Bad engineering managers think leadership is about power, good managers think leadership is about competently serving their team
The services of a good leader is an important gap that development teams desperately need filled. However, very few managers know how to properly serve software development teams.
The state of management in the software industry is so bad that developers are inclined to say “we have Agile, no need for managers.” Indeed, if Agile is nothing else, it is a clear rejection of the need for a highly paid, clueless (but nice I’m sure) guy to show up to status meetings mumbling about how the project is late, again.
Developers come by this disdain honestly, having been subjected to the likes of Kevin who openly wondered why programmers put bugs in their code. Or Bob, the guy who insisted that since we just added 6 new developers, we should be able to hit the date in two weeks. Two weeks, Bob? Really?
Kevin and Bob both have something in common; they’ve never written enough code to understand the process that we all go through. You know the process, right? The one where you say “Hey, this might work, let’s try it!” And then 6 hours later you find out that the tech stack you are using really doesn’t work that way, regardless of how you think it should work. Or when you have a really productive week laying down a lot of new code and then these weird bugs start popping up in integration. Was it your code? Was it someone else’s code? C’mon, it’s always someone else’s code. A couple weeks in you figure out that there is a dependency that needs to be downgraded. Apparently the new way you’re exercising it is No Bueno!
I shudder to think there are people all over the world leading software projects without learning the above lessons about the nature of software. I wouldn’t be writing on this topic if there wasn’t plenty of evidence of this, in fact, being the case. Evidence in the form of an internet full of horror stories about software projects repeatedly going astray at large companies. It is almost like these traditional companies are learning that software is significantly different from construction, manufacturing, sales, or even electrical engineering! Who am I kidding about learning, they really just double and triple down on the same failed strategies their confirmation bias says will surely work this time, only to fail yet again in the exact same way.
If I’m a leader that is serving a team of people doing manufacturing work, there are scientifically proven processes and techniques that can be readily trained and applied. And someone who learns those manufacturing management techniques can reliably boost team productivity. The same cannot be said for software leaders. We come by it honestly, mind you, there really is a bit of a conspiracy in the form of biases built over the last 100 years that just so happens to be the exact wrong thing needed for software R&D. To whit:
“So, in effect, nearly everything you are taught as a business major or leader is seemingly incompatible with software engineering.” ~iism.org - Why CEOs are failing software engineers
At my last company I was told I should pursue an MBA to be a development manager. I did go as far as to pull up the curriculum for several MBA programs. The only thing I saw that might be helpful is financial reporting for Wall Street, should I ever get the dubious pleasure of courting investors in a publicly traded company. The rest of it is all stuff that was invented for the world that existed when Turing joined us. A lot has changed since then. Software is a new thing. Never in history has it been possible to make a thing with so much intricacy and complexity, and get it into the hands of so many people so rapidly. It is such a different paradigm that it is no wonder that traditional management training has almost no bearing on software development teams.
Traditional management is all about establishing repeatable processes that humans will execute reliably. Software is about automating those processes so the humans don’t have to be a computer. Leaders who attempt to make processes for their software development team quickly notice that the work of the team evolves so quickly that the process is irrelevant in a quarter. There is no need for a build process when the build has been automated. There is no need for an integration environment deployment process document when the deployment has been automated. So what’s left for the process wonk leader? I guess it is to write a document about how the process is to automate everything. Hopefully, after publishing, they go find another position where they are needed.
Management of development teams is something new entirely. Maybe. I’ll tell you this, it isn’t taught in an MBA. Harvard isn’t going to teach you how to do it. Whatever development management is, there is no mainstream “just go here and learn how” educational offering. There are, however, plenty of Agile con men who come out of the woodwork, promising to fix the leadership vacuum with their endless consulting hours, certifications and training. If it isn’t working, you must need to buy more training, right? Clearly.
So what are the services that a leader should provide to a development team? I did some research and the first thing I figured out is that there is an incredible amount of SEO spam in this area. I dare you to google “what should development managers do for their team?” No, don’t do it! You will get spammed with Scrumfall Fragile training ads for a month straight. It’s not pretty. I googled so you don’t have to. Here is my humble, partial list derived from sources that resonated with my experience:
Let them do their job with minimal supervision. Do not micro-manage!
Help them advance in the company
Handle the politics with courage, don’t just roll over
Understand the work they are doing, don’t be clueless like Bob
Give the team space to onboard new members so the code base doesn’t get destroyed by people working under bad assumptions
Remember those MBA programs I researched based on bad advice from my manager? Those programs have nothing like the above list in them. In fact, besides random articles on the internet and a few consultants desperately trying to make a go of it, there is really no proven, established educational offering out there to help a budding development manager serve their team. No wonder development teams are so jaded about management. The chances are vanishingly small that they will get a manager who provides the services actually needed; because in truth, nobody really knows what those services are - they just wing it.
In closing, the title of this newsletter is Leadership as a Service. I’m convinced that most software development teams are not getting good service from their leadership. Teams are getting plenty of pressure. Plenty of passive aggressive “I don’t understand why this is late, again.” Plenty of “How come we can’t get this done in two weeks?” And an extra helping of “Hey, I think you can get it done fast if you just do it my way.” Micro-management, project plans and endless servings of story point flavored Jira soup for all, but no leadership service. We can do better, and the price of not doing better is quite high.
Or follow me on twitter: @eWattWhere