Some thoughts on organisational effectiveness/efficiency in a capital-constrained environment
There’s a high likelihood of a global recession. There’s an increased cost of capital (i.e., it costs more to borrow money) which means it’s prudent to protect your cash position. Many companies are shifting to higher probability bets, slowing down headcount growth (or even laying people off), and emphasising organisational efficiency/effectiveness.
Some thoughts on all of this.
“Organizational effectiveness” should account for product life cycle stages
Every product capability goes through the product life cycle: market development → growth → maturity → decline. Each stage has both different measures of success and key activities and this should affect what is considered “organizational effectiveness”.
Organizational effectiveness in market development is efficiently running a lot of experiments to find promising opportunities.
Organizational effectiveness in growth and maturity is efficiently building, scaling, iterating, and exploiting capabilities in order to maximize business value.
Organizational effectiveness in decline or commodity / hygiene capabilities is reducing total cost of ownership.
Questions to ask
- Are any teams innovating on commodity capabilities that should have been shifted to maintenance mode, outsourced, or even shut off?
- Are there maturing capabilities that aren’t considered “innovative”, so no one is working on them even though there’s still a lot of high probability business value left to take?
Don’t confuse utilization for efficiency
It doesn’t matter how busy individuals or teams are. What matters is that we reduce the time and effort to convert ideas into value. “Watch the baton, not the runners”.
When we focus on utilization, we worry too much about things like reducing meetings and interruptions and not enough time on things like reducing delays and bad hand-offs. On the large scale, I guarantee delays and bad hand-offs have a larger impact.
This is not to say that utilization doesn’t matter. It’s more that it should not be the priority.
Things to try
- Map your value stream(s), identify improvements, try them, assess impact on throughput and lead time, repeat
There is a lot of opportunity in eliminating low-to-no value activities
From the Toyota / Lean community (and also my personal experience), if you look closely at any process, a lot of it is low-to-no value activity AKA “waste”. Mary Poppendieck translated this concept to identify several categories of waste in software product development:
- Too much work-in-process (WIP) inventory (AKA “sleeping capital”);
- Working on unnecessary (or low-value) features;
- Relearning;
- Handoffs (unnecessary coordination or collaboration);
- Delays;
- Context shifting (lack of focus);
- Defects
See also Lean Software Development and Implementing Lean Software Development.
Things to try
- Use waste categories to guide retrospectives;
- Use waste categories within the context of value stream mapping when considering improvements.
It is both safer and more efficient to get impact through aggregating a lot of small bets rather than taking large bets
The fundamental advantage of digital-only, continuous delivery companies is the ability to aggregate a lot of small bets for greater impact. This should be exploited.
Question to ask
- Is there a smaller, faster way to get the learning and/or value?
Creativity over capital
When discussing continuous improvement, Toyota uses the phrase “creativity over capital”. This is a reminder that the most expensive solutions are not always the best ones.
When capital is cheap, you can develop a bad habit of solving problems with money: just hire more people, just buy an expensive tool, just acquire a company.
Solving problems with money is generally not the optimal way to solve problems and now with the increased cost of capital, it is even less so.
Question to ask
- Is there a cheaper, simpler, faster way to address the problem?
More cross-training
Specialists (when you don’t need them) leads to unnecessary headcount demand. I wrote about this previously in my blog post: Why T-shaped people.
“If people only know 1 skill, then, if developing your product requires n skills, you will need n people. If people know more than 1 skill, then you will need <n people.”
