This is a post I have been thinking about for a long time, but didn’t have the balls [figuratively of course] to write until now (more on why below).

If you are running an engineering organization of 5 or more people, and your product is launched, you shouldn’t be writing code.

Trust me.  I learned this lesson the hard way.

[divider top="0"]

It is important that engineering leaders are technical.

Leading engineers means earning the respect of your team. It means you are capable of understanding and appreciating what they do, and able to steer the ship if it veers off course (which is likely really difficult if you aren’t technical, because how can you be sure they are doing it right if you don’t know how you would do it).

The fact is, technical expertise is critical to job function, which makes many engineering leaders a bit insecure (myself included). 

However, having been burned by my need to contribute as an engineer, I believe that most engineering leaders should not be writing code.  There are some exceptions – you have a small team, or a product that isn’t launched, for example – but if you are writing code at work with a title like CTO or VP Engineering then you likely have the wrong priorities, or the wrong title (yes, I am talking to all the CTOs that are really just senior engineers with fancy titles).

 

Why? Well let me explain….

 

I used to write code everyday.  I liked contributing to the product.  I wanted to be more than a manager, a member of “the team.” 

I don’t know where this desire came from. Perhaps it was my insecurity that people wouldn’t think I was technical if I wasn’t asking hard questions, commenting on check-ins, or demonstrating my technical prowess some other way.  Maybe it was my desire to be liked and part of the “us”. I often feel like organizations have this unfortunate unspoken line drawn somewhere between “us (the engineering team) and “them” (the management and everyone else) – this division sucks, but it seems to be the unfortunate nature of authority in most organizations.

However, in almost every leadership role I have had as the team grows the free time you have to work on your own priorities becomes less and less.

Let me tell you the little story that changed my views on engineering leaders that code…

............................

Once upon a time I was managing a team of about 7 developers.  We were furiously trying to sell our product, recruiting engineers, building new features, and trying to onboard new customers.  It may sound like a lot, but the reality is that is pretty much any startup.

There was this bug that customers had been complaining about, but it was a big change and because of the risk and new features had been deprioritized.  That week I had been on 2 escalations with premier customers about the issue, and I wanted to fix it.

Of course I didn’t have much time during the day (1:1s, interviews, slide decks, RFPs, sales calls, and standard product/software development work, too), so I cancelled all my weekend plans and starting Friday night until Monday morning I coded (I had built a large part of the system initially anyway).  I worked hard.  I barely slept.   I fixed this glaring bug, and I even wrote tests.  I was so proud.

[image source]

On Monday I rolled into the office a bit more disheveled than normal and I couldn’t wait to tell everyone about my triumph. 

I started with the CEO (who was my manager) 

Me: “Guess what I did this weekend? I fixed that awful bug that CusomerA and CustomerB were complaining about last week.”

Him: “I thought that was going to take a week or more to fix?”

Me: “Well it was, but I worked all weekend straight through and got it done." 

Him: “Are you guys padding your estimates that much?  And why would you do that?  I could have really used your help on this RFP for Potential Client. You are an executive, not an engineer.  If I wanted someone to write code I would pay someone a lot less.”

Me: ** walks out of office dejected **

 

Ugh.  That was a blow to the ego. 
A hour or so later I have regained my sense of accomplishment so I go to the senior engineer on the team excited to tell him about what I accomplished over the weekend of hard work.

 

Me: “Hey, did you see the check-ins from the weekend?” 

Him: “Yeah.  I noticed you made a massive change.” 

Me: “I did!  I fixed that issue that CustomerA and CustomerB escalated last week.”

Him: “Seriously?  In one weekend?  How did you do it?”

More conversation ensues as I explain my approach and walk him through the code.  He gives some feedback here and there and that is the end of the conversation.

   

Lunch rolls around.

All the engineers decide to go out to lunch, but no one invited me to come.  This is unusual (like I said I like to be part of the “us”).

A few hours later I pull one of the guys aside (he and I worked together and at company previously and I hired him so we have a closer friendship). He proceeds to tell me that the whole team is irritated with how I fixed the problem, but no one wants to tell me because they work for me.  As you can imagine it is quite uncomfortable to tell your boss you aren’t happy with how something “works” and that you’ve a better plan to address the issue.  Ouch.

 

That night between my exhaustion and feeling like I let everyone down, I cried. 

It was one of the worst days in my career, and all these years I still remember how I felt. 
Not as much because of the fall out (there wasn’t much more after that day), but because I had thought I did something heroic and awesome, but it truly wasn’t work I should have been doing. 
I let my boss down, I let my team down, but I let myself down.

 

After that day I quit writing code at work, and it made me a better manager and leader.

 

I spent my time on helping the business, getting better at recruiting and building teams, and I deferred to my team.  I let them be the experts.  I invited them into the technical discussions when I knew their technical expertise would be necessary to ensure we set informed priorities and put a realistic plan in place.  They grew with guidance in my leadership.  People felt empowered and trusted.  I would help when needed in specific areas – but I didn’t jump in without being asked.  And when I would jump in to help, I acted like a houseguest – asking permission and making sure I only rearranged the furniture the way they wanted it.

 

I still was technical.  I often wrote code on the weekends.  Although the type of work I did is what I call tinkering. I would want to know about a new language or technology, and so I would build little sample applications (typically analogous to a slightly more advanced “Hello, World!”) – just to learn enough to form an opinion.  And I read a lot of articles, source code, and documentation on things that struck my fancy.

And everyone was better because I made this decision.

 [divider top="0"]

So why am I writing about this now?

Well I didn’t write it before because I was a coward.  I was worried people would judge me and say I wasn’t technical enough, or wasn’t a good engineer, and there was some other reason that was the real reason I didn’t write code. 

That isn’t a concern anymore though (since I am working on my own startup). 

I have been coding pretty much nonstop 7-days per week since January 24^th.  And I am damn proud of what I’ve been building.  Besides being a useful product, I would say that the code is better than many popular libraries and tools currently in use.   But mainly I am writing this now because I am not worried about anyone saying I am not technical.  And if they did, well, it really wouldn’t matter.

 

............................

 

If you are in a technical leadership role and feeling a bit insecure about your technical contributions -don’t be.  Chances are you are focusing on the right things – the hard work to move your business forward that no one else on the team can do.

 

Keep up the good work.