Letting Go of Code to Find Growth
After a career of writing software for 7 years, I accepted the responsibility of leading my first engineering team.
As a newly minted engineering manager, it was my job to enact the process changes and efficiency tweaks I had already been advocating for. I could pave the way for useful cross-team guilds. I would get more face time with our engineers to understand their motivations.
Becoming an engineering manager felt like an additive to what I had been doing. There were a lot of new tools at my disposal; and I was happy to use them. I greedily filled my cup of knowledge as I embraced uncharted territory.
I didn't expect to lose my ability to write code
I was sure I could still devote at least a third of my time to reading and writing code. It would be possible to stay up to date with our codebase, as long as I put the effort in. I was confident I could balance with one foot in both worlds.
To that end, I scheduled myself a monthly recurring "code day" clear of meetings. There were a few product tickets I self-assigned, small ones that wouldn't be missed either way. I told the team that I was doing this to keep up with them. As a way to maintain sympathy with the development process. Below the surface, I was mostly doing this to maintain my skills.
I compared myself with other managers; both at that time and from earlier in my career. Specifically, I was comparing our technical skills. Were others maintaining their technical edge alongside the teams they were cultivating?
Some senior managers still wrote code as a form of stress relief. Other managers, I remember, wrote code because there just weren't enough developers otherwise.
Like some sort of secret weapon hidden behind Jira tickets in the backlog.
Others didn't write code. They were people leaders, project managers and partners across the organization. They greased the wheels and filled in the blanks so the dev teams could keep moving.
A few people had proudly said they could always get their hands dirty— if they needed to. Like some sort of secret weapon hidden behind Jira tickets in the backlog.
The first manager I had didn't let go of his technical side. He burned both ends of the candle; hustling to make sales for the company he built, while foregoing sleep and rest to make designs, and write code for clients' websites and emails.
He would take me aside and say, "John, we eat what we kill." We were lionesses hunting for the pride. We needed to hustle to make things happen. He would say this with bags under his eyes from pulling an all-nighter. I emulated him a few times, burning out with regularity every few months.
The first year
My attitude when I first started managing a team was that I should be doing doing more than 100%. Managing the team day-to-day was an addition on top of what I did as a software engineer. I was striving to be the technical lead and the manager. My motivations were fear and safety.
I was good at writing code. I was a technical leader on the team, at least. I was afraid that if I wasn't writing code, things weren't going to get 'done right'. I was afraid of my team failing; and so I was reaching for the methods I knew best.
My first year as a manager was tumultuous. I couldn't find balance between what I needed to do and what I desired to do. I spent lots of time reading code reviews. I stole moments to write unit tests. I joined in the dev chatter about the latest trends in open source.
My cup was often running over and I was slipping in the puddles.
2 teams, no time for code
There was a turning point when I picked up a second team to manage.
A colleague was having a baby and would be on parental leave. I was craving an opportunity like this to test and grow my capabilities as a manager. I felt I could manage two sets of priorities, two business stakeholders, and two teams of engineers.
I also knew I had to drop code altogether in order to make it work. I figured it was a temporary thing, until I went back to managing one team.
There was no discernable dip in quality. It was going up, actually.
Honestly, it was surprisingly easy to avoid writing code cold turkey. My mind was filled with other logistical puzzles, and I never had time to entertain a line of code. The new team's codebase was fresh and unfamiliar. It would be difficult to ramp myself up to become an efficient code contributor. My original team had plenty of experience together, and needed project guidance, not technical help. Everything was more important than me writing code.
To no one's surprise, features were still shipping. Code was being reviewed. There was no discernable dip in quality. It was going up, actually.
It was stressful managing two teams. I wouldn't be able to keep that up for a year. That said, it was freeing to step away from my code editor.
In time, I separated from my first team and started managing the second team full-time. I had successfully removed myself from writing code at this point.
I repeated to my team what I knew was true, "You're the experts of our code, let me know how I can support you." Every now and then I would slip with a technical assumption. The devs would humble my thinking with their observations and plans for our work. They have my trust.
I'm not the secret weapon
2 years into leading developers, I haven't lost my ability to write code. But it's different now.
I've welcomed the overall shift, because it's allowed me to achieve balance and become a better manager and mentor overall.
My default way of approaching a software problem is as a system of possibilities, anchored to developers who will ultimately find the most pragmatic solution. All I have to do is bring the problem and surround it with context. I have a vibrant team of thoughtful software developers who are the experts.
Every now and then I may dabble in an internal tool to improve the developer experience. I'll forget some syntax here or there, and have to spend more time reading documentation to get back up to speed.
I still read a few code reviews to see how the team is collaborating, but not to stroke my ego as I did before. I try stay out of technical discussions, opting to tag a developer in my place. I've also changed my monthly recurring "code day" to a "docs day", where I read and write documentation, mostly about our team processes.
Each software project is an opportunity to hone our skills. Formerly, as a software engineer, I felt that opportunity knocking every sprint. As an engineering manager, I'm happy to do the knocking.