How to determine if systemic factors slow down your teams’ velocity

Last week, I pulled out the critical thing that Steve Jobs did, upon returning to an Apple computer with a sagging stock price. He went after a major systemic factor that was holding back release dates: too many priorities. If you are really going after top performance, you need to look at all factors, including the global ones.

Local or global maximum?

When standing on the top of a hill, every way you look is down. It’s the definition of a maximum. The thing is, though, you might not be standing on the highest possible hill or mountain in the area. And it’s difficult to know that. You typically won’t see mount Everest unless if you are in the Himalayas.

The same is true when you are maximizing velocity, and looking for the top of the parabola. There is a lot you can try to improve a team’s velocity. But it’s worth checking whether the team is being held back by systemic factors that you can’t see from where you are. Or is it really just a team-specific challenge.

It’s quite likely you don’t even see the potential global maximum, because of pre-existing company culture and procedures, particularly in a larger stable company. It’s worth trying to improve velocity locally, at the level of one team. But also keep in mind that you might be climbing the wrong hill. The higher one will be start with improving the context in which the team operates. A low velocity may simply be a reflection of a difficult culture and context in which the team operates.

Three Examples of Systemic Factors

Before we deep dive into improving team-specific output within each team, here are three examples of systemic factors I’ve seen at client sites that slow down team velocity:

1. Resource Thrashing

2. Too many chiefs

3. Communication overhead

Let’s start at the top, shall we?

1. Resource Thrashing

If your true priorities aren’t clear, this impacts you on many levels. Before getting to the somewhat obvious operational impact, consider the revenue impact first. Yes, revenue!

According to “Stop Chasing Too Many Priorities” by Paul Leinwand and Cesare Mainardi in the Harvard Business Review, too many operational priorities correlates with a given company’s ability to outperform its peers in terms of revenue. Having too many “#1 priorities” will reduce revenue potential. It will be harder to communicate the vision to both customers and employees, as Jobs noted above. Also harder to execute.

For example, one common trap is just to list everything you are doing as a priority. Yes, every cost and effort needs to have a goal and be justified. But this approach muddles what exactly needs to change. Because everything we are working on is a priority. It is easier to sell to existing employees and shareholders, but it doesn’t really lay the groundwork for anything to change.

Operationally, Steve Jobs focus on the 4 quadrants solved what I call the “denominator problem” from an operational standpoint:

people per product = people/nr of products or projects

The large the number of “buckets” you need to fill, the higher the denominator. The higher the denominator, the less resources you have to succeed with each product. New or existing.

This is the true cost of lack of focus. Because if you are under-resourcing your product teams, you are effectively setting them up for failure and yourself up for disappointment as a decision-maker.

Signs of this would include:

• Heavy reliance on traditional project management (waterfall): as there are lots of resource conflicts, you need a caste of professionals to manage this, each with their own specialty. Which adds more cost. Note that they don’t actually contribute to the work that needs to be done directly.
• partial employee allocations: For example, allocating 5 people at 20% will mean that all 5 people will spend most of their time in status meetings and unable to actually deliver anything. But you have the slot fully allocated, right?
• shifting team structures: If needs are constantly changing due to thrashing, then there is constant complexity around what needs to be done, who needs to do it, and by when. So you’re spending a lot of time figuring out how to achieve new goal with the limited resources you have and who you can nab from elsewhere.

2. Too many chiefs

For anyone who remembers high school physics, there was one important distinction between velocity and speed–as my friend Andy Wilkin recently pointed out. Velocity had an implied direction. One direction.

If each manager pulls in their own direction, they collectively turn velocity into speed. A low speed. And effectively no clear direction.

There is a value in having specialized managers which look after shared company concerns. Ones which cut across multiple products. For example, a function like DevOps or a shared database infrastructure. But then you also have functional managers, like QA. And project or delivery managers who are on the hook for getting the team to ship. And geographic managers who keep a close tab on staff in remote offices, possibly because they can charge out the time. And you end up in a situation with a lot of managers who mean well, who want to stay informed, but they don’t really contribute to the work which needs to be done.

