It’s pretty obvious why you would pay an experienced (and skilled) software developer more than a fresh graduate. Beyond that, if you’re working for a company with a great hiring ethos, differentiating engineers by relative ability becomes murky remarkably rapidly. I remember working with a particularly gifted graduate in a large company that used a fixed 3 year pay scale for graduates, and wondering why she should be restricted to a graduate salary when she was obviously outperforming many others.

Like it or not, there is value in having a concrete way to rank software developers. It serves as a checkpoint for salary bands, and also helps developers to understand what they need to do to be “better” (aka paid more).

There are a number of pre-canned “software developer maturity models” around the place. Urban Airship published their tech ladder, which is well written and has the bonus of mapping technical roles onto equivalent management roles – this really speaks to me because I’m a huge fan of the non-managerial technical career. Jin linked me to another great article about “mature” engineers (as opposed to gifted, but inexperienced engineers), which also pushed my “nod nod” button.

I’ve had this nagging feeling that there was something missing from all of these models. It’s taken me a while to put a finger on what it is.

Making Smiles

Having spent a fair bit of time as a manager of developers, there’s one really simple sign (for me personally) that developers are growing: smiles. Those little smiles that I get when I’m hopping in my car after a day at work, or reading an email, or watching an interaction. Those little “wow, yeah, that’s the behaviour I’m looking for” moments.

It’s not that I don’t smile at other times. I love hearing about how someone used throatwhistle.js* to solve a tricky problem, or how they Capistranoed the Puppet onto the SSH. But the thing is: coders be coding. Getting better at technical tasks is simply how you do your job, not how you become a better software developer.

If I think back on those private smiles, there is one common factor behind them: responsibility. They are the moments where I’ve seen a developer moving from one level of responsibility to another. Perhaps a developer has said “hey, I’ll deal with that customer query, don’t worry about it”, or maybe they are pre-empting my thoughts by emailing another developer about an impending dependency that has an unclear delivery date. Fantastic!

These are the times when I’ve become positive that there’s one less thing I need to think about when planning that developer’s workload. One more hour of my week available to think strategically. That sounds selfish on a second reading, but bear with me for a bit.

Towards a Responsibility-based Developer Maturity Model

You may be the most incredible coder, but if you don’t take responsibility for what you are building right from design to delivery, you’re leaving holes in your work for others to deal with. It really is that simple.

This is a straw-man, but I think a responsibility-based developer maturity model is what I’m looking for. Here’s how it might look:

Code Responsibility

A freshly minted graduate understands how to code. Depending on their degree, they might know a bit about software delivery models, but even then they will take time to learn how delivery works at your company. As such, the level of responsibility you might expect from a fresh developer is limited to the code they have created. They need to be told what to build, and often how to build it, but once built they should be able to own it.

Personal Responsibility

“What should I be working on now/next” defines this level of maturity. You’ve moved away from being fed work to do, and are actively seeking out the next piece of work. For a dev manager, this is the first sign of a great developer in the making. Curiosity, drive, and work ethic are all apparent in this level of responsibility.

Functional Responsibility

“Talk to Jane about XML tax updates, she really understands that function”, or more particularly, Jane might email and say “If anyone needs to know about XML tax updates, come and see me, I’ve grokked it”. This sort of behaviour shows that a developer has come out of their shell. They’re confident in their technical ability, they have some respect in the team, and they’re now putting their hand up to take on responsibility outside of their own personal sphere.

Platform Responsibility

“Dave is the Javascript guy”. You’ve proved your technical ability, you have the respect of your peers, and you’re being asked to make decisions about libraries and tools. But it’s not just about your technical skills – your peers know that you’ll take everything into account when making platform decisions, including developer happiness, so they trust you (and in fact rely on you) to help make these decisions.

Delivery Responsibility

“You can really rely on Sally to keep you up to date on where she is at and when her team will be finished”. From a management point of view, this is the ultimate level of responsibility. Developers working at this level will rally their team, manage their time, and deliver on their promises (or let you know when they can’t). There’s really not much more I could ask for than this, because it encompasses everything – including technical ability. A developer like Sally will tell you when there are holes in the spec or a technical gap in the team.

