In my observations of many different software development teams I often get an impression that people see time as the most important commodity available. This is reflected in statements like:
All these statements suggest that time (that is if we had more of it) could easily be exchanged for other qualities of our software development processes. More time for development can be changed for cleaner code; more time planning – for higher certainty; more time testing – for higher product quality. This is a natural and understandable approach. Many things that we directly experience in the world around us, particularly those that deal with construction or production, appear to have such properties.
In my experience these statements have very limited application to software in particular and more generally to product development. As Kevlin nicely puts it in this great podcast
“because you spend a lot of time pausing trying to understand stuff […] it turns out you actually have plenty of time”
This exposes the true underlying commodity that we should really focus on: learning.
Sure time is required for learning but time on its own is not sufficient. We must expose assumptions, run experiments to verify them and adapt based on the outcomes.
Every now and then my twitter stream comes up with an interesting statement or question that sparks some reflection. The latest one came from Paweł:
I’m going to treat is slightly broader, speaking of a team rather then just a team lead.
This is not only an interesting question but also one which, I bet, often gets asked, especially as teams gain autonomy in organisations. Let’s leave out, for the time being, the more fundamental issue, whether we need managers at all, and Bob has some tasty thoughts about this.
Let’s consider the two possible solutions to this conundrum.
Veto the decision.
This is most likely the default answer in traditional, command and control organisations. When seniority and position in the hierarchy is confused with experience and knowledge senior managers fell obliged to make their stamp and protect their subordinates from doing the wrong thing. I hope this approach immediately raises your concern, at least a bit. First of all, the higher up you are in the chain-of-command the more removed you usually become from where the real work is done and your understanding of the context and specific challenges diminishes. More importantly however, to blindly veto your team’s decision is a stark demonstration that you don’t trust their judgment or their knowledge. It undermines their autonomy (assuming they had some to begin with) and demotivates them from taking responsibility for their own actions in the future.
Let the team fail.
If you care about your team accepting responsibility, about their autonomy and motivation you may think that the best outcome then is to do nothing and wait for the result. After all, you might accept that you are wrong in your opinion or you may want to give the team an opportunity to learn and fail. The team will continue with their own, independent decisions towards some outcome. They may succeed, or they may fail. If the latter outcome realises don’t be tempted to go and say “well, I always knew this was a bad idea but I wanted you to learn for yourselves”. Regardless, by not sharing your concerns you are withholding information from the team which can potentially harm the team and thus the organisation.
There is a third way.
When Paweł initially asked this question my immediate reaction was that it is irresponsible to do either. It felt very similar to the problem of delegation. “To delegate or not” appears to be a puzzle for many managers. Jurgen gives a good solution to this one reminding us that there are in fact perhaps as many as seven different levels of delegation between the two extremes.
I believe it’s better to aim for the middle in this particular situation too. My preferred choice would be for the manager to honestly and openly approach the team. They should share their concerns in a neutral manner giving the team the information and the context they might be missing. Seeking to learn their position on the problem, exploring the different potential outcomes, exposing any implicit assumptions that either side might be holding and then allowing the team to take an independent, but hopefully better informed, decision. And even though it sounds like a long-winded process it can all be done in a 15 minute chat at a cafeteria.
If there is disagreement, it’s usually expressed in a manner that lays blame, polarises opinion, and fails to reveal the underlying assumptions and experience in a way that the team as a whole could learn from.
If that were the case, perhaps the question we begun with is not even the right question to be asking.