Stuff I'M Thinking About

This is a post about how we think, how our thinking as leaders is shaped by our past experiences, and how that impacts the decisions we make today.

The way we think can influence the choices we make in ways we don’t notice, and then we are left with inexplicable results, or problems that just can’t quite be fixed.

The choices I will focus on in this post are those related to changes in both structure and work processes. These changes happen as a company grows, or when they face some sort of operational crisis, resulting in a restructure.

Either way, the same influences are at play.

Let’s start with a story, which is an amalgam of my own experience and the stories of others.

The Founders’ Story

The three founders were doing well. They’d built and shipped the first version of their software and had five paying customers, and all this in only two months. John had the idea in the shower one morning, and he contacted former colleagues Margie and Bill to see what they thought.

Early discussion went so well that they were able to quickly whip out a prototype for two customers to have a look at. Bill and Margie were working directly with them, and the feedback came thick and fast. Margie was releasing her test-driven code every couple of hours, and her and Bill were meeting with the customers each afternoon to get feedback.

In just two weeks the two test customers wanted to start using the software in their businesses. It solved some immediate problems for them, and they could see that John, Margie and Bill were committed and responsive. They were also willing to pay.

The next three customers came more slowly. They had some variations of the initial problems the software solved, so the three founders had to work out how to change the software to accommodate their needs, while also keeping the existing customers happy.

They wanted to keep the software simple to use, and avoid the bloat they’d seen in so many other products, and they were happy to spend extra time during the design process to avoid this problem.

With five happy customers on-board, it was time to start advertising, and within a few days another 20 customers signed up.

The team talked to three of these new signups to better understand their needs, and see what additional problems they needed to solve.

It was at this point Margie suggested they hire another developer. She didn’t want to get a large backlog of problems to solve, and delay satisfying the customers’ expectations while the company was on a roll.

They advertised, and got a suitable person, Jess, in a week. She and Maggie quickly adapted how they worked to fit in with Bill and the availability of customers.

Maggie had set up a CI/CD pipeline in the first week of operation, and they were using test driven design (TDD), and this was really paying off now that two of them were working on the code. They could release tested working software as soon as it was ready.

The next week was a shock—150 new customers signed up. There was quite a buzz in the community, and the team’s responsiveness to early customers had acted like free advertising. With these new customers came a whole new list of problems to solve. Maggie, Jess and Bill just could not keep up, so John placed an advert for two new developers and another designer.

The new staff took a few weeks to on-board, but they started being productive quite quickly because of the quality of the existing code and documentation. There was really good communication between the team, and they quickly dealt with any blockers. Sometimes they would swarm on blocking problems to get them resolved quickly. This had the added advantage that the team was learning to problem-solve together while also developing a deeper understanding of the software.

After a couple of weeks, they settled into a pattern of teaming up on problems based on their interest and skills, and working out the solution together. They engaged with customers early, showing them mock-ups and story-boards and talking them through before committing to a more detailed build.

After a few months they got coverage in a major industry magazine. 1,000 more customers signed up overnight, with a steady stream of 50-100 every day following.

The number of email requests increased as well, and the nature of those requests started to change. Instead of writing about the problems they want to solve, most of the emails were requesting specific features. Some of these were features from competing products, and some were solutions the customer had thought up for themselves.

John, who has now assumed the role of CEO, made the decision to double the number of developers, hire a product owner and scrum master, and to adopt Scrum. He hadn’t had much to do with the developers recently because he’d been promoting the company, and they had used Scrum at his last company where it seemed to work. The team were overwhelmed at this point, and he just want to help.

They interviewed and hired the new staff, four developers, a product owner and a scrum master, and after their induction they started work with the existing staff. John divided everyone into two teams with four developers and a designer on each team, and with the product owner and scrum master working with both.

The scrum master worked with the teams to work out what sprint cycle they want to use, and how often they wanted to do releases. There were some dependencies between parts of the software, and with the bigger overall team they need to talk about these before working on new features, so they opted for a two-week cycle, releasing at the end.

Maggie, Bill and Jess were not happy with the change as they were used to releasing several times a day. Also, the product owner was now the only one seeing customer emails. They would write the user stories, prioritise them in the backlog, and then pass them on to the teams to work on. Every feature request was deemed important, so they all ended up in the backlog. It was rare to say no to anything.

