So, a little over a year ago, I made the decision to take the next step in my career and try my hand at engineering management. This was after 10+ years of working as an engineer across companies of various sizes, org structures, and cultures.

I was lucky enough to have the support of the leadership team at LatticeFlow - they gave me the opportunity to give it a shot. The timing was also right: the company was growing, multiple teams were forming, and it was becoming pretty clear some form of engineering management would be needed.

So, here are some of my personal reflections on the things I've learned in the past year, going from engineer to manager. And while they may seem straightforward to you, especially if you've read literature on the topic, they can also feel surprisingly counterintuitive in practice to the engineering-minded folks like me.

Preface

(a.k.a. my take on what an "engineering manager” actually does)

Before I dive into the specific learnings, I want to lay out how I personally think about the engineering management role:

1. "Engineering manager” is a support role. You're there to help the team run smoothly. You're there to help individuals grow. You need to watch out for anything disrupting or blocking the team - and help remove it.
2. You're a member of the team like any other person. Think of yourself as a coach, not a boss. You watch from the sidelines and guide the team to improve. You don't get to give out orders. You may need to ask people to focus on specific problems or areas, but that's about as "directive” as it should get.
3. You keep the bird's-eye view of how your team operates and the environment it operates in.

1. Mentor, don't fix

Engineers are problem-solvers by nature. Especially good engineers. We see a problem, and our instinct is to jump in and solve it on the spot. Heck, we even go out of our way to seek problems proactively, just to check if something's broken and needs fixing.

This mentality needs a bit of a tweak once you move into a management role.

You still need to watch out and be proactive about tackling issues. However, when something isn't working optimally, most of the time you should fight your instinct to go and fix it yourself.

Your job is to mentor the people in your team to fix problems. (This assumes your teammates are motivated and want to grow and improve. If not, you have bigger problems.)

This may mean you need to explain why there is a problem (and, in some cases, even convince people that it is a problem in the first place), show them how to spot it, and then mentor them on how to go about fixing or avoiding it.

Hypothetical scenario

Let's consider this scenario:

• Person A is developing Feature X.
• Person B is developing Feature Y.
• Feature Y is blocked on Feature X.
• Feature X is stuck with an open Pull Request, and the author is waiting for review but isn't actively pinging anyone to get the review done.
• This unnecessarily slows down the development of Feature Y.
• It's been 2 days since the PR for Feature X has been opened.

You notice this on day 3. What do you do?

Now, with an engineering mindset of "go and fix the problem”, you might be tempted to:

• Read the PR and do the review yourself. After all, you are an engineer - you can do this and help the team! This gets things rolling and unblocks Feature Y.
• Or, ping other people to read and review the PR (bonus points if you make sure to tell them you need it done ASAP). You're a manager, after all, and you should let them know they need to do this to help the team move forward. Again - Feature Y gets unblocked quickly.

Both solutions are wrong. (You may need to resort to one of them if you are in a real rush, but for long-term team health, they are wrong.)

You fixed the immediate problem, but:

• People most likely didn't realize there was a problem.
• The underlying communication issue remains unaddressed.
• It's going to happen again.

So what do you do instead?

1. Talk to Person A: "Hey, I noticed your PR for Feature X has been sitting open for a couple of days now. We generally want to avoid that - it can lead to merge conflicts and slow things down, and even more so now that we have Feature Y waiting on this. Were you aware Person B is waiting on this? Or is there maybe a communication gap we should address? You should try to be more proactive and vocal. Feel free to ping reviewers after a day or so — things can slip through the cracks.”

2. Talk to Person B: "Hey, I notice you've been waiting for Feature X to get merged, and I understand it may be annoying that it's keeping you blocked. Did you make sure Person A knows you're depending on this change?”

3. If you do daily stand-ups (or some alternative) and neither of them raised the issue: "Hey, this is what stand-ups are for, feel free to call out things like this - it helps everyone stay on the same page and keep things moving”.

Notice that:

• We're not solving the immediate problem. The PR will remain in review.
• We're giving advice and guidance to help them handle the situation now and in the future.
• We're offering gentle feedback instead of scolding people.

This is what mentorship is:

1. Notice a problem.
2. Let them know it is a problem and explain why.
3. Give them guidance on how to handle it.
4. Stay on the sidelines.

2. Consciously shift your priorities

As an engineer, and especially when working in product startups, my main priority has always been a simple one: "ship the best product possible”. Everything else was secondary.

As you start transitioning into a management role, you'll find yourself tempted to think the same way. There's a good chance you'll keep working with the same mindset just out of habit.

However, your priorities should be very different now:

1. Team health. Make sure there's no toxicity in the work environment. Ensure whatever processes you use actually help the team, and that teamwork is solid. Make sure morale is good and support it however you can.
2. Individual people's health and growth. Make sure people on the team are doing okay. Try to keep them motivated. Try to resolve any issues they are facing. Help them grow at their own pace. Push them just enough when needed.
3. Ship the best product possible. After all, you're a part of a product development team :)

Now, I know this advice may sound extremely obvious. But I think it's very easy to forget while you're on the job and your old habits are kicking in. You will find yourself in meetings discussing product features or engineering solutions, and you will have strong opinions. You'll be tempted to lead the discussion, voice your opinions, and defend them. That's what a senior engineer does after all - you ensure the team goes for the best solution possible.

However… that's not your role anymore. You have to start leaving the product and engineering decisions to your teammates. You need to trust them to do a good job. If you don't give them the space to make these decisions, you are hampering their growth.

You should still give suggestions and share your opinion. But it has to be toned down, and you cannot defend it as fiercely as you might've done in the past. You're essentially giving an outside perspective based on your past experience and expertise. It's not up to you anymore, they have to make the call.

Be intentional about how you share opinions. If you're always the first to speak or defend an idea, it'll be harder for others to take ownership.

To be honest, this is something I still struggle with. But… I'm working on it.

3. Wording matters

This is one of those things I've read before but didn't really believe. I always thought, "as long as I receive the message and understand what Person X means, it's all good”.

Boy, how oversimplified that was.

How you express your thoughts, concerns, feedback, and excitement matters. A lot. No matter the context or scenario.

Your wording can change how meetings go, they can affect team morale, lift people up, or demotivate them. You could enter a helpful brainstorming session or trigger an annoying, unfruitful argument.

The impact of your words is often amplified when you're in a management position. Sometimes due to what people expect of you, and sometimes purely because when you are a manager, you do more speaking and less coding - which gives you more opportunities to mess up.

Hypothetical Scenario 1: One-on-ones

Let's start with a simple example. You go into a regularly scheduled 1-on-1 and you lead with:

"Do you have any problems you wanna talk about?"

This is pretty straightforward, right? Could be worse. You're showing concern and are willing to listen. However, this is a typical example of poor wording:

1. It is a yes/no question. People's brains are wired to seek the "right” answer, and in this case the focus is "do I answer yes or no?”
2. It forces a choice of "do I enter a confrontation / tough discussion now?”
3. It is way easier to answer "no”.

Here are some alternatives:

• What's on your mind lately?
• What do you want to talk about today?
• What's a problem I can help with?
• What can we improve in our process?

Notice that with these:

1. The range of possible answers is not just yes/no. People can answer "nothing”, but they are evaluating "nothing” against actual problems they may start a discussion about.
2. They're more open-ended and inviting to a brainstorming discussion - less confrontational.

This stuff matters. You'll have higher chances of starting a meaningful discussion if you phrase your questions in a more inviting and thought-provocative way. It's a skill you can learn - but you need to be mindful of it.

Hypothetical Scenario 2a: Team lunch

Let's try something trickier. You're at lunch with your teammates, and you're in a shitty mood. Life got to you.

Work isn't going perfectly either. You're getting delayed on a feature that needs to get shipped, you slip up, and vent:

"Man, this deadline sucks. It's too aggressive, how are we supposed to ship on time?!?"

Now we're talking. Depending on company culture, this kind of talk may be heard from senior engineers and they may get away with it. You could even argue that a bit of shared venting is a good team bonding exercise (as long as it's once in a while and not a regular occurrence).

