Changing the Culture of Apathy

Generally speaking, I try not to point out specific things about specific places I've worked. It feels like mud slinging. This post will talk about my current employer. It won't be flattering. It won't be mudslinging though. My hope is to identify some problems and seek a solution. Ultimately, that's what we do, right? Some problems are computer problems, and some are human problems. Being a software engineer often means being able to tell to the two apart, but I know that I personally overlook the human aspect quite a bit. I'd like to change that.

The culture at my workplace is one of apathy. Engineers don't stress code quality, they don't fight for things they feel are important, and they tolerate gross impediments to their output. This is shown in the tools employed (or lack thereof in many cases), processes used, and the scrambling many teams do just to stay afloat.

The level of despair brings down other engineers who otherwise would be fighting the good fight. Not all is lost, however. At some point I pushed against my manager and got myself a spare laptop (VMs can involve prohibitive amounts of red tape). This laptop is now our CI/CD server. It has a sticky note on it saying "Do not shut down, doing servery things" - this is because it was shut down during a standup by a well-intentioned employee. This isn't what gives me hope though. What gives me hope is that in a sprint delivery demo, I gave a brief showing of the code coverage report. The demo was hijacked by the coverage report. The CTO/CIO (the exact title eludes me) is the one who hijacked it. "We need more of this" and "How do we get other teams doing this?" are sentences that were exchanged. This is what gives me hope.

My damage is that I like a good challenge. While I bet I could go find a sweet gig at New Relic, which is a couple blocks from my current location, there's something really interesting about showing up at a place and seeing a software shop that has dysfunction, but wants to get better. I'm in a position to help with that. Do I have all of the good ideas on how to handle that? Of course not.

Yesterday I told my team I was going to get it such that our turnaround for a feature into production in 5 minutes. Currently it's 60 days at best. It's a tall order, and there's much to do to get there. I can see the path we need to traverse to do it. The problem I have is that I'm just one engineer at a shop who must have 200 people in IT. Doing this alone while still keeping up with my daily obligations feels daunting. So what do I do?

I've thought about getting more involved in the hiring process, but I think pulling in the 'right people', whatever that is, will be a fool's errand. While any shop should make an effort to guide its culture, I think changing the culture by bringing in different people isn't the best way to go. I think anyone wanting to bring in some good practices is probably going to avoid a place like this. While it's worth putting some energy into this, I believe the majority should go towards fixing the problems within. There needs to be a way to motivate engineers to want to be better, learn more, and stop putting up with a broken process.

Materials on inspiring engineers to do better feels sparse. Maybe that's because this is more generic managerial stuff. Here's some ideas that come to mind:

1. Set aside resources for engineers to improve. This means time to explore tech and money set aside to go to conferences and the like. This also means engineer time isn't 100% devoted to some product. It means they get to find ways to improve their workflow without having to put in OT to do it. Brown bags are great, but they aren't a real investment on behalf of the organization. If you want to retain people who are invested in you, you need to invest in them.
2. Stop punishing failure. Innovation means you're going to take risks and risk means you're going to make mistakes. If you punish those mistakes severely then nobody will try out new things or do anything amazing - these are inherently risky things. Mistakes will happen regardless of how hard you try to minimize it. The better route to go is having a means of recovery when mistakes do happen.
3. Treat impediments like the plague. On of the most demotivating thing I see a behemoth process standing in my way of making any kind of improvements. Need access to the documentation wiki? Submit a ticket. Need access to the company chat service? Ticket. Need to be able to view the logs for the set of servers your team uses (be it development or production)? Ticket. We have a similar story with deployments, which is probably why we have an entire release management department. These impediments snuff out any hopes that an engineer can make a difference and that their work has impact.
4. Stabilize our environments. My initial thought is to say no future development on features until our nasty fire-starting bugs are fixed. Even then, we need to be on lockdown until we have a release pattern that doesn't encourage dysfunction. This one I feel less confident about, since it's a bigger ask. I'm not sure how else to do this though. People who are willing to help make things better often are not in the place to do it because of how crazy it can be just to keep up.

Any other ideas on what to do? I'll gladly accept reasoned speculation, but hearing some success stories would be great too.