After three sprints both teams were not completing all the planned work for the sprint or meeting the sprint goal, and releases didn’t always happen either. They’d stopped using the CI/CD pipeline because there are usually several features in progress, and often there were code conflicts and things to coordinate. After a release they quite often got a lot of bug reports too, which would have to be fixed quickly. Other work was put on hold while both teams swarm on the bugs.

They hired a couple of testers, but this just seemed to delay releases even more, and it did not help with bugs either. Some of the new developers were not using TDD, and sometimes not even writing tests because they felt it was taking too long and they could rely on the testers to pick up any issues.

John had been out on the road a lot talking with customers, and was hearing about the bugs in the new releases and the lack of responsiveness to requests. He talked to the teams but could not work out what was going on, so decided to bring in a consultant to look at the problems. The consultant spent a month talking to everyone and come up some changes and a new structure, all based on “industry best practice”.

I am sure you can tell the rest of the story yourself. They get more people, they double down on Scrum (or something else), trying to follow the rules precisely, things slow down even more, there is more bureaucracy, more bugs and so on.

I should note that Scrum does not automatically mean that software can only be released every two weeks, and it does not mean that only the product owner interacts with the customer. It does not mean testing has to hold up releases. These are all common anti-patterns that emerge in most teams.

Sadly, many people are currently living versions of this story right now. They post about them constantly on social media and LinkedIn. I used these examples here because that is how it often ends up working in many companies, even if the intent was something else at the start.

What went wrong? Why did John choose Scrum? Why didn’t he ask the team what they thought? Why didn’t the team challenge him or report any problems earlier? If there were problems, why weren’t they fixed?

The short answer is that everyone was overwhelmed, and there was not time to think.

What I believe happened here, and happens in many companies, is that they chose a model, and believed that they’d made an explicit choice based on the evidence. They then became trapped in that model and it ended up strangling the company. When that model didn’t work, they explored other options. Rinse and repeat.

What isn’t obvious is that they did not make (or have) a free and fair choice of the model at all—it was chosen for them.

How can this be so?

Organisational Systems

From birth, most of us are exposed to organisational systems that were designed in the early 1900s to meet the needs of the industrial revolution. The style of education, and the way workplaces were organised and managed, were designed to prepare workers to be part of an industrial machine.

This was primarily the work of Frederick Taylor. His model proposed that managers observe workers and, based on measurement and analysis, design, organise and optimise their work to maximise production efficiency. The method included breaking down work into tasks, discovery of the single best way to do each, and standardising these for the worker to execute. The role of managers was to plan the work and make sure the workers followed the plan without deviation.

Scientific Management, as it came to be called, became the cornerstone of mass production, most famously applied by Henry Ford in producing the Model T.

This type of approach seems to be very well suited to making predictable things—known physical products being the best example.

This separation of managers and workers, with the categorisation of managers as the thinkers, and workers as the doers—the model of top-down control—has permeated industry and our lives ever since.

Personal Operating Systems

From the moment we start work, we are exposed to these systems that have their roots in Taylor’s scientific management. It starts in school, and continues through internships, apprenticeships and promotions through to our elevation to management. We experience, and are part of, command and control systems that work in ways that are similar to Ford’s factories in the 1900s.

Our boss assigns us tasks, either directly, or through specification in our job description. We stick to our tasks, and when we complete our work, we hand it off to others. We are judged based on our outputs—how much work we completed and whether it was up to some set standard. The focus is always on efficiency.

This is not the case for all companies, of course. Some are more progressive, others have abandoned this approach altogether, but few would deny the influence Taylor’s thinking has on what we do today.

The issue for people who’ve been exposed to working in this type of organisation is that their brain’s default wiring has been aligned to the same type of thinking, whether they like it or not.

When you have only been exposed to only one system of working and delivering value to customers, it is hard to see any other way. It might be a terrible way but how could you know any different?

It is possible to change, but as Morpheus observed in the film The Matrix, “no one can be told what the Matrix is. You have to see it for yourself.”

Why is this important to us, now?

The human brain is a pattern-matching machine. When faced with making a decision we first rely on intuition. This intuition is the product of past experience, and is based on patterns and models that we’ve built up over time from years of exposure and use. Intuition is a shortcut to getting things done without expending much effort. It is efficient. Our brains like efficient choices because it saves energy and resources. Our brains are lazy. We are lazy.

A good example is driving a car from home to work. We can usually do this without having to think explicitly about any single step in the process. The execution of the ‘drive to work’ program is automatic, along with hundreds of smaller decisions that are required along the route home. This is so much the case that many people can undertake the journey without remembering anything they see along the way.

