It has been about a year since I started doing the work of an engineering manager, though I only received the title four months ago. I am still new to it. These are the ideas I relied on during that first year, including a few I expect to revise as I get more experience.
The early days
At first, I had no idea what I was doing. Leading a team made the imposter syndrome loud. I was lucky to have a supportive boss and examples of managers who had helped me earlier in my career.
The managers I trusted shared a few habits. They explained what was happening instead of hiding difficult news. They stayed calm under pressure. They asked for my input before making decisions that affected my work. I wanted to offer my team the same kind of support.
With a small team, I started putting those habits into practice. I mentored people through unfamiliar work and gave critical feedback in a way they could use. As the team got more comfortable with one another, people brought problems to me earlier and disagreed openly about how to solve them. We changed our process when it got in the way. That was my first evidence that this approach worked.
I had spent the previous year as the only front-end engineer, writing the features and making most of the decisions. Growing the team required me to give up that control. Keeping every answer in my own head would have made me the limit on what the team could do.
I chose to give people trust up front. New engineers got meaningful work and room to make decisions before they had spent months proving themselves. That was uncomfortable at first, but holding the keys tighter would not have made the team stronger. My job was to share the context behind earlier decisions, then let other people improve them.
The team did not need copies of me. They needed enough context and support to make good decisions in their own way.
Hiring people with respect
Hiring became a large part of the job as the team grew. I had been through whiteboard interviews, high-pressure challenges, and processes that consumed days without telling me much about the role. I did not want to reproduce those experiences.
The first conversation is about the candidate's work and what they want from their next role. I am looking for work ethic, character, and kindness. Those qualities matter more to me than someone's current technical ability because technical skills can grow. One conversation cannot prove any of them, so I ask for specific examples of how the candidate learned something difficult, handled feedback, and treated teammates when the work got stressful.
The conversation also has to work in both directions. Candidates should leave knowing what the company is building, what the team values, and what the day-to-day job looks like. Selling a vague version of the role might help close a candidate, but it creates a worse first month for everyone.
We still evaluate technical skills. At the time of writing, our process includes a small take-home exercise built around a project brief. Candidates identify missing requirements, explain their approach, and call out risks. The exercise is intentionally limited because a hiring process should not require free work that takes over someone's week.
The final step is a pair-programming session. We send the project several days ahead so the candidate can understand it before the call. During the session we work with them instead of silently watching them struggle. The task resembles the work our engineers do, and we care about the questions they ask, the tradeoffs they notice, and how they respond when something is unclear.
Pair programming is still a pressured setting. Sending the code early and behaving like an actual partner does not remove that pressure, but it makes the exercise closer to the job. Candidates told us that the preparation and collaboration made the process feel more respectful.
Even when we pass on someone, the interview remains a real experience in that person's career. We owe them clear expectations, reasonable use of their time, and a direct answer.
Supporting the team without hovering
Once the team grew, I had to decide how to stay available without turning availability into micromanagement.
Regular one-on-ones help, but constant check-ins do not. I set aside time with each person and make it clear that asking for help is expected. Then I leave room for people to work. Someone will only bring me a difficult problem if earlier conversations proved that doing so was useful.
When a teammate asks for help, I try to give the problem my full attention. We look at the context together, find the blocked decision, and decide who should own the next step. Sometimes they need an answer. Sometimes they need another person to think out loud with. Treating every request as an excuse to take the work back would teach the team to stop asking.
Managing also changed how I think about my time. I can complete one task myself, or I can give several people enough context to complete work I could not have handled alone. That does not mean avoiding technical work. It means choosing technical work that unblocks the team, transfers knowledge, or exposes a problem in our process.
The best result is not work completed exactly as I would have done it. It is work I understand and trust, improved by decisions I would not have made on my own.
What I still have to learn
I am at the start of this job. I have not handled every kind of conflict, difficult performance conversation, or organizational change. I expect some of the advice here to look incomplete after another year.
The part I want to keep is straightforward. Tell people what is happening. Stay steady when the situation is tense. Give people context, trust, and room to disagree. When I do not know what to do, those habits give me somewhere honest to start.