With Great Responsibility…

Reflecting on the above, it’s interesting that responsibility maps reasonably well to respect, and respect (in developer circles) can be an approximation for seniority. Want more respect from your peers? Take more responsibility for your work. The other thing to consider is just as no one bestows respect, no one is going to just give you responsibility (in fact, you’ve probably all worked with poor managers who have been given responsibility without the requisite ability).

Care about your work, take ownership of problems and delivery, look after your team members, communicate with your customers. This is what responsibility looks like.

Does this work as a maturity model? I think we might end up with those responsibility categories mixed in with Urban Airship’s tech ladder. I’d love to hear other opinions on whether responsibility is the missing link when we think about software developer maturity.

*Someone once told me about a drinking game, where you drink if [randomNoun].js exists.


When I lack focus, I often feel like I’m doing all the right things, but getting nowhere. Swimming in a vacuum is the best way I can describe it: no amount of attention to technique or increased pace is going to make a difference if I don’t have a medium to pull against. My personal focus is my task list. I’m not perfect, but when I compare those days where I religiously tick off my prioritised tasks with the days that I drift, the difference in output is stark.

bokehLikewise, without focus a software engineering team can look and feel like they’re doing great, but not make headway. You can have all the right pieces set up just the right way, but all for naught. No amount of engineering talent, no fantastic working environment, nor great team culture can make up for a lack of focus. It’s that important.

So, you’ve got – quite literally – infinite possibilities in front of you. How do you focus? I’m still working on it, but I reckon it comes down to this: build the right thing, the right way, right now. I laugh at how simple that sounds, but so many times I’ve been caught out by how uncommon common sense is. You may too very well scoff, but let’s take a look at these things in detail.

The Right Thing

The number of paths to take can be utterly overwhelming, so how do you choose the next one? Regardless of how you choose, know this: you must choose. Without a clear priority order of problems to solve (aka engineering tasks), you doom your team to endless half-assery and direction change.

It’s ok though, you don’t have to choose once and never change, you just have to choose the next thing. The next thing is what your engineers are building right now, which could be multiple things at once if you have multiple teams. Define it and get building it (the right way, right now), then you can go back to choosing the next right thing. Even if you chose the not-quite-right thing, getting that clarity for engineers means you can move on to the next right thing rapidly, while accruing some value from a completed feature. Getting to Done is fundamental.

Deciding the right thing is specific to your project and is a real product management art, but choosing a metric will help. Rank your opportunities according to those that will move that metric the most in the shortest amount of time, and pick the top one. You’ll quickly discover if your metric is incorrect.

The Right Way

Great engineers understand the difference between technical debt and slop. Never do slop. Slop is crappy method names, 10k-line JavaScript files, and nested for-loops with SQL queries in each. Technical debt however is a considered approach to build something in a sub-perfect way. Technical debt is choosing not to build this feature to cater for all the possible future uses. Debt (technical or not) is leverage, and your engineers should understand that leverage – used wisely – grows companies.

If you don’t have automated testing, continuous integration, and push-button deploys then you’re absolutely not doing it the right way.

The Right Way also speaks to culture. If you’re burning out, not communicating with everyone in the business, or not building the skills of others in your team, then you’re not building the right way.

Lastly, the right way means engineers understanding the problem that is being solved. Product management has a huge part to play here, defining and articulating the business opportunity represented by building the right thing. Done well, this serves as an inspiration to the engineering team, whereas a poorly defined problem leaves engineers adrift.

Right Now

Some call it “Lean”, but we call it JFDI: Just Fucking Do It. Don’t wait, don’t agonise over every nook and cranny. Make mistakes, fix them – rely on your fantastic devops and test procedures to help catch them. Deploy urgently and measure.

You’ve decided the number one priority for the business, you know how to build it, so dig in and do it right now.

Check Yoself

So, with an understanding of what lies behind the sentence, we can check on the quality of our focus by continuously asking: “am I building the right thing, the right way, right now?”.

Well, are you?