This is the first in what will be a series of posts in which I am sharing my thoughts about a framework for organizational effectiveness. I’m trying to keep these installments short, so hopefully each will be a manageable read. Please share your thoughts, and let’s learn together.

The question I am often asked as a software product development leader, and as someone who thinks a lot about agile processes at scale, is “how can I make my teams be more productive?” 

Although I think this is the wrong question for business leaders to ask, it is a reasonable one given the challenges business leaders face. A huge portion of any software development organization’s budget goes toward R&D and leaders want to get the best return on their investment. I think the right answer to the question about how to be more productive is, “What’s your current productivity, and what would you like it to be?” No one seems to be able to say. Even when I was leading a PMO and should have been the person with the answer, I couldn't say. Leaders are smart, but objectively saying how productively you're developing software isn’t easy.      

In traditional operations management, the formula for measuring productivity for a given period of time is actually really simple: 

If you’re building physical products, output is the number (or perhaps the value) of widgets you produced and input is the amount of resources (money) it took to produce those widgets. Yes, I’m simplifying. Yes, I know it might look slightly different from one organization to another. But my point is - when you're producing physical products these things are measurable. In many cases they’re even measurable on a person by person basis. 

For knowledge work this becomes harder. Input is easy to measure. It’s the cost of the people employed to build the product. Output, on the other hand, is hard to measure. It might even be impossible. What is the output of a development team? Minimum Business Increments? Features? User stories? Lines of code? How would you measure any of this for an individual developer?

Say you decided you were going to use the delivery of features as your measure of output. Sounds ok. A feature is generally something consumable by a customer. It has value, which is important. But how do you normalize the measurement of features so they are comparable and can be measured in aggregate? One feature might be ten times bigger than another feature. You could try to normalize them using story points, but of course story points aren’t comparable between teams most of the time, and they’re really easy to manipulate.

It’s a problem. Some people might suggest using the number of code check-ins per day as a proxy for productivity. After all, if developers are checking in code frequently that must mean they’re getting more done and the organization is delivering more value to its customers. Maybe. Maybe not. You can get lost for years in these arguments. They become religious and dogmatic, and at the expense of your development teams’ morale. In the end, you may find you’ve not make any real improvements to your organization or to the outcomes you provide for your customers.  

So, I’ve come to believe that for product development teams, we should stop trying to directly measure and improve productivity. It puts our focus in the entirely wrong place. We want to continuously improve the results from our teams, but directly focusing on improving their productivity is misguided.

We just finished another Tour de France season. I didn’t watch every minute of it, but I don't think I ever saw a directeur sportif in a support vehicle rolling alongside one of their riders yelling, “Ride Faster!! FASTER!!” The cyclists are already riding as fast as they can. And I doubt there was ever a post-race team meeting where the team manager said, “Ok guys, we have some ground to make up tomorrow. So here’s what I want you to do. I want you to ride faster tomorrow. Got it? When you think you’re tired and you can’t ride faster, I don’t want to hear any excuses. Just ride faster. We have a lot of sponsors breathing down our necks and we have to win.”       

The role leaders play on a team is crucial. But it’s not to hit people over the head with a tire pump so they will ride faster. Instead, the most important thing they can do is to create the CONDITIONS FOR SUCCESS. In cycling, that looks like:

• Articulating a clear and well understood team strategy
• Building a culture of teamwork and accountability 
• Making sure every team member is supported, empowered, and understands their role on the team and in each race
• Establishing cutting-edge processes for nutrition, bike maintenance, medical treatment, training, and racing as a framework for racers to compete at their best
• Continually monitoring and measuring all four of these areas for opportunities to improve                  

If the conditions for success are in place, riders, who have tremendous intrinsic motivation, have all the clarity, resources, and frameworks in place to perform at their highest potential.

The same is true for our organizations. To build effective organizations, the primary job of leaders is to create the CONDITIONS FOR SUCCESS:

• Clear strategy that is aligned to values, and transparently communicated   
• Culture of high-trust, customer-obsession, and accountability
• People who are empowered with a growth mindset and who take ownership
• Processes that put quality first and are managed for optimal flow of value
• Continually monitor and measure all four of these areas for opportunities to improve

The people in our organizations are highly motivated. They want to do work that matters and make a difference. When leaders provide clear strategy, a strong culture where people are empowered and accountable, and processes that are optimized for quality and flow of value, then people can perform at their best and deliver amazing outcomes for organizations and their customers.

I've come to visualize these four areas of organizational effectiveness like this:

Each of these areas connects with and relates to the others, and all together they determine organizational effectiveness. I believe that for each area - strategy, culture, people, and process - there are four main sub-areas to focus on and help strengthen that area. I'll show you the more detailed map, as well as how to know where to focus first, in my next post. After that we'll dive more deeply into each area and sub-area, but always with the big picture in mind and always remembering that the purpose of all of this is to deliver better customer outcomes.

See you next time!