Saying Goodbye to Code & Control as a Manager

Last week I caught an episode of Taylor Desseyn's stream with guest and friend, Jem Young (@JemYoung). There was a variety of topics covered but one comment in particular stuck out. Jem shared the difficulties of giving up code as a manager. If there is any particular experience that I remember during my transition to manager, this was it. In launching this site with the intention to begin writing more I knew this would be a great kickoff topic.

4 years ago I decided to make the jump to engineering management from individual contributor. It was an accidental stumble into it based on the needs of the company. Early on I split my time down the middle between code and management like many before me. It became quickly apparent that I was setting myself up to fail. I sure did try though.

Working extreme hours to cover both sides worked briefly for me but quickly led to burnout. Burnout is far from ideal with an ever growing list of todos. After coming to terms that I wasn't going to be able to code like before the process began to start offloading work. To keep myself happy I would pick up tickets as I could.

It was a step forward but the approach was flawed. I gave up being the owner of the work but still wanted to control over how it was done. Wanting something your way leads to one inevitable outcome — micro-management. It's an awful management style and I regret putting my team through it early on. The tickets I did attempt take on were not typically low hanging fruit. It was business critical work and I put myself right in front of yet again. This part of the story went on for some time.

One day the product owner, one of the best I've worked with and respect deeply, sat me down to share some hard feedback. The feedback was clear and straight forward. I was holding the project up and the work I was able to complete was subpar. Ouch. Quality is an extremely important value in my work.

I called a team meeting to share what was going on. The words slowly rolled out of my mouth that I wasn't doing well as a new manager. What I shared was framed as a balance problem and that's it. I wasn't quite ready to admit openly that I was afraid to give up control. It was the first time I was open with myself and vulnerable to my peers about my shortcomings even if it was only part of the story.

What I hadn't figured out quite yet is that I did not trust the rest of the team like I did myself. What's interesting is that it did not matter if they could or could not be trusted. It was an ego driven pattern of thinking that no one could do it quite like Dan.

During a later 1-on-1 with my boss at the time I shared my struggles with code vs management. He jokingly said “told you'“ as I was warned early on that this would happen. His followup was a simple question — “is X person a good engineer?”. Without much more conversation I knew where I was being led. I had lost sight of the experience, skills, and culture of the team. My ego had gotten the better of me.

The team was made up of engineers with proven track records. Why wouldn't I trust them?

My approach has since become giving full trust from the start. Everyone makes mistakes, including me, but until then trust stays intact. Mistakes aren't inheritently bad until they happen again and again. That's when trust starts to break.

While I do miss coding the learnings were clear. There is no way to scale performing both responsibilities let alone do both of them well. The team's role is to handle the code and mine (among many) is to trust and support them in that. What was required was a clear shift to enabling the team do the same thing I once did but better. It was in the best interest of the company, the team, and myself.

There will be many things beyond code that you have to give as a manager. And that's ok. Your instinct will be to hold on tighter but I urge you to do the opposite. What your team needs is your trust and confidence. They need the freedom to succeed. Most importantly they need you to believe in them and their abilities. Once you do that you'll find giving up code, control, and just about anything else becomes second nature.

Update: I joined the Front End Happy Hour (FEHH) podcast recently to discuss this topic in more detail that you can check out here.

- DD