Stories about Software


A New Way to Measure Software Careers

How do you measure the progress of software careers?  I don’t mean rhetorically — give it some thought.  As a software developer working your way through the workforce, subconsciously optimizing for AMP, how do you evaluate yourself?

I can think of some things that probably flash into your head:

Maybe you have others.  Weigh in below in the comments if so — I’m honestly interested to hear.

Anyway, today, I’m going to propose a different one.  At first blush, this measure seems kind of binary.  But I think there’s actually a subtle continuum, and this post will explore it.

So, how do I propose we measure progress in software developers’ careers?

Simple.  Your career is as mature as the degree to which you control the decision about whether or not to write software.

What Does It Mean to Decide Whether or Not to Build Software?

Before I get into the progress spectrum I mentioned, I should probably justify my assertion and elaborate a bit.

First of all, when I talk about the decision about whether or not to write software, I don’t mean it in some kind of granular, micro-sense.  I don’t mean that you have the autonomy to decide whether to roll your own logger or to use Log4j.  I don’t even mean that you’re an architect and you can push back on the business about technical feasibility in the short term.

No.  I mean that you make the business decision about whether or not to write software.

For instance, say you’re a free agent that specializes in helping mom and pop retailers establish an online sales channel.  When Mom’s Gourmet Macademia Nuts calls you and contracts you to help, you decide whether to build a custom web app, use Shopify, or send them to Etsy.  (Or whatever — this isn’t exactly my forte.)  Mom asks you for help, and you decide whether or not writing software should be part of that help.

Or take me and my content business, Hit Subscribe.  In order to earn my CTO designation on LinkedIn, I’m handling the business’s technical decisions, including whether to delegate tasks, automate them with off the shelf products, or build custom automation myself.

That’s what I mean about the build decision.

What I’m Describing Sounds Like Management, But That’s Actually Silly

One last point of order before I dive into the continuum of software career progress.  If you think that I’m declaring water to be wet — that of course you mark software career progress by getting close to this decision because that means you’re getting closer to management — let’s take a look at the logical implications of your assumption.

You’re thinking that the decision of whether or not to build software is best made by management.  In other words, the decision about whether or not to build software should not be left to software developers.  There are two categories of people: those who build software, and those who know whether or not building software is a good idea.

Do you seriously believe that?

Does a surgeon need a “surgeon manager” to tell her weather or not to perform surgery?  Does a plumber need a “plumber manager” to decide whether or not to replace your toilet?  No.  In both cases, this is absurd.

But, does a construction worker need a real estate developer and a general contractor to tell him whether or not to build a wall somewhere?  Yes.

What’s the difference?  The difference is that surgeons understand surgery and plumbers understand plumbing.  But construction workers do not understand commercial real estate.

So ask yourself this.  Do software developers understand automation?  Do they understand the domain in which they’re writing software?

Actually, it kind of varies.  Some do, some don’t.  And, because of that, doesn’t it make sense to evaluate your level of progress in the software world on the basis of whether or not you understand why you’re doing what you’re doing and the degree to whether or not you can weigh in intelligently?

Of course it does.  So here’s the continuum.

Level 0:  Your Boss’s Boss’s Boss is Part of a Steering Committee… or Something

At level 0, you’re a cog in some gigantic enterprise.  You clearly do not make the decision about whether or not to build the piece of software that you’re working on.  But not only that.  You don’t even know who does make that decision.

You understand in the broadest, most abstract of terms.  “The steering committee” or “the program” or “the business” or something.  They make the decision.

I don’t care if you’re a wet-behind the ears, entry-level programmer or some kind of CoderNinjas.com black-belt bracket-warrior of Github mastery or whatever.  If the build or not decision is made this far from you, you two are exactly the same as far as your company is concerned.  Any company with enough scale to abstract the decision this far from you has enough revenue to make “$50K salary vs. $120k salary” a few orders of magnitude less than a rounding error.

Mark your progress as a zero.  The only way you get a whiff of non-zero is to stop programming and spend 20 years managing.  Go somewhere else.

Level 1: You’re in Contact with the Decision Maker

Next up, at level 1, you at least knows who makes the “do we build this software” call.  It might be your boss’s boss or maybe even her boss, but it’s someone that you pass in the halls and know by sight.

The odds that you’ll be able to exert any modicum of influence are pretty low, but at least you have line of sight.  There’s an outside chance that you’ll at least be heard if you discover that the product you’re helping to build is actually a terrible idea.  But don’t count on it.

Mark your progress as a one.  If you become an indispensable programmer or a line manager after enough years, you might start to have regular influence on the build decision.  But you’ll get pretty gray waiting this out.

Level 2: Your Boss Makes The Decision

Now, we’re getting somewhere.  It’s not an unapproachable VP or director that makes the call, but rather your boss.  You have a relationship with your boss, and one over which you have a great deal of your control.

Of course, there’s a pretty good chance that your boss, the manager of app dev, isn’t consulting you on decisions about whether or not to build a piece of software.  But your boss is making this decision, which means that your group/team, collectively, has a lot of input into the business.

