I love to code.

Like all passionate engineers; if left alone, I can think of nothing better than to build new things. To create wonderful, elegant, simple solutions.

I spent many man-years on building a CMS from the ground up. I felt like Michelangelo carving David from solid marble - you hopefully know the feeling.

I built many websites based on that CMS - hell, many different companies - and ultimately sold the codebase to a product company. It was beautiful. It was all I did "after hours" for almost ten years.

I probably made $15 an hour.

I don't regret it; I loved the whole process. It was my baby. But it probably wasn't what I should have been doing. It didn't make me rich.

Turns out, beautifully written code isn't all you need!

Anyway, you know all this. I'm not going to blow smoke up your ass about needing requirements, estimation, qa, devops, project management, product owners, market strategy, positioning, branding, advertising, marketing, sales, support, blah blah blah. That's all obvious, but probably someone else's job.

Let's go deeper and more specific.. an effective Engineering team needs coding standards, PR's, architecture reviews, branching strategies, build process, deployment process, staging environments.. that's another very long list.

So far, so good. Yes, as Engineering Director you need to make sure all these things are in place, and humming along nicely. But these are just the table stakes.

So here's the paradox

par·a·dox (noun) : a seemingly absurd statement or proposition that when investigated or explained may prove to be well founded or true.

An Engineering Director shouldn't be coding.

I'll explain why, based on my recent experience, but first please read this current job requirement that I found yesterday:

  • 50% Hands on keyboard development time expected to keep your skills sharp and be able to “Walking the walk” with your engineers

Ignoring the bad grammar (and of course the fact that they can ask for anything, it's their job!), I truly believe this will not get them what they actually need.

Or put another way, if that's what they need (50% coding) perhaps they should title it as Principal Software Engineer, not a Director..

Why not code?

I talked briefly about this before. There are many reasons, but they boil down to this:

  • They've hired better pure coders than you (right?)
  • The company has more important things for you to do

Going back to my personal experience; more than once I've joined a highly profitable small company where I found a working application (sure, with plenty of techdebt, but functional) but with total chaos surrounding it.

Similarities include:

  • ~100 employees, ~20 engineers and not a single project manager or product owner. Ponder that for a second
  • Zero collaboration - one engineer famously didn't even know someone two cubes over
  • No requirements - engineers made all the product decisions
  • No team to speak of. No culture. No trust. A lot of blame.

And often not even the table stakes above - no standards, no branching strategy, no PR's, no release cycle and no deployment process. I think some even called that "Agile" wink.

Luckily both times I had a great boss who was self-aware and a) admitted he wasn't any good at the "fluffy culture stuff" and b) had no problem delegating engineering (and team) improvements.

Critically, there were also highly competent engineers that just needed some support so they could fix the problems that had been bugging them for years.

At those companies, I never even saw the code

Does that make you nervous? Surprised? I didn't need to.

I spent my time focused on the team, and they told me what needed doing.

If you haven't seen my 30 day plan and read my thoughts on the Big Three - Culture, Project Management and Engineering - it's a quick read.

The amazing thing is that if you just setup weekly 1-1's with everyone.. (hold up, this should be highlighted more)..

The amazing thing is that if you just setup weekly 1-1's with everyone, what you need to do next becomes obvious.

You'll very quickly see people who don't fit.
You'll see who to trust.
You'll identify how to improve teams, product, process, environment, culture, productivity.. everything.

That's what you should be doing.