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.
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:
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.
“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.
“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.
“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.