This issue boils down to non-technical people making technical decisions. I’ve talked about this in previous articles that I wanted to spend a little bit more time on. My main issue here can be with Agile management, if you have, but this is not about Agile at all. Let me say that again; this is not about Agile.

With that out of the way, what am I actually talking about? Have you ever worked at a company and realized, “Hey, this technology would perfectly solve our issue!”? Then you go and talk with your colleagues, and they agree only to have management say no. That’s what this is about. It’s about when non-technical middle managers decide they know the technology stack better than the engineers hired to know this stuff. This may seem a little broad right now, but I’ll get into some specifics.

Subject Matter Experts

When you get hired, particularly if you’re hired as or promoted to a lead engineer, you’re supposed to be the subject matter expert for whatever team you’re leading. Your teammates look to you for guidance on the project, and (in a perfect world) management looks to you to make technical decisions for the team and deliver on work. Ultimately, this boils down to your role as a team lead. However, in reality, what ends up happening is that some middle managers will decide that some technology is popular, so we should be using it here. Then they go to upper management trying to look like hot shit, saying, look at this technology we need to use when they barely understand anything about the decision they’re trying to make.

Here’s the thing, middle managers don’t understand what makes a software engineering project work. They don’t understand the software development lifecycle. However, they want to look good, so they try and make decisions they have no business getting into. What does that do for software teams? Well, it produces terrible products and pisses off software engineers. More than that, it actively gets in the way of our work. They treat software like a popularity contest, and whatever is the most popular is the right choice. This is why I say that React’s artificially inflated is an awful thing.

Middle managers pick up on that and say, “I don’t care what the problem is; the answer is going to be React.” (disclaimer: this is not a React piece, I’m just using it as an example of technology picked purely for popularity sake). Then we have to run with it even if it’s an awful choice for the job at hand. I’ll leave it at this, don’t hire someone to be a subject matter expert on something if you’re not going to listen to them when they tell you something.

Office Politics

This is especially prevalent in larger companies and enterprise environments, but it can appear in literally any company. Office politics is one of the largest inhibitors of getting shit done that exist in any company. What is office politics, though? It’s really all about power and ownership. It’s more of these stereotypical middle managers trying to look good to upper management by “owning” projects and “managing” them. What does office politics look like in terms of how we see it from the software side, how does it affect us?

From our perspective, they hired us to be subject matter experts. They hired us to write the code and manage the projects and teams from the technical side. From that perspective, we (should) expect a certain level of control over how these things work on that technical level. Our interactions with the business should be to ensure we have the proper business requirements and deliver the product that they expect. While this does happen, a lot of other stuff happens on top of it. Management doesn’t just pass down product requirements; oftentimes, they pass down technical requirements. Use this library, that framework, and these tools. Why does this happen? Sometimes this middle manager worked at a place where they used this technology, so they think it applies everywhere. Maybe another team in the company found success with that tool, so the middle manager decides everyone needs to use it. These are two prevalent reasons that are both flawed in the same way. No two projects are the same, and no two teams are the same. Sure there can always be overlap in technology between projects and teams, but that is, at its core, a technical decision not to be made by non-technical management.

The Enterprise Issue

When you get into an enterprise environment, you’re often not the only team working on something. Enterprises are large places with a lot going on. I talked about this briefly, but enterprises seem to think that we should use the same technology stack throughout the company. Every team needs to use the same tools; every team needs to have the same technology stack. This is usually a really flawed opinion because I mentioned earlier: every product and every team is different.

Sometimes there can also be a financial incentive to standardize. Some tools cost money, so they want to pay for one paid tool and use it everywhere. This is actually a reasonable thing to do to maximize the value of something you purchased. However, my earlier statement still applies. Just because you paid for a tool doesn’t mean it can apply everywhere. It also doesn’t automatically make it the best tool for the job either. Sometimes managers purchase tools before consulting anyone who would actually have to use the tool. When that happens, it’s 100% on the managers who did that when it doesn’t work out.

Long Story Short

I have worked as a software engineer for a while now. I’ve been a tech lead, and I’ve done a fair amount of “lone wolf” development. At one enterprise, I literally watched an entire department go down, and thousands of layoffs occur because of these issues. It’s not always that serious, but it can be! So what can you do? Honestly, not much. When you get all of these things combining into a perfect storm, it can be really disheartening and feels like there’s no recourse. To get anything done that you feel needs to get done, you have to play the game. You have to work within the structure of office politics, you have to make a strong case for changes you want, and you need a lot of support. If it gets bad enough, you actually have decent options as a software developer in the world. There are more job openings than there are people to fill them at the moment. If you feel miserable at your job, you can always leave your job. As a software engineer, you have an incredible privilege to have your skills be in high demand at the moment.

If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!

If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!