
Somehow I Manage
Thoughts and reflections after my first year as a manager
Wed Aug 05 2026
It’s been about a year now since I first stepped up into engineering management.
I wanted to write this article to share some honest thoughts and reflections on the experience so far.
Your Job is the People
When stepping up the engineering ladder (junior, mid-level, senior engineer), you mostly acquire seniority and responsibility. The fundamentals of your role don’t really change. Your primary job is still the day-to-day delivery of technical outcomes. Each step up feels like a natural progression in the role.
When taking the step up to manager, however, things are a bit different. You’re no longer just responsible for the technical piece; you’re now responsible for the people. Their happiness, their drive, their motivation—all of these things that you have no experience with whatsoever—are now your concern. Your engineering background hasn’t taught you how to give performance reviews, do weekly 1-to-1s or align a team behind a shared vision.
The role has fundamentally shifted. You’re no longer meant to be getting stuff done; you’re meant to be running a team that can get stuff done. At first, it was really hard for me to stop picking up tasks from the board. I needed the dopamine of moving a ticket into “Done” to help me feel like I was accomplishing something in my work.
A few of my takeaways:
- Avoid the busy jobs. When those annoying BAU tasks come in, don’t immediately jump on them yourself. Learn to drive change as a leader to make these tasks easier or non-existent in the future.
- Learn to delegate even the big tasks. You’re no longer a senior engineer. You may be responsible for the tech, but that doesn’t mean you have to build it all yourself. Let your senior plan the architecture for that big new feature. You’ve been promoted to this position because you were great at architecting in the past; now train your team with your expertise.
- Always make time for your team. They are your primary responsibility now. If you’re not making time for them, the team becomes dysfunctional and the tech falls behind.
Ownership & Responsibility
Congratulations. Your head is now firmly resting on a chopping block. There’s likely an entire technical product (or component of a product) that you are now directly responsible for. Any outages, missed deadlines or bugs in this system will directly reflect poorly on you.
Although this seems like a stressful burden, the quicker you learn to appreciate it for the blessing it is, the better. Diamonds are forged under pressure. Your employer is giving you a unique opportunity to show how much value you can bring to the organisation and take a big step up in your career. To quote DHH: “The responsibility is the reward.”
You are also becoming a relationship manager. The team or system that you are responsible for probably has some name associated with it that everyone else in the organisation will use when referring to it. A huge weight on your shoulders will be making sure that name is referred to in a positive manner. You don’t want to be the team that everyone hates having to work with: “Ugh… we have to talk to X again” or “Maybe we can get this done with X since they’ll slow us down.”
Stress Management
A few months before becoming a manager, I also became a father. So, in 2025, my responsibility levels skyrocketed. I went from late-night takeaway and gaming sessions to zero-sleep nights followed by a day of important meetings running well after 6pm. In the first three months, I struggled. Stress levels went through the roof. I would often find myself lying awake in bed, struggling to fall asleep.
This became even more frustrating as I fell victim to comparison. Why were other people managing this so much better than me? People with far more responsibility (and more kids!) seemed to be breezing through life and having a great time.
Relationships
For me, I found that stress was very driven by relationships. I was never stressed by the quantity of work I had to get done, but by whom I would disappoint if it wasn’t done. As an engineer, I had so few relationships that it was easy to keep everyone happy, but now, in management, my network was growing and there were more eyes on me.
The crux of this issue is that you can’t keep everyone happy. Many decisions I made would make people unhappy, and each of those would weigh heavily on me.
This is still something I struggle with, but I’d say there are two realisations that have helped me thus far:
- Are people really as disappointed as you think? The key thing to realise here is that everyone else has loads of other relationships as well. The likelihood is that someone else is disappointing them more…
- Keep the people you’re pleasing front-of-mind as well. There are (hopefully…) some people who are super happy with what you’re doing. Let their energy drive and motivate you.
Physical
There is a more physical element to stress. If I’m ever feeling too stressed, I ask myself: Am I eating well? Am I sleeping well? Am I exercising enough? Over the previous year, my answer to these three questions was often no. These are the first three things to sort out before diving into anything else.
Love the Outcome, Not the Process
Like myself, most engineers are hands-on coding nerds. We love sitting with a blank page in front of us and writing some code. But this is no longer how you bring value to the organisation. I touched earlier on how the role shifts, but now the question is: How do I stay motivated and driven, given I’m no longer doing that thing that I love?
I believe the answer here is to be outcome-driven. Your elevated position of responsibility and ownership now gives you a unique opportunity to really own the outputs from your team. A huge success from the team now reflects well directly on you, so let that be your drive.
Make your goal to get that new feature running in production, whatever it takes. Notice this is a subtly different goal from writing good code. Getting sh*t done is an art that involves so much more than writing code.
Being outcome-driven is also what’s going to drive your career even further. As you step up more, you’ll take on even more responsibility and be even less hands-on with day-to-day processes. At this stage, taking joy in the actual achievements of the whole team is the only way you’ll find satisfaction.
A Healthy Amount of Hands-On
Somewhat related to the previous section: should I write code anymore?
I believe that the answer to this question is unequivocally yes. Anyone hoping to lead a technical team needs to be hands-on with the nitty-gritty day-to-day of writing, reviewing and deploying code. If you don’t do this, you’ll quickly lose touch with your team. You won’t understand their complaints about certain parts of the system or the processes behind them.
You also need to lead by example. As discussed earlier, you were promoted to this position for being a great engineer. Now you’re being trusted to show other people how to be great engineers. So show them what you mean by a good pull request. Show them what it means to add test coverage and be fully production-ready. Your engineers won’t know how to—and probably won’t want to—follow you if you can’t walk the walk.
Okay, let’s be honest. It also gives you an opportunity to reconnect with your love of coding/engineering. Always a plus!
Focus and the Unending To-Do List
Management is the first point in your career where the to-do list is going to grow faster than your actual output. Sure, as an engineer, there are some crunch moments, but generally, you deliver your tickets in that sprint and, if not, you readjust your estimates for the next sprint.
Now, people from other teams are simply going to throw requests at you mercilessly. Since they’re not in your team, they’re not going to understand that you’re busy with more important things. What does “more important” mean anyway?
Prioritisation is key. But you must be the prioritiser. Sure, you probably have your own manager who you can run things by, but you need to have a clear picture in your head of what is/isn’t the priority. Be ruthlessly brutal with your prioritisation. Lack of clarity and focus will kill productivity for you and your team, so be clear and direct when you say no to something. Never delegate prioritisation because, as soon as you do, you will lose control and the team will suffer.
Conclusion
My first year as a manager has been great.
Learning to love the process, embrace responsibility and bring stress under control has helped me grow more in my career over the past year than any other year before. The challenges discussed energise and motivate me rather than worry me. I’m super excited to discover and grow more.