But - now that you're a manager, your words carry more weight. Especially if your team trusts you and looks up to you.

You cannot afford to say things like this anymore. You need to be mindful of the negativity you express out loud. Comments like this can:

• Bring down team morale further.
• Make the team lose confidence in themselves (”my manager doesn't believe we can do this on time”).
• Accidentally single out specific people working on the delayed feature - which can dramatically harm your relationship with them.

Things have changed, and this time you have to keep it to yourself.

Hypothetical Scenario 2b: Team lunch

Let's change the scenario a bit. Still at lunch, the phrase is the same:

"Man, this deadline sucks. It's too aggressive, how are we supposed to ship on time?!?"

But this time, you're not the one saying it. A senior engineer on your team vents like this. What do you do?

As an engineer, there's a high chance you'd say something like "Yup, that's insane, wtf".

As a manager, you need to dial it back. Here are some suggestions:

"Yeah, it is a bit tight this time. I think we'll manage though, and we'll make sure this doesn't happen again."

"Yup, I completely hear you, we shouldn't let this happen again. Don't stress too much, let's do our best. Once we get through, we'll take a break, regroup, and reassess."

Notice:

• You're not disagreeing. When the frustration is reasonable, you accept their perspective and show that you understand where they're coming from. You accept their statement and validate their feelings.
• You're reducing the emotional intensity. There's a high chance the situation isn't as dramatic as the venting made it sound.
• It's reassuring - you let the team know it's ok, we'll move on, and improve.

In rare cases, it is okay for a manager to show frustration - as long as it's framed constructively. For example:

"Yeah, I'm feeling the pressure from this deadline too. Let's figure out what's in our control now, and then we'll talk about how to avoid it in the future".

Bonus: Don't forget to code

When you transition to a management role, coding will take a backseat. Especially early on, when you're trying to figure things out, you'll probably be overwhelmed by all the new responsibilities - 1-on-1s, growth plans, requests from people - and you won't really have time to focus on writing code.

However, stepping away from hands-on work for too long is a mistake. It's easy to underestimate how valuable it is to stay technically sharp.

It helps with decision-making

Understanding the technical context helps you ask better questions and spot risks earlier. It will help you in planning discussions - you'll be able to avoid unrealistic timelines.

You'll understand the subtleties of technical architecture decisions and weigh in on tradeoffs. You'll be more confident backing your team when they need time for tech debt or refactoring - and you'll know when to push for active feature development when the timing is right.

Identify dev experience and process issues faster

It's much easier to notice problems with your development process when you participate in it.

Let's go back to the example of Pull Requests taking too long.

It's way easier to notice a process issue when you are actually going through the process instead of just observing from the outside:

• Maybe CI is too slow?
• Maybe people take too long to respond to PRs?
• Maybe people reject PRs just because of a few nits?

Assuming you are an experienced engineer, those issues will stand out a lot more if you're hands-on than if you're only watching from the sidelines.

Writing code - even for side projects, internal tools, or one-off scripts - can keep you grounded.

It's fun

After all, coding is what got you here. You're still an engineer at heart, you just have a bit broader scope now. You should remind yourself what it's like to contribute directly to the product and ship features.

This might be subjective, but I personally find occasionally changing pace from management to engineering is refreshing and productive. It gives you a change of pace, a mental reset, and often a new perspective.

One important caveat: your availability is different now

This is crucial. As a manager, things will come up that you can't plan for in advance. This means you cannot be certain how much time you'll have available for coding. Even if your calendar looks free on Monday, by Tuesday it might be half full.

This means your availability as an engineer is unreliable.

If you commit to taking large chunks of work - especially ones that other people will rely on - you will end up slowing down your team or disappointing them.

Try to take smaller tasks instead. Things you can do in between meetings, or that you can finish with 1-2 days of work are ideal. This way, you're still actively participating, but you won't risk blocking someone for days at a time or slowing down the team's momentum.

---

Final words

Anyway, those are a few of the things I've learned (and am still learning) on this journey from engineer to manager. None of this is perfect or universal - every team and company is different - these are just some of the reflections I've had so far.

If you're making a similar transition, I hope some of this resonates or gives you a bit of a head start.