Managers, Developers, & the In Between

We can – and we must – change what “career success” means for software developers.

Part One: Marking the Paths

“I love my team, but I’m a bit jealous of them, too,” Jeff said, fiddling with the edge of his coffee cup. I hadn’t seen him in a few years. Last time we got coffee, he was building a little startup and enthusing about node. In the interim, his company had found a business model and made enough money to hire a few other devs.

“They’re actually all great, even the junior dev I hired. Product is super pleased. They’re working on stories, making progress…” He trailed off. “They get to write code all day. I’m in and out of meetings all the time. I answer a quick question once in awhile.” He paused. “I was supposed to have one day a week to write code.”

Jeff and I did our computer science degrees together, back in the day, and have seen each other every once in a while since then to catch up. For a long time, when I met up with him (and other college friends), we’d talk shop about code. I really loved it, particularly when I was working at a place where my co-workers weren’t into that kind of thing. As the years went by, though, many of my college friends moved away from actually developing software. Most went into management.

Jeff had been the last holdout.

The Dilbert Divide

Before we get too far into this discussion, I’m going to be specific about my definitions of “management” and “development” here, because in the hallowed tradition of Dilbert and Office Space, we often perceive a wide and obvious divide between them. The reality at smaller companies [1] is that the divide is rarely as wide or as obvious as in fiction. All jobs are somewhere on the spectrum between Dilbert and his pointy-haired boss.

So rather than setting up precise definitions with crisp lines, we’re going to divide the jobs that orbit around the production of software as follows:

You’re in development when your job focuses on code.

• You care about the product, and the people, and the process (at least I hope you do!), but mostly you care about them in the context of their relationship to code.
• A significant part of your job is looking at, discussing, writing, and changing code.

You’re in management when your job focuses on things other than code.

• You’re focused on the product, or the people, or you’re off doing executive stuff like fundraising and strategy.
• You may still mess around and experiment with code, but it’s no longer the main thrust of your job. You’re “higher-level.”

Jeff is firmly in camp two; I’m firmly in camp one. My other school friends are somewhere in between. At a smaller company you’re likely to transition slowly between them, perhaps not even noticing when the polarity switches.

Why does this happen?

Jeff could go back to an “individual contributor” role at any time. But he doesn’t, because despite wistfully wishing for code time, he actually enjoys being a manager.

It took me an embarrassingly-long amount of time to figure out that management is not all tedious meetings and spreadsheets. I seriously used to wonder why anyone would take that promotion. Then I got to a certain level of seniority, and suddenly the advantages of becoming a manager over staying a developer were very clear:

Or is it the other way around?
(image from 30068822@N04 on Flickr)

• Management pays more.
• You get better business context for the company’s technology.
• You feel like you’re leveling up your career.

Without business context, you’re always surprised by direction changes. That gets old.

Without more money, you don’t feel like you’re being rewarded in proportion to your value. And here’s some realtalk: babies are expensive. Five to ten years in is when most developers make the transition to management. It’s no coincidence that right around then is when many also start considering a family.

Without that feeling of progress, you feel stagnant. And that’s the crux of our dilemma. Management is the only obvious way to keep advancing once you’re a senior developer [2]. This applies both inside individual software development companies, and across the industry in general. There really aren’t other clear options.

This comes from the (usually unvoiced) assumption that actually writing code is a lower-level activity [3]. People seem to think that the difficult work of building a product is done elsewhere.

You can see this when you look at articles on developer career paths, like this answer on Quora, which essentially says “Of course, developers who want to keep advancing will leave development and go into management!”

What else is there?

I’m Glad You Asked!

Some folks would love to keep programming; others would love to manage people, or the product. Different developers have different ideas about the most interesting and challenging work to engage in, as they get more experienced. But pretty universally, it seems, we all want to make more money, have more business context, and feel like we’re advancing. Personal satisfaction is important. We need to offer developers more choice, and more guidance, for navigating the first ten years of their career.

You’d be forgiven for thinking that the only path “up” is into management. In reality, doable non-management career paths do exist, and have always existed, in some form. But they’ve never been marked. We’ll do that in a later part of this series. In this part, I want to set the context: why do the paths need marking? Is this all my sour grapes that no one marked them for me? 🙂

I’d be lying if I said that didn’t figure into it. But I’ve been thinking about this for a very long time, as I’ve seen my generation of developers cross the magic “senior” barrier and, mostly, disappear. I’ve realized that there’s more at stake here than personal satisfaction. The one-way moving sidewalk from developer to manager hurts our teams, our companies, and our industry. It’s holding us back, and we need to do something about it.

