When solving complex problems, those who are directing the work sometimes prescribe solutions. They do this for several reasons:
- Because they want to help, and if the answer seems obvious to them then it seems the right thing to do
- Because they feel it will help them get the outcome they want sooner
- Because that's always been the way they do things—management directs
To some extent, this makes sense if the solution is obvious. However, it may cause unexpected side effects both for our software team and the outcome that we desire. An answer may seem obvious, but simple problems have a knack for hiding complexity. Also, our solution might not be the best.
The New New Product Development Game, Takeuchi and Nonaka, HBR, 1986 discusses the need for subtle control when managing product development teams. By setting the purpose for our team and giving them the intent, rationale, and any constraints, we can operate a much more fluid style of management which empowers our team to work how they see fit within those boundaries. Boundary setting enables team self-organization.
Those closest to solving the problem, the ones working on it, often have the information necessary to make decisions. If they don't always have to go up and down the chain of command to get answers from superiors, this will prevent long waits. And besides, our management teams are often removed from the day-to-day context of the problem in the first place.
This doesn't mean that management doesn't have an interest in what our teams are doing—far from it. Management will still check in with the team to see if things are progressing in the direction they hoped for. However, giving our team a degree of autonomy will rapidly speed up the decision-making process.
We've hired smart people to solve problems; as professions go; most software development team members are a highly educated bunch. Rather than telling them what to do, we should work collaboratively. This collaboration will help our team understand where the value of our product lies and means they will be more focused on a solution that realizes value sooner.
By telling our team why we want to do something and then leaving our team a degree of autonomy as to how they do this, we may be pleasantly surprised by the results.