DaedTech

Stories about Software

Mar
20

By

The Coding Dev Manager Can Work, But It’s Hard In Traditional Orgs

Category: You Asked For It

Today, for reader question Tuesday, let’s consider the idea of the coding dev manager.  In my experience, most companies draw a fairly sharp line between individual contributors (they code) and managers (they don’t).  But in startups and Enterprise Silicon Valley companies, you’ll have additional rungs of the corporate pyramid where people still write code.

Who is right?  Well, in my estimation, startups and Enterprise Silicon Valley.  Er, at least, they’re less wrong.  (Let’s talk “right” when we stop modeling our corporate structure after ancient militaries.)

But, as the asker of today’s reader question points out, this still-technical manager struggles to spend much time writing code.  (When he refers to “the book” he’s referring to my book, Developer Hegemony.)

The Reader Question about the Coding Dev Manager

Hi Erik,

I really enjoyed the book. One question I have regarding the efficiencier/partnership model for developers.

In my last job at [redacted], I was leading a large team working with [redacted]. We followed a similar model where we worked with customers on business problems, and then designed the technical solution ourselves (obviously updating them along the way), and then delivered it. As the team lead of the initial project (and eventually the overall engagement lead of 3 projects), I found myself spending less and less time programming. Towards the end it was < 10%.

In your book, you mention that it is possible to still be programming yet work on these other areas, but in my experience the “other” areas end up taking so much time I ended up not really coding. Sure if we have a team full of “T-shaped” people everyone can share various burdens, but from the client’s perspective they typically want 1 counterpart who they can go to to make the final calls. Is this an inevitable fate, similar to section 3 of your book that as the person’s value increases they go further and further away from coding?

Also, a Tweet on the Subject

For a bit of additional background on the subject, check out this tweet from last week.  More interesting than my tweet is the responses, in the context of this discussion.  (None of which I replied to — apologies, folks, I’m terrible at Twitter.)

The doubts in the responses to my tweet are important.  People see the following failure patterns for the coding dev manager.

  • You don’t actually wind up coding (as expressed in the reader question).
  • You kinda do both things, manage and code, and both kinda suffer (Doug).
  • You don’t actually wind up leading (Grant).

And then there are a couple of points that maybe staying “at the top of” one’s tech game isn’t that hard or even necessary.  (I’m inclined to agree with both ideas.)

So overall, what we’ve got is the million dollar question — how can you be both a programmer and a leader?

The Coding Leader: The Base Case of a Proof by Induction

In college, I studied a good bit of discrete math.  This included, rather prominently, the idea of proof by induction.  If you can prove that something is true for, say, the base cases of f(0) and f(1), and then you can also prove that if f(n) is true, f(n + 1) must be true, you can prove f(n) for all n.

Put another way, and with less rigor, you can start your reasoning with a simple case and then expand the thinking.  Can someone be a software developer and also a boss or “lead”?  Well, instead of thinking about it the way that most of us do, imagining a dev manager with 7-9 direct reports coding away full time, let’s imagine something a little different.

Let’s say that you follow in the footsteps of someone like Patrick Smacchia of NDepend or Remco Mulder of NCrunch.  You build a piece of software that you sell, and you earn a nice living at it.  In the initial stages, you are a software developer, a CEO, a sales staff, and everything else all rolled into one.  Here is your base case, f(0), and it works.  You’re both the boss and a software developer.

Now, let’s say that your software/business starts generating enough surplus revenue that you can afford to farm out some tasks.  Maybe you hire a virtual assistant, or maybe you start hiring firms to take care of things like marketing.  Or, maybe you hire a full time administrative assistant.

Now, you spend the overwhelming majority of your time programming (building and supporting your app), but you’re also the leader of a team of 2 or 3.  The second base case, f(1), now also works.

The Coding Leader by Induction

This works.  I promise you — it works.  A lot of people start out as software pros or efficiencers (including many in the book) and take on a staff member to whom they delegate work.  Going from “just you building a thing” to “just you building the thing and someone helping out with admin” is no problem.  I can even speak to this directly, having a VA firm on retainer.

You can go from “software pro with 0 staff” to “software pro with 1 staff” without skipping a beat.  So you can be technical and be a leader.

Let’s now jump into the marginal case for induction.  Say you’re still deeply technical, you’re running a business or department, and you have N staff.  Is there any reason to think that you couldn’t make N+1 staff happen?  You’ve got a fully functional operation with you and N staff, for some N, but it all goes to hell at N+1?

That’s not how life and business work.

I’ll concede that what I’ve done here falls short of inductive proof.  But the reasoning should give you pause.  It should make you question your assumptions.

And, so, for the rest of the post, let’s really blow the doors off of some stock assumptions assumptions about the business world.

“Tech Leads” Should Focus more on “Lead” and Less on “Tech” in Guidance

What does a tech lead do?  Well the truth is, that tech lead is usually a vanity title.  It plays into a world where we comically over-value marginal programming skill.  Usually, the tech lead role exists to provide non-monetary, peacock-esque compensation in lieu of more money or power.  (Though, to level-set a little, it sounds like the reader asking the question had actual org chart authority, but I’m speaking to the general “tech lead” role here.)

Tech lead is a role that we accept with comical sobriety and reverence.  And we think it matters a lot more than it actually does.

