The first thing that surprised me was how much control I felt I’d lost. On paper a promotion is supposed to mean the opposite — more authority, more reach, more say in how things get done. In practice, the work I used to be measured by wasn’t mine to do anymore. I couldn’t ship the feature myself. I couldn’t fix the bug at eleven o’clock at night. The success of the role, and by extension my success in it, now depended on twenty other people doing their jobs well. That’s a strange feeling for anyone who’s spent a career being the person who could just sit down and solve it.
What I cared about — what I’d cared about for years before the title made it official — was building the right team and the right culture. Quality of the code we shipped, but also quality of the working life around it. I wanted the developers on my team to be happy, to be productive, and (dare I say it) to actually enjoy the job. Those three things aren’t unrelated. The teams I’d been part of that produced the best work were always the ones where people wanted to be there in the first place.
I didn’t stop writing code overnight, and I’m not going to pretend that I did. The switch from delivering work yourself to enabling other people to deliver it is the part of the job that catches most new managers out, and it caught me out too — but I was at least aware that it had to happen. Learning to delegate properly, to trust someone else to do something I knew I could do faster, and then to let them learn from doing it, turned out to be one of the slowest and most uncomfortable lessons of the first year. It’s easy to say “I trust the team.” It’s harder to live that on a Friday afternoon when the deadline is Monday.
There were also things I wanted to put right. Some of them were structural and long overdue: salaries that hadn’t kept up with what good developers were actually worth, software platforms that had been quietly neglected for years, and a career path that was opaque enough to leave good people drifting. Some of them were cultural: I wanted the developers on the team to actually talk to each other — to share what they were working on, to help each other through hard problems, to take some interest in each other’s growth. None of this was going to change overnight. Honestly, none of it was going to change in a year. But I wanted to start, and I wanted whatever progress we did make to land in a way that benefited the business as well as the people in it, because I knew that was the only version of this that would actually stick.
The strange comfort I had going into the role was that, as a senior engineer, I’d spent years calling the outcomes of technical, architectural and business decisions before they played out — often with an accuracy that had surprised even me. I had a quiet reputation for being right about the hard calls. What I was about to find out was whether any of that judgement transferred when the calls weren’t about systems any more, but about people. I’d lost control in some places and gained it in others, and it was time to put that reputation on the line.