I would like to address a pet peeve of mine: The unfortunate habit in some circles to refer to people as “resources“ in staffing-related discussions. In the past, I have heard phrases like “We will need more Java resources“ or “Can we find more DevOps resources”. In this piece, I want to argue that, more than just being slightly disrespectful, this phrasing demonstrates a fundamentally flawed understanding of the staffing challenges in software projects.
To get the obvious problem out of the way: Of course, it is a bit disrespectful to assign a label to people that evokes the idea of “raw material”. Nevertheless, normally there is no ill intent and the idea is clear, the person asking for a “Java resource” is looking for an individual with experience programming in Java and likely simply opted for the shortest way of verbalizing this request. I therefore typically bite my tongue and resist the urge to label the offending party with a similarly anonymous description of their role in the value chain (“As the administrative overhead just said…”).
What I find more problematic is that approaching staffing problems this way grossly oversimplifies the situation. The word “resource” implies that any two instances of the same kind can be substituted at any time. Your project requires a certain quantity of bricks, but as long as they are the same kind it does not matter which one you use. All you need to specify is material and size. The word “resource” also suggests that adding more input (enlarging the team) will automatically allow you to produce more output. In my experience, neither of these correspond to the real dynamics of a software project (this is a quite broadly shared view at least since “The Mythical Man-Month” was published in 1975).
Furthermore, by requesting a Java Resource, you express that the main quality that matters in your team setup is experience with a particular technology. Granted, if most of your project makes heavy use of a particular technology, it is a good idea to have people with that experience present. Nevertheless, this is far from the only or even the most important quality you should look out for. Think about it that way: The objective of a soccer team is to score goals. However, a team composed of people selected purely on the basis that they can strike will likely not get very far.
Thinking About Teams
Maybe when considering teams we should start from the activities that need to happen during the project:
- The team will need to understand the domain and the problem you are trying to solve and connect the dots.
- When there is a disagreement, the team will need to resolve it.
- The team will need to take ownership of the UX of any interface you are building.
- The team will need to be able to deal with the specific quirks of the technical landscape you work in. (E.g. distributed systems, containers, embedded devices)
- Things will go wrong and the team will need to get their hands dirty when shit hits the fan.
- The team might also need to operate the software and assure availability.
- The team needs to take care of security concerns and manage the risk posed by malicious actors interacting with the system.
- The team needs to communicate with project stakeholders, especially when there are dependencies.
- The team will need to assure the quality of the product and manage code complexity and technical debt.
- The team will need to train any junior members, produce documentation, potentially train customers, keep stakeholders up to date, be aware of new important technology trends, and much more.
This list is just an example and definitely not meant to be exhaustive. Here is a related talk that I enjoyed by Dan North on the topic of how a member of a software team is more than just “a developer”.
Not everyone in your team needs to cover all of these competencies and for some, you might prefer specialists, however, generally, it is probably a good idea to have some redundancy. If several of these activities get neglected, this lack can backfire.
Note, however, that a lot of this is not just a question of the skills and competencies of an individual but depends on the team interactions. One person setting the tone potentially influences others to be more proactive in coaching junior colleagues. Another consideration is that people that have already successfully worked together for a while will likely have an easier time finding a rhythm that works. A team composed of strangers will require a ramp-up period.
Welcome to the Real World
Now, all of this looks nice on paper. Nevertheless, I do have to concede that the real world does not work that way. In the real world, there are two places where you can find people for your team: Internally (through reallocation from a different project) or externally (through hiring).
If your people come from other parts of the organization you might not have a lot of choices depending on the political situation. If you hire, you can be as picky as you want, but I am not aware of any interviewing strategy that can reliably assess a candidate in all the detail described above. Furthermore, you likely don’t hire for that one particular project (unless maybe if you are looking for a freelancer) and you want the candidate to be successful in other teams long after this current mission has ended.
Does that mean back to square one? In the end, asking for “resources” is the best we can do? I would still suggest that a better approach is to first simply start from the fact that something can be improved in your team and to carefully state what the problem is. Where are you currently getting stuck? Is it just a lack of hands that type Java code? Likely the bottleneck is something else and making this explicit can open up new possibilities like reducing the project scope, getting outside help, or in some cases even reducing the team size. Employing the word “resource” to describe the situation just makes it more likely you end up with an unproductive solution.
The Solution Space 