Hands-On

Ways to stay tech-savvy while adding value as an engineering manager

Feb 06, 2025

Recently I celebrated a special kind of anniversary. My decaversary (10 years) of becoming an engineering manager and giving up IC life! A question I was often asked, after years of managing and mentoring engineering managers, was:

How do you stay hands-on?

This question pops up in several ways. Sometimes it shows up as feedback to managers that they are “not technical enough." Sometimes it causes “founder mode” vs “manager mode” debates. And sometimes it triggers the “should managers code?” question.

The root cause of all these questions and concerns is the same. Many engineering managers (and their managers) worry about losing touch with tech. They get pulled into things like performance reviews, team planning, status updates, team building, and cross-functional alignment.

“Losing touch with tech” is a real issue for engineering managers. At its mildest, it could confuse or stress the team because the manager might commit to the wrong projects or timelines. At its worst, it could make the manager's skills obsolete. It would be a problem if the manager had to move to another company or team. I've mostly seen it as a problem between two extremes. It shows up as the manager's inability to accurately represent their team or guide them to the most impactful work.

But the solution is not to try to do your eng manager job while also trying to do IC work. This will lead to burnout for you and/or cause unnecessary friction for your team.

In today’s article, I talk about 5 roles engineering managers at all levels can take on to stay hands-on while still adding value to their team’s work.

⛸️ Friction Logger

This was a technique I’d followed often, but it wasn’t until my time at Stripe that I came across the term. It involves thorough testing of a journey. It can be a user journey in your product or a developer journey in your workflow. Then, write down your experience. Capture what worked and what didn’t. Also, include clear recommendations to make the journey better.

I recommend doing this exercise periodically on developer journeys. It will help find where your team is facing friction. Then, you can make development easier and faster. Expanding this exercise beyond your team's circle can create a wider impact. You may discover friction affecting more developers than just your team.

Should engineering managers friction log user journeys? Or is that a thing for product managers only?

If you want to advance in your career, you must wear many hats and swap them often. At Stripe, I logged friction for our new embedded components' platform integration. I was able to see how things were from the platform’s perspective through an engineering lens. This helped us all - eng, product, GTM, and more - understand how to make this experience better!

👩‍💻KTLO Analyst

Most engineering teams have many KTLO (keep-the-lights-on) tasks. These take time from other work. A long-term look at KTLO categories will reveal useful insights. You can use these insights for high-impact work.

In the early days of Google Compute Engine, I did a KTLO analysis. It found we weren't releasing every week as we thought. We had many rollbacks, so it was more like “2 steps forward, 1 step backward." The causes of these rollbacks revealed a few themes. We could use them to improve our release cadence. This, in turn, unlocked a major business milestone. A faster release cadence resolved 20% of our technical deal blockers (TDBs). These were features that were blocking new deals.

Here are some more examples of KTLO analysis I've done in the past:

A biannual analysis of our production incidents helped my team gain insights into reliability, leading to investments in projects like fault-tolerance testing and upstream performance testing.
Analysis of bugs reported in the last 3 months revealed our "bug factories," which helped us focus on those areas during design and code reviews.

One more thought on why undertaking KTLO analysis is high-value work. Most engineering organizations suffer from what I call the “infra project suspicion." It is often unclear what business needs "infra projects" will meet. These projects are technically dense, long-term, and preventive in nature. An example of an infra project would be “improve our release cadence." In contrast, "feature projects" have a clear goal: implement this feature. It is often easier to match this to business needs. KTLO analysis helps you support “infra projects” by linking them directly to business goals. In my example, it took almost a year to improve our release cadence. But, mapping it to the revenue it would unlock via the TDBs helped us allocate resources and keep our GM's support.

🚨Oncaller

I highly recommend being part of your team’s on-call rotation! A few ways this will help you and your team:

You will stay connected to the vital parts of your system. You’ll feel what breaks often and recognize what has the biggest impact.
If you are plugged in, you can provide air cover to your team during on-call emergencies that get escalated.
You can also give praise when your team manages important issues well and recognize them for projects that stop potential breakage.
You likely have the least bandwidth on your team. If the team's docs and runbooks don't help you during your on-call, you can take back learnings on how to improve them (see the Archivist role below).
If the on-call experience frustrates you, it frustrates your team too. Or, they may have grown used to it, which could be a problem (normalization of deviance). Treating on-call as a type of friction logging journey will help you make it more efficient for your team.