This mode is known as System 1 thinking, as identified by Daniel Kahneman in his book Thinking, Fast and Slow. Fast thinking is based on intuition and relies on shortcuts and pattern matching, and is also often tied to emotional state. Once we have a pattern it can be applied again and again, with little thought or cost.

The other type of thinking is System 2, which is more considered and thoughtful, and I will get into that later.

There is one very important point to make about System 1—we are mostly unaware that we are using it—and this is where the problem starts. We respond to a question or problem based on our intuition, and because we ‘just know’ that the answer we have is the right one, that it fits perfectly, we proceed without any additional thought.

But it gets worse. Not only are we unaware, but sometimes the wrong answer is applied, and we don’t realise that either. Kahneman noted that, “This is the essence of intuitive heuristics: when faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution.”

In that one sentence is a key insight into why our efforts so often go wrong: it is because the solution was incorrect all along.

Because we have worked in organisational systems that are Tayloresque in nature, our System 1 brains have built up heuristics based on that model. We didn’t know that this was what had happened, but it did. The trap is that these problems, and the responses, are rooted in the industrial age. But we don’t live in that age anymore, we live in an information age, so many of the patterns we have in our brains no longer fit.

The organisations that benefited from Taylor’s work were ones that produced a known and consistent physical product. The work (and product) could be broken down in to parts, much as Henry Ford did with the Model T.

Modern companies are often producing things that are not the same, and are sometimes not even fully known when work starts; everything is bespoke, and only the first few steps may be known. Products are created through a looping process of plan, implement, study, respond.

What went wrong with our startup?

Looking back at the story above, we can see some distinct changes happening as the company grew.

The model used when they started out was the essence of agility. People collaborated with customers on finding solutions to their problems. The company was able to respond quickly to feedback.

As they moved to a more formal and structured model, the customer seemed to play less of a role, and eventually they moved from being customer-centric to feature-centric. The two are certainly not synonymous.

In the face of the growing issues, they got outside help, but as we often see this only delays or contributes to the inevitable decline in real agility.

We can see that the company passed through several distinct states. Each of these is called an operating model. Some people call them frameworks, but they are essentially the same thing. (Although a framework is really just a reusable template.)

Every company has an operating model, whether they are aware of it or not. These models can evolve over time, or they can remain static until disrupted by external (market) or internal (management) forces.

It can be seen from the story above that the operating models they chose didn’t help, overall. They may have help in some domain or another, but with a net loss of value. This type of issue isn’t isolated or restricted to blog posts or business books, it is everywhere once you start to see it (or live it).

How do we fix this?

There are two parts to the solution, neither simple or easy. The first is change the way we solve the problems we encounter, and the second is to change our own expectations of what leadership is.

Change problem solving and models

The key to this change is to slow right down, and to become aware of our own internal process.

I have already talked about the risks associated with solutions that arise from System 1 thinking. This automatic, heuristic-based thinking, can give us solutions that don’t always address the problems at hand.

If we do choose to slow down and take some time to consider the problem, the risk of taking shortcuts is still very high though; we are still lazy, and looking to save time and effort.

To slow down we use System 2 thinking, which is conscious, and more logical and systematic.

In this case, we might spend some time looking at operating models that other similar companies use with a view to copying what they do, or we get in a third-party to do thinking for us.

This might seem like we are explicitly thinking, but this is just falling back into the same trap as System 1 thinking; we are looking for shortcuts to avoid doing the hard work that needs to be done.

The over-reliance on existing models or frameworks, imported from other organisations, or the use of consultancies or “experts” under the guise of best-practice, is a major source of problems. There is an assumption that a static model can fix our problems right now, and in the future. This is never true.

I will note here that some consultants and experts can help, but only if they have the lived experience to coach you through your own process of discovery, and to help you grow towards autonomy. Helicopter experts offer little in terms of long-term benefits, and can also cause short-term damage.

Sometimes the use of external models is driven by a desire to be more like [insert name of your favourite successful product company]. If we want to be successful like them, we should adopt their operating model. It’s obvious!

This rarely works because the operating models in the big successful tech companies are based on a set of principles which support the overall vision and strategy. They don’t just exist in a vacuum, and they are being evolved constantly in response to market conditions and constant feedback. Their operating models are living, breathing, things.

Their models are also designed to optimise the communication flow around the work being done, which is something that is rarely considered in less successful companies.

