Agile Job Descriptions

May 22, 2008 by JurgenAppelo

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.

Permalink