Developers, your manager is likely clueless

Software is new to the planet, and given that it took 100 years to build competent management techniques for manufacturing, it is no wonder that managers today are looked upon so poorly by developers.

Author’s Note: This article is focused on legacy, MBA dominated environments. If your company has proven, amazing software engineering execution built into its DNA, it is very likely this article is a non-sequitur for your situation.

Kevin called me into his office for one of his Q&A sessions, “I called you in here to brainstorm on an important problem.” I nodded energetically, thinking he had finally figured out something important, 3 weeks into being our manager. Kevin continued with “So listen, I keep hearing about all these bugs. And I really think we need to put a stop to it.” I cautiously responded, “Stop to what?” Kevin replied, “Stop the bugs, we need to stop putting bugs in.” I was somewhat early in my career, so I wasn’t really sure what to say. I mean, I’m not pro-bug, right? Nobody is pro-bug. I’m really anti-bug, and if you look at the history of computer science with the development of elaborate type systems, managed runtime environments and procedure level fuzzing, the industry itself has more than proven itself to be as anti-bug as anyone. Yet here is Kevin with his principled stance that the team just needs to stop putting bugs in the code. Bless his heart, right? Wow, if only we had thought of that ourselves, this is why we clearly needed Kevin!

Kevin is real, and while these days the Kevins of the world don’t come out and say things like above, they still think just like the Kevin of yesteryear, looking for fever symptoms so they can apply that bottle of aspirin, and then wonder why patient dies from a lack of antibiotics. The Kevins of today have moved on from trying to stop bugs, to having Jira SLAs for resolution of bugs. Sadly, this is probably worse since at least old Kevin was tangentially interested in reducing the escape rate of bugs, which might actually translate to something like a CI pipeline to discover bugs early rather than an SLA system which is all about remediation after the fact.

The Kevins of the world come by their ignorance honestly as, to date, there is no reputable source of software engineering management education to help Kevin become competent. Well, that and Kevin needs to learn how to code, so he can then learn just how ignorant “Stop putting bugs in the code” really sounds to a development team.

Lest you think this article means that developers are perfect, have a read on the need for managers to curate development teams. The imperfection of humans is actually one of the key reasons competent, caring management is truly needed - regardless of what a significant portion of Agile followers think.

Here are some signs you have been saddled with a clueless manager.

Focuses on Jira metrics, praises people for completing “lots of Jira tasks”

This is especially bad, software engineers are smart, they can game Jira metrics with almost no brain power. Kevin will be pretty happy because his team will always be in the story point/Jira task lead, that is until another team figures out how the task/story point inflation game is played.

Doesn’t understand the team’s competencies and skills

This results in work coming to the team that isn’t a good fit. And if the manager is a flogger, you get the benefit of skilling up via death-march on nights and weekends - assuming you don’t just solve the real problem by jumping ship and leaving your manager.

Says things like “Let’s just get it out there and then Fix Forward!”

This brand of manager is ignorant about just how users react to buggy software. If your company has some kind of a moat that prevents competition, you can get away with deploying really buggy software and then applying the Fix Forward anti-pattern - that is until they figure out how to break the moat. But, even in the short term with a moat, all of the experts agree that it is actually far cheaper to get the bugs out of the software first and then deploy. Quality actually is cheaper when you calculate total business cost.

Blames development staff for introducing bugs

Bugs are a fact of life when introducing software change. Anyone with experience knows that the correct outlook is to expect there to be bugs and involve the development team in building CI and automated regression testing to get the bugs out before giving the software to the customer.

Gets upset when bugs are discovered

This is a common side dish that comes with blaming the development staff above, only in this case the net effect is to repress the reporting of bugs. Which of course results in slowing down the process of removing bugs from the code.

Just wants to get it done ASAP

This manager is all about ignoring problems. Is there a problem but another team is going on the hook for it? Blinders on, just get your Jiras done! This manager, depending on their mood, also loves to squash work like cosmetic fixes that reduce cognitive dissonance - the theory being that the team should laser focus on getting their Jiras done and wait for some other silo to raise a new Jira to fix cosmetic defects.

Tells everyone what to do and how to do it, in detail

Detailed tellers are so happy that they finally have the power to get everyone to write code “the correct” way. Tellers are especially bad if they have lots of energy and vigor as you can’t just wait for them to go away. This manager type is probably single-handedly responsible for causing software engineers to be reticent about working for a manager with technical chops.

Doesn’t understand survivorship bias

Companies will fail in large software undertakings several times, and assuming they don’t go under, finally get something that sort of works that they can “Fix Forward.” The prior failures are glossed over and forgotten, the organization eagerly reports success all the way up the chain and the C-Suite sighs in relief that they’ve finally put that gnarly software project in their rearview. Of course what comes next for the C-Suite is a never ending series of escalations (that’s what drives the Fix part), a slow death by a thousand cuts, all courtesy of the “Fix Forward” anti-pattern.

So, as a developer, what can you do?

Not much, unless you have a good shot at getting the manager removed without hurting your career. You might be tempted to somehow educate your manager, and if the skill gaps are pretty small, and the trust level is high, the managing-up school of management can be effective. However, most development manager skills gaps are on the scale of the Grand Canyon. For example, if the manager lacks software engineering competence, that just isn’t fixable. No magic wand is going to make old or new Kevin a good development manager. Furthermore Kevin is usually in place because the organization likes him, you can infer this fact because he lacks competence and is still employed. I have seen engineers band together and get their whole team moved away from a manager, so it isn’t impossible to effect change. Dramatic and traumatic, but not impossible. Before undertaking such an effort in political maneuvering, ask yourself how likely it is that the next manager the organization selects will be as bad or worse. Sometimes it makes sense to change the organization. In my experience though, it is usually better to just change organizations - especially if you detect that you are in an organization that has no track record for great software product execution.

Bottom line: If you know that your work product is actually used by the customer base and your manager is consistently giving you bad direction or just seems useless, chances are quite good that you have been saddled with a bad manager. A good manager will actually do things that are useful, and you will for sure notice them doing it. And remember, if you can’t change the organization, change organizations. Your software engineering career is too important to waste on bad management.

Or follow me on twitter: @eWattWhere