A snapshot of the operating model can, of course, be captured and converted into a framework for use elsewhere, and everywhere. However, when this is applied in a new host company, the underlying principles, vision and strategy are missing, trapping the donor company in a static model that appears to fit, or is made to fit, but doesn’t. On top of that, it forces certain communication pathways and technical architectures that are not optimal for the work being done.

There is always a hope with these models that this is The One, that this will make a difference, and then we’ll be set. None of that is ever true; most models last a few years, only to be replaced when they fail, the market shifts, or new management arrives.

As W. Edwards Deming once wrote to a correspondent, there is no such thing as instant pudding, alluding to the fact that there is no recipe you can copy to be successful in business.

On that score, a Toyota executive was once asked why they are so open to sharing what they have learned with their direct competitors. His answer was that even starting with what they do today, their competitor will take 10 years to catch up, by with time Toyota will be another 10 years ahead.

Scrum is a good example of an operating model widely used in software development. In terms of the process, it is very well-defined. Most people in the software industry know what it is, and how it is supposed to be run. The latter part of that last sentence provides a hint at why it doesn’t seem to work that well—‘how it is supposed to be run’.

Scrum was designed to provide a framework in which to express the principles outlined in the Agile Manifesto. It is essentially a set of trainer wheels to get people used to working in a general way that could arise from following the principals. It is a “rough fit”. This is done with the understanding that once the principals take root, the training wheels can come off. From that point, the business is free to change and adapt what it does, firm in the knowledge that is the principals driving how value is delivered.

Another example is the Spotify Model, which was all the rage for a while. The truth is much more complicated.

The problem with models is that they are often imported as-is, in a largely monolithic process. There is a belief that everything can be planned in advance.

While there may be commitments to continuous improvement, this rarely happens because so many things have changed, and there are so many new interdependencies to manage, it is far too risky to actually change anything. Indeed, some sensible changes might even be avoided because they don’t represent “the one true way”.

A good example is daily standups. This is the one true way, so we have to do it, and in the prescribed way. I was part of team once that had no fixed daily stand ups. We used continual and open communication as a core part of our process, and delivered value multiple times a day, not just every two weeks.

The other point about models is that they all have failure modes—aspects of the model that, if not adhered to, will always result in failure. There will also be failure modes that are unknown, and will happen in as yet unproven contexts or scenarios.

Even if the failure modes are known, they are often ignored. Michael Hammer, the ‘inventor’ of business process engineering (BPR), wrote in one of his books of the 10 ways a company can fail at BPR. I once worked for a company that managed to achieve eight of these while under the guidance of a ‘big four’ accounting firm. And yes, they did fail at BPR.

At this stage I can hear the howls of objection—but the model we are using does work, there have been improvements.

The truth is that almost any change a manager makes will result in some measurable improvement, at first. This is known as the Hawthorne effect – when a change is made things always go better for a while because everyone is aware they are being observed by management.

The Hawthorne factory was known for the (in)famous lighting study, but did many more similar studies. What they found was that changing any variable usually increased productivity, including changing back to how things were prior to the study.

While these studies only changed one parameter at a time, the general principle still applies. Of course, during a restructuring no-one can know which of the potentially thousands of small changes actually resulted in any improvements at all. Some things will be better, others will be worse, so it depends where we look.

And sometimes the observed improvement is nothing more than increased activity or just an increase in visibility.

My objection to most models and restructuring programme is the lack of any built-in feedback loops that allow the model itself to be improved. The model is assumed to be immutable, and must be implemented as-is to ensure the expected results—in other words the same results that other users of the model allegedly achieved.

The problem is that without any corrective feedback any issues with the model expand and metastasise, and they behave just like bugs in software—something doesn’t work as expected, and this can cause local or systems-wide crashes.

The other issue is that there is also usually no feedback during the implementation phase. The design and planning work is done up front, it gets rolled out, and then we wait and watch.

So many assumptions, and so much risk.

The Alternative to off-the-shelf models

The alternative is to design and maintain your own operating model, but this is not a one-off activity which is why most people avoid it. You can also start with an existing model on a small scale, and adapt that incrementally, based on testing and feedback from real-world experience. This latter approach is usually more palatable and practical.

The resistance to doing either stems from the amount of perceived work and, frankly, a lack of experience in doing so. This resistance is also fuelled by the fear that anything we come up with will fall short of delivering the sort of outcomes that are achieved elsewhere. We have KPIs to meet! If the model doesn’t work it’s not our fault, right? (It really is our fault.)

