Agile Job Descriptions

I'm in the process of reorganizing and streamlining job descriptions in our company, and now the HR manager wants me to define the differences between a junior software developer, a medior software developer and a senior software developer. Ehm… ok, that's a tough one. My first thought was that juniors need coaching, senior don't, and mediors end up somewhere in the middle. I would be perfectly happy with such a fuzzy-logic definition, but I'm afraid both our HR manager and our employees want more tangible function profiles.

Oh boy…

The Problem with Competences
The easy solution is to use competences. I could write job descriptions formalizing that seniors should be able to do A, B, and C, that mediors are able to do A and B, and that juniors are only expected to do A. But then I would be painting myself into a corner. I'm quite sure that, soon after formalizing such competence-oriented definitions, our software developers will need to acquire the new competences E, F and G. What then? I might be stuck with people not willing to adapt to the new situation, because the new competences haven't been formally documented. And continuously changing formal documents is the last thing I want. Not in the least because, in a country like The Netherlands, any change in a formal document needs the approval of at least three committees, two management layers and one counsel of wise old men.

Using Agile Requirements
Creating job descriptions is like setting up requirements, and I am gonna try and do this the agile way. I am unable to predict the future, therefore I am unable to define what competences people need to acquire three months from now. It's something we simply have to discover along the way.

Therefore, I think I might define our new job descriptions along the following lines:

  1. Be able to satisfy project stakeholders, among customers and colleagues.
  2. Be able to deliver projects that are profitable, and matching their quality criteria.
  3. Be able to learn, follow and adapt professional software development processes.

Each of these requirements can be measurable (well, more or less), and they can be tuned to fit the different levels of juniors, mediors and seniors. For example: juniors must be able to learn processes, but seniors should be able to introduce and adapt them. But most important, they allow for any kind of changes in processes, technologies, quality criteria and stakeholder requirements. And with an ever-changing environment, that's exactly what I want.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
A Tasty Team Building Exercise
Tear Down Your Cubicle Walls
The Virtue of Junk Code

Related Posts
free book
“How to Change the World”
  • Jacob

    I dealt with this very briefly at the beginning of a blog post a bit ago ( I think the thing most likely to give you trouble is if your progression trips over the judgement barrier. I’ll be pretentious enough to quote myself:
    “The differentiation between these positions starts off with how much you know. A Sr. Programmer is a Jr. Programmer who knows his tools inside and out and can complete assigned tasks quickly and without a lot of supervision. Around Team Lead time, however, progression stops being about what you know and starts revolving around your ability to choose wisely between competing trade-offs.”
    It’d probably be best to account for that difference in there if you think it comes into play in your organizational structure and job expectations.

  • Jurgen Appelo

    Jacob, thanks for the advice. It seems indeed that our level descriptions are turning out the way you’ve described. With a couple more criteria like ‘years of experience’, ‘complexity of projects’ and ‘level of coaching/independency’.

  • marion

    Thank you for your great advice. It will help a lot to people about how do they handle their work and the description you mention regarding jobs are really helpful.
    Marion Barrett
    Job Description

How to Change the World - free Workout - free