You must stop coding, you must keep coding

Our dev team’s grown to twenty-three and when the summer intern zenith hits we’ll be — this is weird to type — forty for a few frightening days.

My biggest personal challenge now, by far: How do you stay connected to a product amidst all this scary m͓͇̘̗a̴̹̠̜̝͖̘n̩͙̘͙̫ͅa̬͙̖̬͍̦͔g͓̼͈͇̙i̪̺̘̙̻͘n͕̠̰̦̗g̗? Do you launch the damn editor? Write a single line of code?

I’ve been trying to squeeze every last bit of advice out of role-models I respect. I’m seeking stories from folks who’ve successfully navigated these waters. From personally writing tons of code in v1 to scaling and managing teams who then receive profuse apologies for all those v1 hacks. If this is you, plz send tips.

Here’re the various mentor voices in my head so far.

You must stop coding. But you must not stop coding. Stay very connected to your product. Make mockups and decisions and docs. Scale your team. Intimately know your tech and your tools. Don’t get out-of-date. Be a coder, but don’t waste time in the code.

You absolutely without a doubt need to keep coding, but under no circumstances should you be coding.

Got it. ✔ Chhhheck!

As confusing as that seems, there is solid agreement for how a technical manager should spend, say, 85% of her time. Scaling, recruiting, empowering, refining some teams’ focus, blah blah blah BLAH we’ve all heard it. Everybody agrees.

It’s the other 15% of the day that’s up for debate. This is that short bit of time when you do something creative that magically keeps you tied to your product and on top of your tech stack and immunized against pointy-haired-boss disease. Some suggest mockups, some suggest small production bug fixes, some suggest adding unit tests, some suggest writing code that you never intend to check in.

There’s leeway here, so for anybody else who’s trying to figure it out, here’s how I’ve chosen to spend my intentionally non-managerial time.

• Fixing small bugs for various teams. From a performance tweak to fixing a x-browser bug. Small, maybe 1 hour of work. I see the code, I make sure my dev tools are up-to-date, I ship, I communicate what I fixed. In and out. I can lightly connect with multiple teams this way.
  
  
• Pairing with somebody for 1 or 2 hours a week. I work with a developer who’s extremely effective at making use of my time if I give it to him. I put a block on our calendars, show up at his desk, and do exactly what he tells me to do. His project moves a bit faster, he steals whatever codebase knowledge I have left from earlier days, and I get to make a difference in our product by following his lead. I don’t personally think this would work if I showed up at just anybody’s desk. He’s unique, I’m lucky.
  
  
• Asking teams to send 1-4 hour dev tasks my way. I’d normally assume that this would overload me and I’d have to turn everybody down, but I’m actually still waiting on these tasks. *wink*.
  
  
• Participating in hackathons. I am excited to run another healthy hackathon this summer just so I can drop my managerial hat, hide in a corner, and hack.
  
  
• Using the weekends. This is a dirty secret. Little management needs to happen on weekends, so I use some free time to hack. Controversial and not a great tip to give everyone, but it’s important to me.
  
  
• Shutting myself away for a few days and coding a small feature. Last time I did this? Months ago. Last time I did this without feeling that I’d shirked more important duties? Over a year ago. I no longer think it’s wise. “You must stop coding.”

Rands’ Technicality is the authoritative piece on this search for maker/manager balance. He opens with “Stop coding.” By the end he commands, “Don’t stop developing.”

What’s clear is these waters are murky. Any good technical manager must go through the difficult transition from coding to spending almost their entire day empowering smarter teammates. But how you maintain that certain je ne sais quoi that separates you from the non-technical manager you never want to be is a pretty personal choice.

Me? I have to launch the damn editor. Just for 30 minutes. Not to code, but to code a single line.