Consequence 1: Most Managers Suck

We need people in management who are actually interested in managing people. Right now, we mostly get people in management who want to be promoted.

Some folks who want to be promoted are also actually interested in managing, and will eventually learn how. Too many never do, though, and become liabilities who chase away their reports (see photo). Unskilled managers are the primary reason people leave companies, though you’ll never hear that in the exit interviews.

This is a problem for your community. I have a brilliant friend who had been working on a Ruby project under a bad manager. She changed companies to get a good manager, but it meant switching to .NET. She was reluctant at first, because .NET is so much more “corporate” than Ruby, but she did it, and she’s never been happier. That’s a huge loss for the Ruby community, due entirely to one bad manager.

I’ve heard similar stories from people who leave the industry entirely. We’re losing great people because our managers are incompetent. Let’s stop promoting people who aren’t ready to do the work.

This is a problem for your business. Even bad managers are usually adept at managing people very similar to themselves. Bad managers can go along for years, with nobody realizing they’re a problem, when their team is homogenous and demographically similar.

However, when the team starts to diversify, if the manager is unskilled (and particularly when they don’t realize it), they can’t adjust, and end up chasing all those people away. Trouble retaining diverse developers is a big blinking neon sign saying “bad manager”.

When you’re stuck with a homogenous team due to unskilled managers, you’re severely limiting the range of ideas you can generate. These days, that is a huge liability.

Consequence 2: Slow Progress in Software

Despite the fact that programming has existed as a real career choice for over fifty years, our understanding of how software is built is still pretty primitive. We’re stuck in old industrial-age metaphors (even “product” comes from the industrial idea of something physical that can be picked up and “shipped” somewhere) [4]. These metaphors have certainly helped us develop our industry, and they still apply directly to some projects. But the industrial metaphors are starting to show their age on software-only projects, particularly in services, and we’re only just beginning to understand what replaces them.

There are lots of other interesting problems like this, where it seems like our old approaches are just now starting to wear thin:

• Concurrency, or more generally, distribution: how do we do more in the same unit time?
• Cryptography: how do we make information available to those who need it, but not to those who don’t?
• Architecture: how can we structure our projects to best take full advantage of the team we have?
• Process: how can we reclaim autonomy and control over our work in an industry where “agile” is most often a tool of top-down corporate control?

Our industry has so much empty space we haven’t even started to fill.
(image from mallix on flickr)

Like everyone else, when I was early in my career, I bought into the assertion that ambitious people leave programming behind as soon as they can. I figured I’d leave once it got boring.

Well, after twenty years, it still hasn’t gotten boring. I’m still finding new insights that I didn’t have the breadth of experience to understand even ten years ago. That’s not because I’m a particularly slow learner, I think; there is just a lot of stuff still to figure out here.

It’s exciting to see that new vistas are relatively close at hand. But I can’t uncover all of them by myself, and people who aren’t hands-on-keyboard can’t help. We need more experienced, active developers so we can explore richer methods of programming, and advance the state of the art.

But we live in a world where the people writing the code mostly have less than ten years of experience. We’re capping off what we can learn pretty low. No wonder real progress has been elusive.

Solutions

We have a whole host of reasons to find some way through this maze. If we solve this puzzle, we can:

1. Offer individual developers more choice when they’re advancing their career. This opens up longer-term participation to more people, enabling us, as an industry, to do more (and more interesting) things.
2. Increase the quality of our management by ensuring the folks going into it actually want to be there. We’ll lose fewer good people and get better at managing diverse teams.
3. Quicken the pace of software innovation by keeping more people writing code longer.

The rest of this series will explore how we make this change. Some of the change we need is organizational, some is technical, and some is philosophical.

It is all possible.

End notes

[1] The larger the company, however, the more polarized jobs become. back to source

[2] At least at companies without an individual contributor track. Some people come out of school, take a job at a Large Co., and stay there most of their careers. Large Co. usually has a “technical” career track that parallels the management track. This allows them to continue to advance while keeping their hands on the keyboard. It’s a neat idea, and for folks who can stomach working at the same place for so long, maybe it works. I’ve heard mixed reviews. back to source

[3] I’ve been writing and speaking quite a bit about how we have outgrown an industrial/factory model for software development, in which a developer is akin to a replaceable factory worker. Here’s a blogish thing I wrote, and the slides from my talk at SCNA on this topic. back to source

[4] As mentioned in note 3, this has been the main thrust of my research and speaking lately. I’m currently filling a few more vacancies for conference keynotes and short-term consulting gigs for 2016, so if that’s of interest, please get in touch. back to source