We think that “the juniors” would flounder without us showing them design patterns and inversion of control.  We think that they’d be adrift in a towering tsunami of their own incompetence, incapable of getting code to compile without us.

The truth?  Mentoring is important, and they’ll come along faster with your guidance.  But they’ll be fine with you.  Code will ship, if not always smoothly.  Business will happen, if not always elegantly.  We over-value having a “senior developer” micromanaging junior developers.

My point?  Becoming a leader in business isn’t about deciding which Javascript framework the team must use.  That is sound and fury, because it really doesn’t matter.  Becoming (an effective) leader is about something else entirely.

So let’s put our first myth to bed: the one that says you can’t be a technical/coding leader because you have to spend too much time technically reviewing your team.  If you find yourself struggling with that, you’re a nanny, not a leader.

 “HR Stuff” Isn’t Inevitable in the Forms We Think

So, let’s say you’re not wasting all of your non-coding time micromanaging other developers and insisting on making all framework decisions.  What, then, are you doing?  Well, if you’re a card carrying member of most pyramid-shaped corporations, you’re probably doing “HR stuff.”

  • Weekly 1:1 meetings with each of your 7-10 reports, taking up a quarter of your time or, more, if you prep for them.
  • Manager/director-level meetings, most of which involve getting outsiders to leave your team alone, so they can work.
  • Managing a gigantic spreadsheet that puts your group’s projects and your team members into a matrix, with you shuffling 8 hour blocks around like pawns on a chessboard.
  • Idly musing about how to make the previous three things more efficient and less stupid.
  • Oh, maybe coding sometimes!  (But when everyone leaves the office, and it’s almost hobby fare)

That all might seem inevitable, but it isn’t.

Let’s go back to Remco and Patrick.  Or, better yet, let’s take me, running my agency, Hit Subscribe (mostly because I can speak more expertly about it).  I don’t do any of that stuff, and I’ll bet neither do Remco and Patrick.

When my wife and I started Hit Subscribe, I wrote posts for our clients and she edited them.  Since then, we’ve hired something like a dozen authors, 3 editors, and a bookkeeper.  And because we’ve made those hires, you know what I finally have time to do for the business?  Write code.

Seriously.  When I started, I had no time to build out intellectual property, but now I can actually carve out a day per week to automate previously manual processes.  I manage a non-trivial team and have time to write code because much of the standard, corporate leadership ceremony isn’t actually necessary, and I’m not doing it.

The Secret to Staying Technical and Running the Show

Let’s for a moment review the valid objections from the reader question and from responses to my tweet.

  • Acquiring more responsibility in a pyramid-shaped corporation forces more overhead and takes more and more of my time away from technical pursuits.
  • If you wall yourself off in a pyramid-shaped corporation and code, blowing off some of that overhead, both things suffer.
  • If you wall yourself off in a pyramid-shaped corporation and code most of the time, the team you’re supposed to (micro) manage suffers.

Anyone noticing a pattern?

If you are, you probably know the secret.  The secret to being the elusive coding dev manager (or coding manager of any kind) is not to work in a pyramid shaped corporation.  Full stop.

The Efficiencer’s Prerequisite Understanding for Juggling Tech and Leadership

How, then, does it go differently for folks operating outside of the standard corporate model?  Well, the standard model has a long history of optimizing for work consistency in the name of efficiency.  Programmers program and managers manage, and the elusive coding dev manager comes up with some daily split and does that.

But truly leading — building or running a company or department or something — isn’t that cut and dried.  It might require weeks or months of leadership without any programming, during which you make hires, delegate tasks, and make the business more efficient.  Then, when you win back some of your time doing that, you can code.

To do this, and to remain sharp with software through your programming hiatuses requires you to become pretty proficient with software.  But it also requires you not to become bogged down with marginally perfecting the craft.

The secret, then, is to realize that, once you’re decent at it, programming is kinda like riding a bike.  You can stop it for a month, a year, or even more, and still be pretty darned good at it, all things considered.  And, during that month, week, or even year, you can spend time building an operation, an organization, a business, or a company.

Efficiencers, entrepreneurs, hustlers, and leaders in our line of work understand this.  Convincing you otherwise is in the cynical best interests of some (the ones that become opportunists in pyramid-shaped organizations, for instance).  But it’s a myth.

Becoming the Coding Leader — Striking the Balance

How should you go about juggling being a technologist and a leader?  Well, you have plenty of people to look to for examples.  Patrick and Remco, but also Udi Dahan, Oren Eini, Stephanie Hurlburt, and plenty of other impressive people I could rattle off if you’d like to see more.  They’re entrepreneurs, leaders and managers with ongoing impressive technical chops.

But the one key that unites everyone I’m talking about here is becoming a coding leader outside the standard script of the pyramid-shaped corporation.

When you start your own, tech-first kind of firm, you shed unimaginable baggage.  You dictate policies and procedures instead of following them.  Personnel concerns happen for you rather than to you. And you can engineer your business the way you’d engineer a piece of code — ruthlessly plucking out duplication, eliminating waste, and revisiting your assumptions to maximize efficiency.

So how do you lead and stay technical?  Simple.  You do both entirely on your own terms, in the context of your own venture.