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.

3 Replies to “Responsibility”

  1. The other thing I’ve noticed is that with some engineers you can assign a bug to and say “Try this” and they’ll do it then return the bug to you saying “It didn’t work”. The good engineers are the ones who will try what you suggest, then try something else, in fact they’ll keep banging away at the problem until they’ve fixed it, worked around it or proved it can’t be fixed (at least by us).

    This is also one of the hardest things to figure out in an interview. You can ask technical questions, go over employment history and give them coding tests but it’s really difficult to know whether someone is self-motivating without actually working with them.

    Many years ago when I first started interviewing candidates the senior engineer who was working with me told me he could usually tell if someone was worth hiring or not as soon as he walked in the room. I was quite shocked at the time and thought that maybe he’d gotten lazy or disillusioned, but over the years I’ve come to understand what he meant – sometimes you meet a candidate and immediately find yourself thinking “No”. I try not to let this gut feeling get in the way of their interview performance, but I don’t think I’ve ever had a candidate do a good interview if I’ve had this feeling. Of course, that could be confirmation bias but I’m always careful to get my colleagues’ impression as well.

  2. I’d add one more – Process Responsibility.

    Development is a process that needs to integrate with other processes that make the business hum. When a developer can attain the maturity levels where they are constantly searching for and implementing improvements to make the process of development (and rapidly learning when these experiments fail) then you have a team that can really make a difference with the optimal number of people.

    1. That’s a good point Miki. I’m starting to wonder if it’s more of a matrix or checklist than a maturity model. That is: developers might exhibit ownership or responsibility in multiple different areas, and the goal is to have complete coverage (either across the team, or from every developer).

      This way, you’d pick developers with great delivery responsibility as team leads, and tech leads where they exhibit platform responsibility?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.