We ignore the point that anything we come up with could be better (if we apply the right principles) than the current state, and (probably) more sustainable than a large-scale import of an outside model.

The critical point about this approach is that corrective feedback loops must be an integral component. Yes, loops, plural. This is what is missing from the static model approaches I outlined earlier.

Fast feedback loops and adaptive operating models are the secret sauce of those big successful product companies you are trying to copy.

When used on top of an innovative idea, continual incremental improvement, 1% better every day, wins the race every time.

There is a lot that goes into designing and evolving an operating model over time, but that is where success lies, and that is the job of a leader—working on the system, continually. Toyota is probably the most widely documented adherent of this approach, but certainly not the only one using it.

Leadership changes

As mentioned above, the other change is the one we have to make in ourselves.

We are responsible for the system in which our staff and teams work in. (A system is interconnected network of parts that an interact with each other. A change in one part of the system, even a small one, always spreads much further than expected.)

Any operating model is not for us, it is there to allow our company to deliver value to the customer. The model is not there so that we can control the decisions people make, or have visibility over every decision or piece of work. That would be insanity.

The model is for our staff and our customers, although we are responsible for the model.

We must learn to delegate, and with sufficient context, so that people can make the right choices themselves. That will free us up to work on the system.

To have confidence to do this, the operating model must incorporate feedback loops, with it being everybody’s job to work to improve the system in response to that feedback be it from internal sources or market signals.

One of the big challenges for leaders in this regime is giving up control. The desire to remain in control, and to be able to see everything that is going on, can have a huge influence on the type of framework or operating model that ends up being selected.

Command and control structures will not make a great product company. Beware that your System 1 thinking leads you to select command-and-control models, even if you are aware that these are bad and you want something different. The force of System 1 thinking can be very strong!

When a company is small, we can be across every decision. But there is a level of intimacy with customers in a startup that is not sustainable as the company grows.

In a large company, the CEO or executive team cannot be across every decision either, and potentially might not be across most of the most important decisions made in the company.

There is a big difference between what it feels like to be a founder, with the high degree of hands on, and knowledge of everything that is happening, to being in charge of a much larger company.

As a company increases in size, you will no longer have the knowledge to make rational front-line decisions. Only those that have direct contact with customers will be able to make that call. As leaders, we don’t want an army of mini-mes that will make decisions exactly as we would.

Some leaders would like this, and get annoyed when an underling make a different choice, regardless of whether the outcome was positive or not. They typically assign any failure to the underling not having done what they themselves would have done, rather than some other factor outside of their knowledge or control.

We need our staff to be able to act autonomously in the best interests of the customer and the company, and we need to create an environment that enables that as early as possible, lest we create a company where staff are dependent on constant direction and micro-management.

(As an aside, if you feel you have to micro-manage staff, this might really be about you or the operating model you staff work under.)

When a leader is unable to let go and delegate, the orientation of the company frequently shifts from providing value to customers to just delivering features. Quantity instead of quality. Outputs, instead of outcomes. Short-term results, over long-term sustainability.

Summary

Our penchant for shortcuts—either through System 1 thinking or just laziness—is a key factor in our failure to create operating models that work well, and that can evolve in response to internal and external feedback.

To make a change we need to commit to slowing down and doing some real thinking for ourselves, on our own, and with our teams.

We also need to transform our style of leadership from command-and-control, to one of providing vision and context, and empowering and trusting our staff to get on with work.

Along with this, we must make the switch from being focussed on maximising efficiency and resource utilisation, to optimising the flow of work and value through the organisation to the customer.

How do we make this change? That is the $64,000 question.

I will not, and can not, provide a prescriptive template to solve this problem for you personally, or for your company. There is no such thing. This is a personal journey that you have to undertake with you team.

There is quick fix, no shortcuts to be had. It will take a lot of work, and we all have no time to lose.

I was lucky enough to be exposed to lean thinking and agile ways of working very early in my career. For me, much of what I have written about above in terms of good practice feels quite natural because I have lived it. But it did not always feel that way.

The key for me was to focus on reading the best thinking in the field, and on continually improving as a leader. From that I could learn principles that could be applied in my work, regardless of the model, and to develop a toolbox that I could draw on as needed. I adapted my approach based on the failures and successes.

The other thing I did was to observe, ask questions, and research new discoveries, also with a view to extending the range of my toolbox.

An early influence of mine was the work of W. Edwards Deming. His management theory has four components:

