tech

Staying Technical

Software engineering careers have such a wide range of responsibilities that it’s easy to focus on one subset at the expense of others. As a manager who likes to code, I focus on balancing Individual Contributor (IC) and Manager contributions. Depending on what’s going on at work (PBS), that split can go as far as 75%/25% towards one direction or the other. This post answers a question I’ve asked myself regularly, “How do I stay technical on the management track?”

For Me?

Before investing any of your limited, corporeal seconds in reading this post, do any of these sound like you?

I’m a manager, managing ICs or managers. I understand that it’s my job to support these folks. Understanding software development helps me do that job.

This profile aligns with my own. I currently manage ICs and Managers. How high up the management track does staying technical apply? Some C-level folks, like Evan Wallace, CTO of Figma and creator of esbuild, stay incredibly hands-on.

This post isn’t just for managers, though. Consider these IC profiles as well:

I’m an IC considering a move to management.

and

I’m an IC who wants to empathize with my technical manager.

If any of these voices resonated with your own thoughts, this post is for you.

What is staying technical?

This post’s title presents a misnomer. All folks who work in software product development have some technical skills. “Staying technical” is how I’ve heard it put by engineers on the management path. Some managers gather in groups, lamenting our lack of code-writing time. Our threnody covers either our personal disconnection from source code or the loss of status in the eyes of “real engineers.”

So what does “staying technical” mean? This post on the Pragmatic Engineer’s blog honed my definition. When I say “staying technical,” I mean “building software” on the following diagram:

Balance between management, alignment, and building

We’ve gone from “staying technical” to “building software”. What does “building software” mean?

Writing code

Yep. You knew this would be here. I think about writing code when I think about building software. The code’s scope can be anywhere on the spectrum, from a minor bug fix to an entire service. Later in this post, I’ll write more about finding the proper scope as a coding manager.

Creating blueprints

Instead of writing code, blueprints align engineers on how to build software. The blueprint sets a team’s direction, and the code becomes an implementation detail. Think Architecture Decision Records (ADRs). Staff engineers or architects often create blueprints, but the task can fall to engineering managers too.

What’s my motivation?

Finally, before we dive into how managers stay technical, let’s consider why we’d want to in the first place. Why would someone want to stay technical?

The joy of coding

Developing software, specifically writing code, brought me into the software engineering field in the first place. Most developers revel in the joy of creation. Where there was nothing but a blank IDE screen, we engineers conjure logic and reason from the ether. Coding feels good. Coding still feels good even after eight years of holding a management title at my day job.

Authenticity

Management is about supporting your team. Listening to developers, discussing complex problems, and setting reasonable expectations are part of the daily job. Management does not mean you’re the best programmer on the team. I manage iOS, Android, and web developing engineers at this point in my career. I can’t possibly know Swift, Kotlin, and JavaScript better than every one of these specialists.

My technical knowledge lets me talk to generalized problems, though. My software development experience lets me mentor engineers and relay what worked and what hasn’t worked for me. Staying technical provides engineering managers with the authenticity they can use to support the developers (and managers, who have to support their own developers) on their team.

Changing tracks

As I said at the top, software engineers can do so much in one field. There’s always more to learn, and one of my heuristics for Doing it Right is to make sure I’m always learning. I approach my career as a pendulum between Manager and Individual Contributor. The pendulum doesn’t swing back and forth with a measured regularity, but I continually examine my point on a spectrum. Am I learning something here? Could I learn more by leaning towards technical leadership or individual contributions?

How to stay technical?

Whenever I write “it depends” in a post, I pat myself on the back for being a good engineer. Staying technical may be more difficult for some engineering managers depending on their situation. Some engineering managers may not want to stay technical at all. Here are some ways that work for me in my situation.

Projects at work

These are my favorite if I can find them. Can I code something at work, given my time, technical ability, and access? As someone who has developed software for decades, my experience lends itself to architecture-level decisions. A Director-level co-worker came up with this analogy related to the type of programming work that falls to him as an experienced engineer:

When it comes to writing code, I compare my job as a Director to a Master Plumber. I’m called in at the very beginning when work starts or at the very end when something goes wrong. I’m either installing the initial pipes or resolving an especially gnarly problem.

Those are the two types of work I look for now: initial architectural stuff and complex problems.

After regarding how my current technical ability fits with the task at hand, I consider several more criteria:

When the project lines up, I shift my daily schedule into two segments: maker time and manager time. For me, my best programming comes in the morning. I reserve a 2-3 hour block on my calendar and close Slack/email to give myself time to get into the flow. I’ll schedule my manager tasks like meetings, 1:1s, interviews, etc., outside of my maker time.

Projects outside work

Yay, more work, right? More work isn’t all bad. I’m not saying it’s all warm baths and watermelon, but I enjoy freelancing. I’ve worked with the same client for ~10 years. We’ve established expectations. I write code, mainly on the weekend. They write tickets and prioritize them based on our conversations. Freelancing has been a welcome reprieve after a long week of management. The extra income isn’t bad either.

Freelancing works for me, but there are other paths to staying technical outside of work. Consider OSS and personal projects. The important part is that you get your fix. You’re “building software” and writing code.

Work projects can inform outside work projects but tread carefully. You’re in non-compete territory, but there’s room to navigate. Talk with engineers at work. Are they jamming on CRDTs? If that sounds interesting to you and you can’t contribute at work, pick up a toy project outside work. If money motivates you and it’s a good fit, can you apply CRDTs to a freelance project?

Clubs

By the time we get to this option, we may not be writing code anymore. If “building software” were a conversion funnel for engineers, the end goal at the bottom of the funnel would be “writing code”. Clubs fulfill a purpose at the top of the funnel. As a social, collaborative activity, clubs spawn new ideas for me. These new ideas eventually make their way down the funnel towards improving the code I write.

I’ve started and participated in several clubs at work: #eng-book-club, XR club, Tech Talk Tuesday, and DevDrills (think weekly LeetCode exercises), to name the current batch.

Books

Finally, books create new ideas that I use to build software. Like clubs, reading isn’t writing code in itself. If I’m really trying to recharge my “writing code” battery, reading won’t work. But, if I want to build better software, reading is fundamental.

Reading works by myself or with a group. I started an engineering book club at work. The group introduces books that I wouldn’t choose on my own, motivates me to finish the book, and leads to an excellent conversation about the material.

It’s up to you

Are you out of alignment regarding what you’re doing and what you want to do? I encourage you to ask yourself this question and sit with it regularly. You can adjust the balance between building software, directing strategy, and managing people. There’s a good chance that “staying technical” is possible within your role as an engineer of any kind. Progress, to a fulfilling degree, takes effort.