Moving from engineer to engineering manager changed more than I expected. I led people before I had a management title. I knew the work, helped others get started and spoke up when I thought a decision was wrong. I assumed the management title would make that responsibility official.
My decisions now affected other people’s work and opportunities. I had to assess performance, give difficult feedback and make calls that someone might dislike. I also had to give up some of the technical work I enjoyed. The extra meetings were the obvious change, but they were hardly the interesting one.
My background was mainly in QA and technical leadership. I could solve problems and defend a team’s point of view. Managing the people doing the work required more than that.
Leadership Started Before the Management Title
My first lead role grew out of a project I had been handling largely on my own. When other people joined, I already knew the work, kept track of what needed doing and helped them get involved. I became the lead because the project had grown around me.
In later roles, I stepped forward again. I was involved and willing to argue for the team, including in uncomfortable meetings. Sometimes that was useful. Sometimes I was so focused on making my point that I gave too little thought to whether I was bringing people with me.
One early mistake was trying to make a new lead appointment less awkward. A colleague seemed unhappy about it, so I told him it did not really matter who was lead. We would work together. I meant the second part; the first part was false.
It mattered who made the final call and who answered for it. We could collaborate closely without pretending those responsibilities were identical. I was trying to be kind and ended up making the role less clear.
The management title made that responsibility explicit. I had to represent the team, assess work and help people develop. Knowing the technical work did not tell me how to manage the people doing it.
I Had to Stop Managing by Instinct
For a while, I led mostly by instinct. I stayed involved, helped people solve problems and spoke up when I thought something was wrong. I was much less prepared for difficult feedback or for following someone’s development over time.
A management course in 2019 changed how I approached the job. It made me take one-on-ones, feedback, goals, delegation and performance reviews seriously as regular work. Later, Engineering Management for the Rest of Us helped me think further about trust and conflict. Reading did not make the conversations easy. At least I had stopped treating them as something to improvise when a problem appeared.
I began having regular conversations about what people wanted to learn and how their work was going. I followed up instead of waiting for a formal review. If I had a concern, I tried to say it while there was still time to do something about it.
I was still direct, and I did not always get the delivery right. In a technical discussion, saying the uncomfortable thing can move the work forward. When the subject is somebody’s performance, the same habit needs more care. I had to learn that giving clear feedback and getting a useful response were two different skills.
Helping People Grow Was the Best Part
I liked helping people grow before I became a manager. In the role, I could do more than offer occasional advice. I could help someone choose what to learn, give them work where they could practise it, and follow their progress.
I saw colleagues broaden their work from manual testing into automation, DevOps and software development. I gave them responsibilities in those areas, made room where I could and followed their progress. They did the learning and took the risks.
Making room also meant handing over work I would have liked to do myself. If I kept every interesting task because I could finish it faster, other people would have little chance to develop. That decision made sense for the team. It had consequences for my own technical work, which I only understood later.
Performance Reviews Made Fairness Harder
I wanted to be fair. That was easy to say until people with different contributions and ambitions wanted recognition at the same time, and the available rewards were limited.
I decided salary increases and bonuses within the available budget. For promotions, I consulted my manager and had a substantial say in the decision, with the promotion budget also setting limits.
I had to assess the contributions of people I respected and explain my decisions. Sometimes I could not give someone the recognition I thought they deserved. I wanted people to feel heard, but trying to satisfy everyone made those decisions harder.
My 50/50 Plan Failed in Practice
I tried to split my role roughly in half: management on one side, hands-on QA work on the other. It sounded sensible. I would stay close to the work and still lead the team. In practice, the numbers were fiction.
The most interesting technical opportunities usually went to people on the team. That was often the right decision for their growth. The management work stayed with me, and I filled my supposed technical half with manual testing tasks that still needed doing. I was busy, but I was not developing in the technical areas I had imagined.
I had helped create the problem. I still needed to understand the technical areas the team was taking on, but I had not worked out how to keep learning while leaving them room to do the work.
I do not think every manager has to stop technical work. My mistake was calling the job 50/50 without deciding what that meant when the team’s development needs and management work competed for my time.
I would define the technical part much more carefully now: which work the manager keeps, which work belongs with the team and how the manager stays informed without claiming the best tasks. I had left those questions unanswered and then wondered why the split did not work.
What I Would Clarify About the Role
I liked the people part of management. Seeing somebody become confident in work that was new to them was satisfying. I also learned that liking that part of the job did not tell me enough about the rest of it.
Before taking a management role, I would ask what decisions I would actually own. Could I set priorities and make the final call on team work, or would I mainly pass decisions along? How would performance judgments be made, and what part would be mine? When a problem went beyond my authority, who would I take it to, and what could I expect them to decide?
I would also ask what technical work the role really included. If somebody says it is half management and half contribution, I would want examples of what fills each half in an ordinary month. My own version sounded plausible until I tried to do it.
Those questions would not remove the difficult conversations. They would make the job itself clearer.