Are you considering a career move from software development* into management? Perhaps you feel you’ve reached a roadblock or dead-end in your technical career path? Or a manager has left your organisation and your seniority and/or tenure means you have the opportunity to take up the role? Perhaps it’s your first step on the management path – a team lead or project lead role?
Well, I have some bad news. Technical skill and seniority does not translate into managerial aptitude. In fact, the better you are at your technical role right now, the worse off you will be as a manager. And it gets worse: If you are an awesome hacker, chances are you will not only suck at management, but you will also hate it with a passion.
In 2001, I was working for a major bank in the UK, on a huge internet banking project. We had a team of over 200, with the project being run by one of the ‘Big 8′ (as it was at the time) consulting firms. My role was initially mostly technical – I spent almost all of my time designing algorithms and writing code. Over the course of the project, the seniority of my role grew; by the end, I spent most of my time dealing directly with the business and project management team.
My lasting impression of management at the conclusion of that project was very simple: these people have absolutely no idea what software development is and no idea how to manage a software development team.
Don’t get me wrong, they were nice, friendly, earnest people. They were honestly trying to achieve the best possible result for the business and the project, but they were failing in so many ways to connect with the development group that I was just baffled. How could these managers, many of them with dozens of years of experience, be so bad at this? At lunch, the dev team would uniformly gather together and bitch about the latest management decisions, conjecture on the cost in wasted time and money and collectively boggle at how such seemingly fundamental mistakes could be made.
When I was at university, a couple of mates and I had established a rule which has served me well since then. If one of us complained or bitched or moaned about something long or often enough, he could be called out on it with a standard question: “So what are you going to do about it?” I love how simply this question shifts the conversation. You’ve bitched enough. Either you think this issue is worth taking action over, in which case do it. Or you don’t, in which case, please shut up about it.
So when that project wrapped up, I returned to Australia with one thought in my head: get into management. I mean, how hard could it be?
Turns out, quite hard.
With fifteen years’ experience managing technical teams now behind me, I have what appears to be a relatively rare combination of technical and managerial experience. I’ve been part of the solution architecture group on international, multi-year, multi-million dollar projects and I’ve also managed diverse teams of over 100 technical staff.
A shift from a technical role into a management one doesn’t just require you to manage your time differently. It doesn’t just require a new set of skills, or using different buzz-words. It requires a fundamental re-wiring of your core beliefs. It’s not a vocational shift, it’s a religious one.
At the core of almost everything we do as software developers is a simple principle: meritocracy. The belief which underpins this is that there is an objective way to judge the value of what we are doing. Given a particular context, we can compare competing proposals and select the better of the two. We constantly strive to move towards this ‘better’ end of the scale in our skills, our tools, our methodologies and our solutions. Personal status, rank, experience, tenure – all are meaningless, save as rough heuristics for who gets listened to first. It’s the idea, the concept, the design, the implementation, the explanation – the value – which wins, not the person. Objectivity is king.
This view of our art is diametrically opposed to that of management. In management-land, context and value are fluid concepts. Relationships, whether commercial, professional, social or political, are the driving force. Perspectives and perceptions combine, conflict and criss-cross, constantly changing, to create a shifting web of motivations. Selecting which motivation to act on is a subjective fishing trip in an ocean of subjective interpretation.
Never was this more starkly demonstrated to me than in 2012, during an exchange I had with the General Manager of my division. A few weeks earlier, in our weekly catch-up, he mentioned that he felt we had a “delivery quality” issue in one of our regions. That team reported to me, so obviously I took the news seriously and asked him why he had that impression. He told me that there had been reports that we were issuing a lot of credits – essentially refunds – on work done in that region recently.
Hearing his reasoning, I immediately relaxed. I knew that any credits had to go through me for approval and that there had only been one which had. It was for a very small amount and was due to the poor performance, over a year beforehand, of an employee who had since left the company. I also had very good knowledge of how the accounting process worked for this region – credit entries on the P&L were quite commonly just the result of accounting adjustments being made (for example correcting a double-billing error from the previous month). I knew with certainty that these credits didn’t mean we had an issue with the quality of our delivery.
I detailed all of this in broad terms to the GM and figured that would be the end of it. The delivery team certainly couldn’t be blamed for an artefact of how our accounting process worked.
Over the next few weeks though, the GM continued to repeat the mantra that there was a delivery quality issue in that region. He brought it up in a number of different meetings, to a variety of other managers and stakeholders – including upwards reporting to the Group General Manager. I was baffled. He was doing reputational damage to this team across broad sections of the business, even after I had explained the situation. I urged him on a number of occasions to review the credit list for accounting adjustments, rather than to continue to report that there was delivery quality issue – to no avail.
For our next scheduled catch up, I went and got the credit list myself. I categorised each entry, along with evidence of the accounting adjustments and why they were being made. I was ready once and for all to put the issue to bed.
After I presented the data, along with my detailed analysis which categorically proved there was no delivery quality issue, he said something I will never forget: “I understand what you’re showing me, but I’m not the sort of manager who makes decisions based on these kinds of facts. I’m more of a ‘gut feel’ sort of person and my gut feel tells me that we have a delivery quality issue in that region.”
I still tell this story today, particularly to people with technical backgrounds – the punch-line always gets a laugh. To them, it’s an almost-perfect real-world manifestation of Dilbert’s PHB.
Once you finish laughing though, it’s worth considering that many managers would not see any issue with what that GM said. Their value to their organisation is their subjective judgement – being able to draw their own conclusions from a range of inputs, even in the face of overwhelming evidence to the contrary. It’s seen as ‘strong leadership’. Glossy business literature is rife with stories about managers who trusted their gut when all the evidence was against them – succeeding despite the odds.
This is the cognitive dissonance you will need to resolve, as you take up management duties. Very rarely is any managerial decision-making done based on anything which could be called objective data. Pursuit of certainty is almost always counter-productive. It is too costly, takes too long and is anyway probably irrelevant by the time you achieve it.
You’ll need to make frequent, rapid decisions, based on competing expectations, considering relationships first and you’ll never, ever, be (completely) right. Welcome to management.
*I imagine this concept applies equally to other technical fields, but I have the greatest depth of experience with software development.