Estimated reading time: 6 minutes
Feeling distant from the code?
I have always preferred staying hands-on as an engineering manager (EM). This doesn’t necessarily mean writing code every day or even consistently contributing to feature development. But it does mean having a strong understanding of the systems your team owns and maintains, while also being accountable for the quality of the code.
In previous manager roles, I’ve been able to stay close to code largely because I was an IC in the organization before becoming an EM. However, I recently led a team in a high-stakes, ambitious, multi-year project that forced me to take on some non-technical tasks.
A few months in, I realized that my EM responsibilities were shifting. I was taking on new challenges: resourcing the team, coordinating across stakeholders, facilitating cross-team collaboration, among other project management responsibilities, leaving very little time for technical work. To make matters more complicated, my team was starting to work in a new codebase and was learning a new programming language and framework; the more that I was pulled into non-technical leadership work, the more I felt “behind” in my technical know-how.
After a few months of this, I decided to take control of the situation and change my approach, carving out a month of time to get back into deep technical work. Making that shift successfully required a deliberate approach that balanced communication, workload, and proper planning.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Understand your workload
In order to carve out the time to catch up on missing technical context, you need to first identify where you are currently spending your time. For me, this meant enumerating all the responsibilities I was juggling, including meetings or work that took up significant portions of my week.
Once you understand your workload, the next step is to start identifying the categories of work that can be dropped or delegated, and the tasks you have to continue. For example, if you are owning work that a TPM or program manager could take on, that task could very easily be handed off to another stakeholder. Similarly, you may find that some recurring meetings can be skipped or delegated to someone else for a period of time. Other touchpoints can fully happen async.
In my case, I realized that many of our team meetings could be led by the engineers themselves (at least for a little while). I also opted for asynchronous 1:1s with my engineers. In lieu of our usual 1:1 time, I sent my reports a list of questions, such as “What is on your mind this week?” and “Is anything frustrating you or slowing you down that I can help with?” This ended up being surprisingly effective for the one month of my experiment.
On the other hand, tasks like writing performance reviews or engaging in hiring loops for roles on my team could not be delegated to anyone else.
More like this
Craft a plan and set goals
Once you have a clear view of how much time you can realistically reclaim for deep technical work, you’ll need to craft a plan. Imagine you have a month to become an IC on the team – how would you want to spend it? Where do you see your technical deficiencies? What corners of the system are you uncomfortable with? Do you want to spend your time pairing heavily with other engineers on the team, or working independently to understand the domain (or a combination of both)? Answering these questions will help you start to see how you want to spend your time.
It’s also helpful to set a few goals that you want to work towards. For example, my team was learning a new framework I wasn’t familiar with, so I set goals to build a few API endpoints using it. In order to achieve that, I also had to accomplish other goals, such as becoming comfortable with the programming language, writing tests, and resolving static analysis errors.
Finally, you’ll need to set some constraints around your plan. How much time do you need to achieve these goals, realistically? If you are trying to slot in deep, technical work during performance review season, for example, you may realize that you can’t actually carve out enough time to get into the details until later in the quarter. Similarly, if you’re trying to learn a new programming language or framework, you likely need a few weeks to make your time meaningful.
In my case, I determined that four weeks – equivalent to two sprints in our engineering organization – was a reasonable amount of time. Four weeks would allow me to achieve the goals I set out for myself without introducing too much risk to the team or the project.
Communicate your plan
Once you have a proposed plan that you feel confident in, it’s time to socialize it with others. When I shared my technical catch-up plan with my own manager, I received some useful feedback that helped me mitigate some potential risks. My manager and I also worked together to identify additional tasks that he could help with or that I could drop altogether.
When it’s time to share your plan with other stakeholders (such as your product and design partners) and your team of engineers, it’s important to frame your plan with the intentions behind it. For example, when I shared my plans to drop most of my management responsibilities in favor of focused IC work for a few sprints, I explained the decision, the goals I set for myself, and the benefits I saw. Explaining the motivation behind your decisions can help to ground them. You should also be prepared to discuss the risks of your own plan and how you have weighed them; this will help you assuage concerned stakeholders.
Moving forward with your plan
Once you’ve communicated your plan, there’s only one thing left to do: execute on it! For me, this was the most fun part of the experiment; I had the freedom and time to dig into a new system and write code to support feature development. Along the way, I also gained a better sense of the developer experience my team encountered daily; I caught mistakes in pull requests and asked thoughtful questions in code reviews. My contributions to technical design documents and API contracts became more detailed, and pairing sessions became more productive.
Even after four weeks of focused technical work, I continued to pair with other engineers, took on a few small tasks here and there, and contributed code strategically and when most necessary. At the end of the experiment, I realized that some of my managerial tasks could be delegated to others indefinitely, and that some meetings weren’t a good use of my time. In doing so, I freed up more time in my week to do technical work so that I didn’t find myself “falling behind” again.
Deadline: January 4, 2026
Call for Proposals for London 2026 is open!
Final thoughts
Getting back in the code allowed me to become a more effective leader, and while it required a lot of planning, I was able to reverse my drift from the codebase.
Carving out time to prioritize your own technical context isn’t a detraction from your management duties; in fact, it’s likely to pay dividends in the long run. Making the time for that deep work is one of the most valuable investments you can make in your team and, ultimately, in yourself.
