I called the meeting because the team needed direction.

We were facing real challenges. The kind that don't resolve themselves. I had an analysis of the situation, a clear view of what needed to happen, and I had called the team together to begin working through it.

What I didn't have was a room that agreed.

Some members of the team saw the problem differently. Some had their own ideas about how to respond. The conversation pulled in multiple directions at once, and I sat there with a realization that stopped me cold: I had no idea how to handle this.

Not the technical problem. I understood that. I had been a software engineer for years. Debugging complex systems, writing production code, delivering under pressure; I could do all of that. What I couldn't do, it turned out, was navigate a room full of people who disagreed, get them aligned, and get them moving.

That was the moment I understood that leading a team and doing the engineering work were two completely different games.

The game you were trained for

As an engineer, you build skills in a specific kind of problem-solving. You define a problem, examine it, identify a solution, and implement it. The feedback is fast and honest. The code compiles or it doesn't. The tests pass or they don't. The system works or it doesn't.

You get good at this. You get very good at this. And because you get good at it, you get recognised for it. You get promoted because of it.

Then you step into a leadership role, reach for those same skills, and they don't work.

The problem in that meeting room wasn't a logic error. It wasn't a bug I could trace. There was no debugger for disagreement between smart people who each had a legitimate perspective. There was no compiler that would tell me which direction was right. There was just a room of people looking at me, a decision that needed to be made, and a team that needed to move.

That's not an engineering problem. It's a people problem. And most first-time tech leaders are completely unprepared for it.

Why technical excellence doesn't transfer

The skills that make engineers excellent tend to work against them when they first step into leadership. This isn't a criticism. It's a structural reality worth understanding clearly.

Engineering rewards individual precision. You write code. You own it. The quality of your output is a direct reflection of your knowledge and effort. Leadership rewards collective outcomes. You don't produce anything directly anymore. You produce results through other people. That is a fundamentally different relationship to work.

Engineering rewards being right. In a technical argument, correctness matters. The better solution wins. Leadership regularly requires you to move forward without certainty; to make a call with incomplete information, commit to a direction, and bring people with you even when they're not fully convinced.

Engineering gives you fast feedback. You know quickly whether something worked. Leadership operates on much longer loops. You make a decision today and find out if it was right weeks or months later. Even then the signal is noisy.

Then there's this: as an engineer, your credibility came from what you could do. You were the person who solved the hard problems. In a leadership role, you become the person who knows the least about what everyone else is doing day to day. You can't out-code your engineers. You can't out-design your designers. The credibility you built as an individual contributor doesn't transfer automatically. You have to build a different kind.

What nobody tells you going in

Research from the Chartered Management Institute puts 82% of people who move into management positions in the "accidental manager" category; people who received no proper leadership training before or after being promoted [1]. That figure is for the general workforce. In tech, the pattern may be more pronounced. Most engineers who move into leadership do so because they were excellent engineers. Not because anyone prepared them to lead.

This is the gap. Not a character flaw. Not a failure of intelligence. A gap between the job you were hired and trained for and the job you've been handed.

The challenges I faced in that meeting room were not unusual. They are close to universal for first-time tech leaders. The inability to reach for technical skill and solve a human problem. The discomfort of ambiguity where there used to be precision. The feeling that the thing that made you good at your job has suddenly stopped working.

If you've felt that, you're not behind. You're at the start of learning a different set of skills.

What this blog is for

The Hard Part is about the work that comes after the technical work.

It's for engineers, product managers, and all other professionals working in tech who are stepping into leadership, or who are already in it and finding it harder than they expected. It's for people who are good at what they do and are now being asked to do something completely different, with little instruction and high stakes.

I write from my experience. I've been a software engineer, an IT manager, and a senior product leader in tech. I've made the mistakes that come with being underprepared. I've also spent the time to study what works, grounded in psychology and coaching science rather than management folklore.

This blog won't tell you to be more confident or find what you're passionate about. It will tell you what the research says, what the experience of real leaders in tech shows, and what actually helps when the technical skills stop being enough.

That's the hard part. That's what this is about.

References

[1] Chartered Management Institute / YouGov, survey of 4,500+ UK workers and managers. Bad Managers and Toxic Work Culture Causing One in Three Staff to Walk. Chartered Management Institute. managers.org.uk. Note: this figure covers the general UK workforce, not tech specifically.