This is a systemic problem of unclear goals, covered up by having layers of people who are responsible for slices of what needs to be delivered. Here are a few metrics you can track:

• cost of going in the wrong direction: Often a side effect of having too many stakeholders, you can end up building things which sound good to internal decisionmakers or committees, but which customers could care less about. In other words, the “voice of senior manager” booms louder than the voice of the customer. total cost = nr man months * monthly burn rate
• cost of oversight crowds out budget for people actually doing the work: a side effect of having so many managers is that you don’t have enough money left over to hire competent people to do the work. Managers are expensive and, ultimately, they aren’t really required to accomplish the goal. Just to structure the work and monitor progress. Some of that is necessary, but ideally it’s done by people doing the work with a high level of trust and a minimum level of oversight.
• ratio of stakeholders to team members at meetings: This originated as a snarky observation on my part. Doesn’t make it less true. For operational meetings, such as a development team standup, if most of the people attending say they are “just listening today”, that means they aren’t adding value and they are taking up others’ time. To be followed up by more meetings with other stakeholders and managers to discuss what is happening at the standup. In practice, there is a high financial cost to all of this, and this ratio is a good proxy for that cost, even if employees don’t know who makes how much.

3. Communication overhead

One of the older pearls of wisdom that have been floating around the software industry is: “9 mothers won’t be able to deliver one baby in 1 month.

Your ability to add people on to a project will typically be constrained by the structure of what you’re building. But also by sheer communication issues. Before anyone can contribute to a project, they need to have enough context to be ableto do so. That is harder than it seems. For one, they need to know how their bit contributes to the overall vision. So they have to understand enough of the big picture, to locate where their addition should go. For another, they need to know who knows what. Who to ask specific questions.

Much of this accumulates based on natural interaction patterns in groups of people. Each person will need to relate with every other, even the junior people to the senior people. So every important messages needs to go out to everyone. And also needs to be understood by everyone.

Common patterns to make this “work”:

• hub and spoke pattern, where the manager is the source for all decisions and communication. Typically, this results in the manager’s time being a bottleneck, and most of the team sitting around and waiting for instructions. And overall progress is slow.
• peer-to-peer pattern, or the self organizing one. This is much more effective and immediate, particularly if there are differences of experience, skills, or knowledge among team members. but this is often difficult to scale up. Each additional node added to a network of peers adds increasingly higher communication requirements. A network of this type has n! connections, so 25 peers in a flat network have 25! connections or 1.55 * 10^25 connections.

In practice these sheer numbers are combined with either inexperienced or offshored staffers or partial allocations of busy people who can’t be 100% spared. For the first, it’s clear why they struggle to contribute (at least without direct access to managers and mentors who are too overstretched to help). For the second, if you have a senior BA allocated at 20% to a project, most of that time will be attending status and planning meetings just so that she has context. So there is almost no time available to do any work.

So in short, for discovery intensive work like new product development, you are setting yourself up for difficulty if you put too many people on the product too.

Wait, so how do you get a globally optimal outcome if you can’t add either staffers or managers?

Beyond a certain point, it doesn’t make sense to add more. You will see it in your output metrics. And ideally that output goes in front of customers or prospects frequently (with commercial intent of course).

Small, highly experienced teams who know what they are doing. And with direct access to customers, to ensure they are building something customers care about. These people are probably on your team already. Get rid of everyone else, and give these team members the space to do their thing.

If you want to increase learning and speed, add more independent teams with the same characteristics. But don’t make one team too large in the hopes that the software factory will output more web screens and database tables per month. Because either it won’t or it will, and in both cases, you can end up disappointed.

Note that this is the exact opposite of what large, efficient and established companies are used to doing. Being deliberate, effective and thoughtful will leadyou down a much better path.