Do You Have These Issues In Your Organization?
At Agile 2 Academy we have done a lot of surveys of technology companies, in terms of their project challenges, and there are common themes. Let’s see what those are! And then we’ll tell you how those issues can be addressed. And guess what? All these things also impact costs, and they link to strategic objectives!
Our list of recurring issues numbers 25, but the five below are the top (most urgent or important) issues that seem to come up again and again:
People hesitate to take prudent risks.
People stay in their lane, instead of reaching out.
Too many meetings, or meetings not efficient.
Resolution of issues is too slow.
Dependencies (are a problem that we struggle with).
Do these sound familiar?
All of these impact agility, hugely. And cost. And effectiveness.
And in today’s rush to incorporate AI, number 1 is paramount.
So is number 2.
And number 3. And 4! And 5!
Always Think Both Short Term and Long Term
When dealing with any issue, there is what you should do now, to “stop the bleeding”, and there is what you should do to address the root cause, long term.
Focusing on one and not the other is a prescription for failure.
There are lots of practice-based solutions for these five symptoms. Yes, they are all symptoms of root cause problems that need to be solved.
The trope about embracing failure should really be about expecting people to try things before being sure.
For example, “People hesitate to take prudent risks” can be band aided by creating innovation programs, or workshops in which people create ideas that executives then sponsor. Hackathons fall into the latter category. But while these are worthwhile approaches, they won’t solve the root cause. The root cause has to do with the culture, which is created by leaders, which – in effect, although usually not intentionally – punishes failure.
But wait: contrary to the trending trope that leaders should embrace failure, we have a different take: What we have observed among highly agile companies is that leaders in those companies expect that people will prudently try things before being completely sure it will work. In other words, it is an attitude, and it is demanded.
For example, if a group lead hears about ideas for an approach, and the team is confident but not certain that it will work, the group lead’s response might be, “Why have you not tried it yet? Why are you waiting?” The implicit admonishment is that trying things is expected. People not only have permission to try before being sure, but it is expected of them.
The ramification of that is subtle but crucial: if people behave that way, then a lot of the time they will fail. What they try will not work. But if trying things before being sure is considered normal, then some failure of early trials becomes business as usual, and is naturally followed by reflection, regrouping, and trying again.
In other words, leaders need to set a strong behavioral expectation that people will try things before being sure. And then when something doesn’t work, leaders should set an example of discussing why it didn’t work in a dispassionate and rational way, and encourage people to try again.
It’s all behavioral. And leaders generate the behavior through their expectations – in other words, how they behave.
Expect that People Go Out of Their Lane
Along similar lines, leaders need to give people problems to solve, not tasks to complete. And they need to set the expectation that people will reach out to whoever they need to talk to in order to solve the problem.
It was dependencies that caused Amazon to invent its single-threaded leadership approach.
Elon Musk once wrote an email saying that if anyone blocked someone from talking to whoever they need to talk to, the blocking person would be fired.
Amazon has a method known as single-threaded leadership. A single-threaded team – which might actually be a large collection of small teams – is expected to do whatever it needs to do to achieve its objectives. By “do whatever it needs to do” we do not mean that they can cause problems for others or get out of alignment with corporate strategy. What we mean is that they are expected to work with other functional areas to work out ways to get the problem solved. They don’t need permission. Reaching out is expected – it is demanded. Again, this is behavioral. There is no “single-threaded collaboration process”.
The Agony of Dependencies
Let’s jump ahead to dependencies. It was a growth-generated escalation of dependencies that caused Amazon to invent its single-threaded leadership approach. All organizations that contain multiple initiatives suffer from dependencies. Dependencies can easily gridlock you, blocking everyone from moving forward.
The key to managing dependencies is to get people to think about how to remove and automate resolution of dependencies from the start. There are definitely patterns for that. (I have written about dependency management patterns for software development.) But the main ingredient is behavioral: get people thinking about it, using a systems perspective. Think end-to-end. Reach out to other teams, and work out ways to reconcile dependencies along the way, so that people don’t have to wait for each other.
It’s All Behavioral, But Knowledge Helps
All these phenomena have behavioral solutions. But knowledge of useful patterns helps. I mentioned that I wrote about dependency management patterns for software development. Those patterns are useful, but only if people think from a systems perspective and reach into their mind to consider what patterns might help in a given situation. And it is important to start doing that early on, before gridlock sets in.
There are no processes for solving the top five issues I started out with in this article. The solutions are all behavioral. The solution is to teach people to behave differently. And yes, teach them some patterns – and there are plenty. The entire field of DevOps is about patterns for how to do things. But patterns are useless without the behaviors that will apply the patterns.
These Impact Agility and Cost
Poor performance in these areas have wide ranging impact. They each affect your organization’s agility – that is, its ability to move quickly and change directly quickly. For example, if people are not willing to try things before being sure, they will over-think and over-plan. SpaceX has a rule that if you are 51% sure it will work, you should try it. Amazon has a similar rule, but their rubric is 70%. That’s how they are able to move fast.
If you over-plan, then you are losing on both the top and bottom line.
That impacts cost too, on both the top line and bottom line. If you over-plan, then you are investing in wasteful planning before finding out if the plan will even work. That’s a bottom line cost, and it is wasteful if the extra planning does not actually increase the chance of success – and for technology development, the tradeoff between planning an experimentation heavily favors experimentation. On the top line, if your planning delays your product release and causes you to miss a window of opportunity, then you suffer a huge top line loss.
Similar reasoning applies to the other issues that we began this article with: the problems I have been discussing all affect agility, cost, and strategy success.
The Strategic Link
There is no better way to improve your organization’s performance than developing the leadership skills of your managers
The link to strategy is that all these issues are impacted by the leadership style of the managers at various levels, because the solutions to all these issues are behavioral. It is the ways that managers respond to situations that determine the arc of these issues when they arise.
People hesitate to try things because their managers discourage it. People stay in their lane instead of reaching out because bosses discourage their people from crossing organizational boundaries, and senior managers create a competitive situation between mid-level managers and business areas. People have too many meetings because managers find it convenient to pull everyone in their office to find out what is going on, and their managers do the same, and so on up the chain – and so everyone is in meetings all day.
And so on. It’s all about the behavior of people in leadership roles. So if you want to improve on the project issues mentioned at the start of this article, the place to begin is with leadership style, at all levels. Leadership training and development needs to be a strategic priority. There is no better way to improve your organization’s performance – and nip all those project issues in the bud.