This is promising!  You have a lot of options for impressing your boss.  If he values technical acumen, you can work on that.  If he likes good presentations or excellent time management skills, you can work on those too.  In short, you can figure out how to land the boss’s ear and thus to have a bit of say in the decision.

Mark your progress as a two.  You don’t have direct influence, but you can acquire a meaningful say within months, rather than years.

Level 3: You Influence the Decision

At this point, the progress is obvious.  You have the ear of whoever it is that makes the build decision.  It could be that a VP just really personally likes you, or it could be that you’re a small shop where a democratically-minded dev manager listens to smart folks.  Either way, you feel pretty confident that you could bring about a veto of a terrible build decision.

Others in the organization can, of course, easily overrule you.  You don’t truly own the decision.  But you have a seat at the table every time there’s a decision to be made.

Mark your progress as a three.  You’re a meaningful part not just of software creation, but of the business of creating software.

Level 4:  You Make the Decision

You own the decision.  Since this post is about software developer careers, you’re obviously still involved in building the software.  But you also own the decision as to whether or not to build the software.

This might be the result of you being the technical founder of a small, sustainable app-based business.  Or, maybe you’re a technical consultant.  If you’re still in the corporate world, perhaps you’re in the sweet spot of working for a company that’s relatively flat, but lets dev manager types code.

Whatever the case may be, mark yourself as a rare four.  You’ve hit the apex of software careers.  You build software and also have deterministic say over whether or not what you’re doing makes sense.  This is the height of being a professional and an authority in your field.

Optimize of this Measurement of Software Careers and Reap the Benefits

You’ve probably noticed something by now.  If you optimize your career for making progress according to these levels, you’ll almost certainly find yourself working at progressively smaller companies.  I don’t deny it.  As any reader of Developer Hegemony knows, I believe that the future of software development as a profession will see an exodus from massive, pyramid-shaped organizations and massive displacement into smaller, nimble “efficiencer” firms.

But I don’t offer this as some sort of evangelism of my future predictions.  Rather, I offer it as career advice for software developers serious about the business of software.  Do you want to look back on your career and summarize it with, “seems dumb to me, but they just pay me to code up the spec?”  Or do you want to look back on a career where you were an expert in the business of software, automation, and a domain, and where you make expert decisions and give expert advice in that capacity?

If it’s the latter, then you have a new career path.  Forget the blog posts about which client side framework will be most marketable in 2019 or which silly interview prep site of the month will give you the inside track to Enterprise Silicon Valley.  Focus on career moves that bring you closer to deciding for yourself whether or not to write code.

newest oldest most voted
Notify of
I like this metric. It’s a pretty good way of condensing AMP down to a single factor, and it leads to some interesting implications: 1) While I used to think that Big Tech companies would do well on this metric, I’m not so sure anymore. Yes, they pay well, and there is some prestige by association, but I am beginning to expect that many people in those companies face plenty of barriers to exercising this sort of discretion. 2) There are many different paths that do well on this metric, so if you find you are blocked on one path,… Read more »
Erik Dietrich
I agree that the different paths by which you can arrive at this situation is important. It can account for a variety of satisfying (or unsatisfying) arrangements. Off the cuff, and at the risk of sounding cavalier, I might just ask directly during the interview. “You hear all the time that it’s just as important to build the _right_ software as it is to write good code. How much say do engineers here have in decisions such as whether this is the right software or not and to veto a particular feature?” This modulo more careful phrasing, but I think… Read more »
I’ve been considering whether just asking directly would be a good idea. I like the general direction of your phrasing, especially how you preference it with “building the right thing” vs. “building it right”. I suppose it depends in part who it is you are asking. If you are asking the manager, they may not want to cede authority prematurely and hedge (though a mature manager recognizes the value of engineers demonstrating initiative). There’s also the more indirect route such as “how are product roadmap/feature decisions made?”. If there’s a dedicated product owner/manager, how closely do I work with them?… Read more »
The decision whether or not to build software could also be whether to write it or to buy something of the shelf. But I guess still a ‘needs software’ decision, and there’s no such thing as off-the-shelf that needs no configuration 😉 Prior to that, there is the decision that you have something that requires a software solution. Who is the person deciding that there is some challenge worth addressing? Am I making a distinction that doesn’t exist in your model? Is it valid? Or is this the same person who decides whether the software gets built or not and… Read more »
An interesting watch regarding autonomy (and motivation in general) in the work place is here: https://www.youtube.com/watch?v=rvEbDzg6EhQ Essentially, this game development shop broke down autonomy into three parts: team, task, and technique. Developers and other creative professionals could choose: 1) What they thought the most important problems to solve for the company (by choosing their team) 2) What the next important step in solving that problem was (by choosing what task they were working on) 3) How they could solve the problem (by choosing their technique for solving it) What’s perhaps most interesting is the pragmatic approach the management took into… Read more »