I’m a Software Engineer Who Got Promoted to Management
This is what I learned from embracing the dark side
After several years of gradually moving away from programming, six months ago I finally made the switch into engineering management. My motivation was good — I had discovered, completely by surprise, that the most satisfying part of my job had ceased to be developing code and had started to be developing people. It became clear that the way I could be most productive — and have the biggest influence on the code base was to stop doing the daily work of programming, and instead help others to be more effective and more efficient.
That was the theory.
But in reality I was stepping into the dark. Sure I had seen what my managers did day to day, but there were many parts of their jobs which were, for perfectly good reasons, hidden from view. Over the weeks and months that followed my promotion I began to discover some of these for myself:
My main job is staff retention
If I want to get things done, I need a team. And I’m a line manager to a team of people. If anyone from that team decides to leave the organisation, I find I’m less able to get stuff done. Also I’ll have to start recruiting (which is an expensive process — and risks not finding a good replacement), and that’s if there is money in the budget to recruit a replacement at all… quarterly profits can lead to hiring freezes and open jobs suddenly vanishing.
It’s better for everyone involved I can encourage you to stay. And so, more than anything else, I want to keep you happy. I spend my time studying things to help my team become more engaged in their work, trying to tune jobs and teams to suit the members. And on occasion I will don fancy dress or hurtle over an inflatable obstacle course, not because I want to, but because I’m trying to show you that it is okay to get involved in some of the things we are doing to make your lives better.
The reason I interrupt your work once a week to hold a 1:1 meeting? It’s because I want to know you’re still happy with your job. And I want to be able to nip problems in the bud. Seriously, take advantage of it.
People think you’re going to be angry that they are leaving
When people are thinking of leaving, they are afraid to tell me. Sometimes that’s because they don’t want me to know they are going to interviews (which is a fair enough worry… though I’m not going to stop you, because there is no point in making an enemy at the point I most want to convince you to stay). But the earlier you let me know there is something bothering you, the earlier I can do something about it. And, by the way, I can be quite thick. You may need to be explicit. Tell me ’this is a problem and its making me question if I want to stay here’. If there is anything I can do about it, you bet your life it’s what I’m going to focus on. And I’m open to suggestions as to what will make your life better.
No, I’m not going to be angry if you are leaving. What I’ll probably be is sad. Both because, unless I’ve told you otherwise, you’re a valued member of the team doing good work, and because if you’re going, it means I’ve failed in part of my job. You might think it isn’t my fault, you just want to get a step up the career ladder — but I’m here to help you grow your career as fast as possible, to help you be everything you are capable of being. I’m also going to try to win you back. In the past I’ve told people “don’t accept a pay rise once you’ve threatened to leave” — and it’s a reasonable point. But if I’ve missed the fact you needed a pay rise, I want desperately to give you the chance to get one. As I said above, I’m thick. If this is the first time you’ve explicitly told me you want more money, it could be the first time I’ve realised money was your key issue.
I need to be interested in what people say
This was a surprise. I’m an introvert, but being a manager means I sometimes have to play being an extrovert at work. Generally, in my daily life, I don’t have deep person to person conversations — especially not about people’s lives and their emotions. But now I’m regularly having 1:1 meetings and trying to understand everything about what makes my team members tick. And that means taking conversations whichever way they go. Now, many of my team are also introverts, so at times it’s like a stone trying to suck blood from another stone, but the thing I’ve had to do to make it work is be interested in them. And that’s kind of new to me. So if you are telling me about your weekend, or some personal project, or a family wedding, you bet your life I’m going to be asking more about it. And I genuinely want to know more about it — and even help you out if there is anything I can do to assist. The other day I honestly recommended a motorway service station to one of my engineers.
And there is a deep motivation for all this: What you talk about tells me what matters to you. And that helps me determine if there is something I can do better. Because as often as I tell people I’m thick, most people don’t come out with their biggest concerns until they have turned into significant problems
People care about the strangest things
It is reasonable to assume that that what I want isn’t what other people want, we are all different. But it turns out other people are weird. Some people care far more about being allowed to have a plant other desk than they do about getting a substantial pay rise. Some people get really emotionally attached to the type of biscuits available in the break room. And speed bumps in the car park, and soap dispensers in the bathroom can almost be quitting issues.
So I really had to learn that what is trivial to me can be life or death to someone else.
When people don’t want to do something, there is always a reason — and it isn’t always that they don’t like doing it
Sometimes engineers don’t do the work I ask them to do. And usually they don’t tell me they are not going to do the work, so I only find out that it still isn’t done when I check up. By which time, I’ve probably told someone else it’s all under control. This isn’t because my team are lazy, or because they are inveterate liars. But there is a deep seated reason — and it’s that reason which needs to be addressed. Sometimes it’s because the engineer thinks they know better than me what needs to be done. And frequently they are right. There has been a communication breakdown where I’ve failed to learn from the engineer what challenges are blocking them from being effective. Sometimes the engineer is wrong — in these cases there has usually been a communication breakdown where I have failed to explain to the engineer what is most important to the business right now (and more significantly why)
But there is another more significant concern. I know my team, and I expect great things of them. In general I can trust and rely on them. But sometimes, when I ask my team members to do something, they don’t trust themselves to be capable of doing it. This is part of the learning curve of any new skill I’m asking someone to take on. They start off not knowing the skill, and not wanting to go through the early stages of incompetence as they pick it up… at this point it’s my responsibility to ensure they are supported until they get over this hump and into the high flying phase where they are able to teach themselves and enjoy the growth they get from learning it. But there is a second phase of fear: After a point, they run into a wall. The learning stops, and the task becomes boring. This is where we have to make a choice — can I get them through this hump and into mastery, or should I find a way to sweeten the work — perhaps by suggesting the engineer tackle it in a way which suits their needs and desires rather than the most efficient way. For one engineer this might be asking them to teach someone else. For a different engineer this might involve automating the task, or picking a new language or paradigm to work in.
In any event, my job is not to judge ‘does the engineer do their work?’ but rather ‘what is getting in the way of them doing that work, and how can I help?’
Many software engineers don’t see much of the bigger picture
As an engineer you have to focus. I have spent weeks as an engineer trying to solve a problem which ultimately only required the change of one or two characters. Finding those two characters was quite possibly worth tens of thousands of pounds to the company in sales. When I’m in this mode, it’s perfectly reasonable that I can find myself ignoring everything else that’s going on — especially as companies can be big places, and much of what’s going on can be in a different country — or continent.
When the business decides to tell it’s employees about what is happening, it tends to do so in the language of business. It talks about sales and financials. It makes predictions about the future which are not supported by data. There can be focuses on corporate responsibility and soft skills. None of these things relate in any clear way to the particular two characters an engineer is trying to locate. They feel irrelevant, and frankly not particularly real or believable. Engineers work in hard facts and hard results. In company meetings they bring their laptops along, ignore the speakers, and get back to the thing that really matters — the code.
As a result, engineers know an awful lot about the code they are writing, but frequently far less about why they are writing the code, why the company values it, and what it actually needs to do in the future. This means engineers argue to improve codebases in ways which don’t suit company strategies, they argue for features which don’t make business sense, and they build up resentment about other teams which are not willing to lend a hand in their work (because those teams, quite rightly, are focusing on the wider goals of the company)
At times, as a manager I even have to divert engineers away from the bigger picture. As a manager I need my engineers to focus on what they are doing. What they are doing may well be incredibly significant to the company’s ongoing business plan, but it may well be a long distance from what the business is pushing hardest. I need to convey the importance of their work to motivate my team (and at times reassure them about their job security). I draw their eyes away from the big picture, then find myself wondering why, weeks later, they are not acting as if they understand the part they play within it.
It is very easy not to communicate enough
Sometimes engineers can get very angry or upset. When this happens, it’s usually because I haven’t explained something to them well enough. And frequently I’ve completely failed to notice that they didn’t know the things which would have made my actions make perfect sense.
Here is how this happens: Management identify a problem. Often we’ve identified the problem because those engineers who are now upset were the people who told us about it. We look at the problem and realise it’s one which needs to be fixed at a management level (there are several reasons we come to this conclusion — the two most common are politics and economies of scale). So we talk about it, a lot. We investigate. We gather data. We might pull in some key engineers who are involved, and get their assistance. We build a plan — a plan that’s in line with all the other factors we are trying to manage. Frankly, by this time, we’ve spent so much time looking at this issue that we know it back to front and are, quite frankly, sick of it. But from the outside, it might look like the problem is just being ignored — as if we’re not doing anything about it.
Then we begin to institute the fix. Ignoring the fact that our fix might not be the fix the engineers want (engineers are problem solvers, so they frequently turn up with solutions to problems, not the problems themselves… but as I mentioned above, engineers are also frequently missing out on the big picture, and are not trying to solve the actual problem we find ourselves in). And people get annoyed. They get angry.
What has generally happened is we haven’t talked about it enough.
It’s almost impossible to communicate too much. So I’m going to regularly be repeating myself. Not only in meetings, but also one to ones, by email, by slack, and possibly even while you are waiting for the kettle to boil. But sometimes I forget. Sometimes I don’t realise because I know about why we are going the way we’re going and I forget that you might not have been present when we decided to go that way.
So if you want to know what caused a change in procedure, grab me and pull me aside. You’ll find I’ve thought about things much more than you expect. And I’ll probably also apologise for not having told you all of this much earlier.
I’m now responsible for promoting people and giving them pay rises — including people who were my peers six months ago
Those people I laughed and joked with about not getting the promotions and pay rises I wanted are now on my team, and turn up in discussions I have with other managers about who is going to be promoted. It’s uncomfortable. Especially because the promotion pot is never big enough to promote everybody. Now I have to rank people in order of how much I want to see them promoted — and I have to put some of my team members aside because other managers have people they need to promote. It’s a weird game. Concepts of fairness and merit can be brushed aside by the practicalities of who we absolutely have to retain. As a manager I’m batting not only for my team, but for the business — and sometimes the two groups are in opposition.
The best thing I can do is make the process as visible to my team as possible. I can talk to them about the minimum requirements needed to get promoted. I can tell them about the way my company’s promotion cycles work (so when to expect promotion). I can find out if what they are looking for is responsibility, job title or cold hard cash and point them in the right direction. What I can’t do is promise anything by a set date. At best, if the promotion pot isn’t big enough to embrace particular team members, what I can do is give them a leg up the rankings for the next round.
Sadly none of this makes life any easier when I have to tell people they haven’t been promoted this time around. Some parts of being a manager are just plain hard.
Corporate bullshit is greater than most software engineers ever see. But it is all done with the best of intentions
Sometimes as a software developer I was hit by random acts of management. New goals set for the department which didn’t actually match the work we were doing. Conflicting priorities — some turning up as red-hot must-do-right-now necessities — which hadn’t been mentioned yesterday. HR initiatives which feel tone deaf. Training courses which teach incorrect, irrelevant information… and, by the way, are compulsory.
These didn’t go away as I got promoted. In fact now there are more of them. Believe it or not, we spend time trying to shield the team from being distracted by even more of these initiatives… but we also begin to get visibility on where they come from. Most of the initiatives come as a result of the business identifying fundamental global problems. These problems need to be fixed, and the way upper management fix problems is by setting goals. These goals are turned into numbers we can track. And the numbers need to be achieved by certain company functions… who don’t always have a great oversight of the company as a whole, and who certainly don’t have the time or money to come up with approaches that suit everybody.
So when I can’t shield you from the bullshit, my job is to try to make it as easy as possible to comply with. Which sometimes means I have to make space for you do fulfil it within your usual job. And that can look like I’m now hugely worried about you doing something pointless and irritating rather than doing all that urgent work you have mounting up. Really, I’m just trying to get it out of the way so that both you, and I, can focus on what actually matters.
And in case you’re wondering — if there are better ways of meeting the goals the company sets, you can bet I’ll be feeding them upwards too.
Now I have to spend time managing the people who used to manage me
The people who used to be my managers are now my peers. When I want to get things done, these are the people I rely on to help me.
When they were my managers, to some extent they were more like a force of nature — people I would ask for help, and they would either give it to me, or not. It certainly wasn’t always entirely visible why they were not able to help in some situations. And while I had theories as to which managers were better at particular things and tried to use those to my advantage, ultimately what I got was up to them, not up to me.
Now things have changed. These managers are no longer forces of nature, but people with just as many annoying (and adorable) tics and personality quirks as anyone I’ve work on as part of a development team. They have their own areas of focus, and their own approaches to leading their teams. If I align with what they care about, I get complete support — but if I ask them to take substantial time out of their work to assist me, sometimes it takes a certain amount of prodding and poking until I get what I want.
It doesn’t always come naturally to realise that, now, I’m having to give tasks to — and chase up the people who previously gave tasks and chased up me.
Management is Fun!
I absolutely made the right decision moving to management. I can see it isn’t a role for everyone. It takes a whole different set of skills from being a software engineer. But it is also much more rewarding. I’m still developing a product — but now I’m also growing a team. I’m watching people mature, take on responsibilities and do things that I would never have managed to do. And I like to think I’m helping them along the way. I’m learning. After eighteen years in software development and nine years in one company, I was beginning to think that there wasn’t much more to pick up in my areas of expertise. Now I’m back on the personal development track, and discovering new things I need to know, and new skills and facets of my personality I never knew I had.
Computers are great, because they give instant feedback, and you are either right or wrong — your code either compiles or it doesn’t. People are far more nuanced. Ideas they hate can turn out to be fantastic successes, and things which start off as failures and be tweaked to become practical and efficient — or can cause unimaginable pain to large numbers of people. Instead of a debugger, all I have now are one to one meetings and occasionally being harangued while picking up a cup of coffee. But I’m back in the game, and feel far more alive as a result.