1. Appreciation of a System: A business is a system. Action in one part of the system will have effects in the other parts. We often call these “unintended consequences.” By learning about systems we can better avoid these unintended consequences and optimize the whole system.
2. Knowledge of Variation: One goal of quality is to reduce variation. Managers who do not understand variation frequently increase variation by their actions. Critical to this is understanding the two types of variation — Common cause which is variation from the system and Special cause which variation from outside the system
3. Theory of Knowledge: There is no knowledge without theory. Understanding the difference between theory and experience prevents shallow change. Theory requires prediction, not just explanation. While you can never prove that a theory is right, there must exist the possibility of proving it wrong by testing its predictions.
4. Understanding of Psychology: To understand the interaction between work systems and people, leaders must seek to answer questions such as: How do people learn? How do people relate to change? What motivates people?

(The above summary was taken from the article Understanding how work is done — Deming’s theory of profound knowledge.)

This opened up many areas for further study and consideration.

This was the path that I have taken. My challenge to you is to work to expand your own toolbox, with a view to transforming your approach to the problem solving, leading, and anything else you discover along the way.

To help you get started, I’ve included below a curated list of some of the books I’ve found helpful.

If you have found this post helpful, I’d be happy to have a coffee to explore any of these ideas with you.

Reading Material

Out of the Crisis, by W. Edwards Deming

This management classic appears, at first, to be more focussed on manufacturing, but the reader will quickly realise that the lessons are applicable in any field. As I once heard someone say, all roads lead to Deming.  This was one of the first management books I read.

The New Economics for Industry, Government, and Education, by W. Edwards Deming

Deming’s final book is a masterpiece of insights, and where he explicitly expands his management theory into the world of knowledge work. A must read.

A New Way to Think, by Roger Martin

I have written a lot about models, and this is a book about models. This is the first book you should read, as it will help you start the journey to examine the models you currently use, and the processes you use to apply them. I reviewed it back in February 2023.

Predictably Irrational, by Dan Ariely

This is just the book you need to shake up your thought-life, and your world. Dan will lead you through some experiments and their findings to show you how your thinking works, and how it can fail you.

Atomic Habits, by James Clear

If you want to make changes in the way you behave, both at work and at home, this should be your first stop.

What Got You Here Won’t Get Your There, by Marshal Goldsmith

Don’t be put off by the title, or this book’s billing as a New York Times best seller. Marshall is one of the top executive coaches in the world, and this book covers the many leadership behaviours that act as constraints on the company and your career, and what to do about them.

The Art of Action, by Stephen Bungay

This is a great book on how to delegate work with sufficient context to allow people to act autonomously. There is a podcast episode that is a good starting point before you read the book.

Playing to Win, by Roger L. Martin and

You will not succeed, regardless of how you operate, if you do not have a great strategy. Most books about strategy are wrong. This book is not wrong.

I also recommend any of Roger Martin’s other books, and suggest subscribing to his practitioner insights newsletter.

The High Velocity Edge, by Steven J. Spear

This book should be a classic too. Spear takes a close look at the operations of ‘learning organisations’ from a wide variety of sectors, and from these case studies derives some unique insights. He shows how they (from the book blurb):

1. Build a system of “dynamic discovery” designed to produce ultra-high-speed learning within an organization
2. Attack and solve problems when and where they occur, converting weaknesses into strengths
3. Disseminate knowledge gained from solving local problems throughout the company as a whole
4. Create managers invested in developing everyone’s capacity to continually innovate and improve

A must read.

Wiring the Winning Organization, by Gene Kim and Steven J. Spear

This book builds on the earlier work of both authors, and is also a must read on how to do things differently. I am not sure why this book is not getting more press. Perhaps this is because it does require the reader to be very open to the concepts presented, and be willing to spend time thinking through what they mean and how to apply them in your own company. This interview on YouTube is a good introduction.

Project Lifecycles – How to Reduce Risks, Release Successful Products, and Increase Agility, by Johanna Rothman

This is probably the most useful book ever written on feedback loops. In it, Rothman outlines a range of different project lifecycles, and how each trades-off feedback against risk. I wrote an overview of the book in a recent review.

The Effective Manager, by Mark Horstman

Leaders also have to be managers, and this is an excellent book on the basics such as one on ones, feedback, delegation and coaching. There is also a good podcast with a massive library covering every topic imaginable. Worth the $US200 a year fee just to get access to the show notes.

Transformed, by Marty Cagan with the SVPG.

This, and the two previous books Inspired and Empowered are the first book I’d recommend to help you move to a better operating model.