I have to mention one more reason for being on-call as an engineering manager.

In my early days as an engineering manager, I had taken on a new team of 5 engineers. We were in charge of a critical developer infra used by 1000+ engineers at the time. All my team members complained to me about how intense and demanding their on-call was. I was curious to experience this time sink myself to figure out if I could reclaim some or part of this time for my team.

On my first day on call, I received 23 chat pings. They were all questions about using our infrastructure. The answers were already in our documentation! After the fifth such ping, I wrote a short message like this - “Hi! Thanks for using FooBar. Please visit <link> where you will find our quickstart guide and FAQs to help you get started.” I copy-pasted this message to all the chat pingers for the rest of the day. It was enough to solve their problems. The next day, I added a blurb to our on-call page. It said users should try the quickstart guide and the FAQ links before pinging the on-caller. After that update, I got no pings for the rest of my on-call shift with no noticeable drop in usage or quality of our infra.

As an engineering manager, you have a superpower. You can say no on behalf of your team. You're probably more comfortable doing it than they are. My team was being courteous. We were providing white-glove service to every user. This led to intense on-calls. I switched us to a more scalable approach. It did require saying no to many folks, both directly and indirectly. But it helped us reclaim valuable time. We spent that time improving our offerings. This provided greater benefits to our customers compared to our white-glove onboarding.

🗄️Archivist

Ask any engineer, and they will tell you their #1 problem is documentation. Eng docs are always in need of updates, and there are always better ways to write them. A well-functioning eng team also creates many other docs. These are in addition to design docs and user documentation. Postmortems for incidents. Regular updates for project milestones. Quarterly retrospectives for OKRs. Monthly business review updates. And more. There may be training docs from tech talks, brown bags, and other training sessions.

You can and should create some of these documents yourself. Most eng managers already do this. I’m not talking here about being a document writer; I’m talking about being your team’s archivist. The dictionary definition of an archivist is “a person who maintains and is in charge of archives." You are the only one who can play this role. As the team manager, most of the documentation likely comes to you. You don’t have to read it all, but cataloging and organizing it will be super valuable to your team!

You can take advantage of the advent of LLMs to analyze your archives in a significant way. As an example, one simple thing I did out of habit was to move all relevant docs of a type into a Google Drive folder. So all weekly ops review decks would be in a folder, for example. When Gemini became available in Google Drive, I could ask it all sorts of questions about my ops review data, which spanned weeks!

🛠️Engineericationer

My lack of hands-on experience was acute at Stripe. I had "grown up" at Google, from IC to EM to Director. At Stripe, I directly stepped into a senior role. I did not have the experience of actually building and shipping code there!

I was fortunate to get the flexibility to do an “Engineerication” in my first 90 days at Stripe. An “engineerication” is a portmanteau of “engineering” + "vacation," but it is NOT a vacation! Regardless of your view on the "managers should code" debate, I HIGHLY recommend this approach for quickly learning tech in a new domain. Especially if you learn by doing, this will help you a lot more than reading docs or code.

All the activities I mentioned could be part of Engineerication. However, writing, submitting, and deploying actual code is a key part of Engineerication that isn’t included in those activities.

Here are a few tips for planning and going on a successful engineerication:

Choose bite-sized tasks. I asked around for ideas suitable for first tasks for new junior engineers or interns and got quite a few good choices.
Choose tasks that are not in the critical path. You don't want your team unable to ship a key feature because your one PR was pending while you were off doing other manager-y things!
Choose representative tasks. It's easy to think, "My team uses Ruby, so I'll just do this Ruby tutorial for engineerication." But that misses the true goal of engineerication. The goal is to work in your team's codebase. Do a task someone on your team would do. This will give you a deeper understanding of how things work.
Be vulnerable. If you’ve followed the above tips, it is very likely your tasks are intern/new-grad shaped. You are going to run into issues working on them. And when you do, you’ll likely have to ask the junior team members for help getting you unstuck. Set your ego aside and enjoy the process of learning from them. Reverse-mentoring is a gift. It can help you gain knowledge and connections you'd otherwise miss.
Beginning, middle, and end. You must prioritize your engineerication. to make it meaningful. I found it helpful to have a clear start, middle, and end. This way, I could stay accountable. The junior team members also felt that I valued their time. This also let me limit my engineerication. I could then wrap it up and move on after my timeline or milestones finished.