How I Learned to Let My Workers Lead

I recently came across a really interesting article written by Ralph Stayer titled ‘How I Learned to Let My Workers Lead‘ about his experiences at Johnsonville Foods.

It describes the way that he was able to help change the company culture from one where he made all the decisions and took all responsibility to one where everyone in the company was involved in decision making, resulting in a more successful organisation.

One of the interesting early parts of the article talks about how the problems created are entirely the fault of the author who is the CEO of the company:

I started by searching for a book that would tell me how to get people to care about their jobs and their company.

And yet, I told myself, why not? I had made the company so I could fix it. This was an insight filled with pitfalls but it was an insight: the fault was not someone else’s, the fault was mine.

It reminds me a lot of the following quote which is attributed to Dr Paul Batalden (although apparently also to several others!) who was influenced by W. Edwards Deming.

“Every system is perfectly designed to get the results it gets.”

I think this is something which is very easy to forget and we probably end up placing too much emphasis on the individual and forget the context in which they are operating.

For example, it’s much easier to perform well working in a team in an organisation which really buys into the agile/lean way of doing things than it is in one where a strong culture of hierarchy, a tendency to favour the big up front approach and a culture where politics and politics and bureaucracy are rife.

Another interesting observation is that his employees were so used to him solving their problems that even when given permission to solve problems they struggled to do so:

They were good soldiers, and they did their best, but I had trained them to expect me to solve their problems. I had nurtured their inability by expecting them to be incapable; now they met my expectations with an inability to make decisions unless they knew which decisions I wanted them to make.

I wonder if this explains why when you try to work in an agile way with a team which is used to a strict hierarchy they will initially find it difficult to challenge any decisions and solve their own problems.

This links well with another thing I noticed as I was reading the article - it takes a long time to change a system. The article covers a period of around 5 years and still there is more that can be done to make the organisation even better.

Another good insight is that we don’t need to have a grand plan in order to initiate change – we can just do it:

These system changes taught me two more valuable lessons. First, just start. Don’t wait until you have all the answers…if I had waited until I had all the answers, I’d still be waiting. A grand plan was impossible…I just knew I had to change something in order to alter expectations and begin moving toward my goal.

This links closely to the idea of asking for forgiveness rather than getting permission which I’ve had drilled into me by my more experienced colleagues over the years! I’m sure there are situations in which that advice doesn’t apply but the majority of the time it seems like a pretty good mantra to follow and encourages you to be more active and try and make something good happen.

There is a tendency when coaching that as soon as someone isn’t doing something as well as you would/think you would to immediately take back control of the problem which the author identifies:

I wanted coordinators who could build problem-solving capacities in others rather than solve their problems for them…I took every opportunity to stress the need for coaching skills…whenever someone became a coordinator, I made sure word got around that the promotion was for demonstrated abilities as a teacher, coach, and facilitator.

This new promotion standard sent a new message: to get ahead at Johnsonville, you need a talent for cultivating and encouraging problem solvers and responsibility takers.

The problem with doing that is that you encourage the wrong behaviour but equally we need to ensure that
it is safe to fail otherwise people will be scared to make the wrong decision.

In software we can design this into the system by ensuring that we have tight feedback loops and by automating out the possibility of human error.

Another observation which I imagine will be fairly familiar to anyone working in software development is the following:

In our early enthusiasm, we had played down the technical aspects of our business, encouraging everyone to become a coordinator, even those who were far better suited to technical specialties.

A career team recommended that Johnsonville set up dual career tracks — one for specialists and one for coordinators — that would enable both to earn recognition, status, and compensation on the basis of performance alone.

ThoughtWorks seems to do this pretty well compared to a lot of companies where you end up becoming a manager if you are a very strong technician a.k.a The Peter Principle

Stayer ends with some interesting ideas on improving performance in organisations of which the stand out points for me were:

  • People want to be great. If they aren’t, it’s because management won’t let them be.
  • Learning is a process, not a goal. Each new insight creates a new layer of potential insights.

He also introduced a learning and personal development team to help employees improve themselves which seems like an interesting idea and one I hadn’t thought about before:

The traditional personnel department disappeared and was replaced by a learning and personal development team to help individual employees develop their own Points B and A — their destinations and starting points — and figure out how to use Johnsonville to reach their goals.

The summary of his learnings is perhaps the most insightful though:

I’ve learned that change is the real job of every effective business leader because change is about the present and the future, not about the past. There is no end to change. This story is only an interim report.

This is the idea of continuous improvement that lean thinking encourages us to embrace – it’s all about the journey and not the destination.

Reading this reminded me a lot of the way my colleague Pat Kua works in helping other people in his teams developer their skills and I’m hoping that InfoQ have recorded his talk from QCon London ‘Building the next generation of next leaders‘ which I’m told covers similar ground.

The Poppendieck’s also have an interesting video recorded at Google where they cover the role of leadership in software development.

This entry was posted in software-development. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to How I Learned to Let My Workers Lead

  1. Issa says:

    I believe that the problem here is that leaders are always tempted to micromanage their staff, real-time or online. If there is trust and good communication in the first place, a lot of issues could have been avoided. Still, this is a great post that managers should read. Thanks!

  2. Good article, but expresses a common misunderstanding that is all-too-common in programmer culture regarding hierarchical organization.

    Lean organizations are defacto hierarchies. Hierarchy is not only a hallmark of Lean, it’s also a necessity.

    I’m constantly dismayed by the dark imperatives of programmers who seek to dismantle the very thing that enables Lean to work and to apply opportunistic representations of Agile that issue from only one subculture (although a rather vocal and entrenched subculture) from with the Agile movement.

    The crux of the issue is failing to semantically-decouple hierarchy from bureaucracy. It’s not the hierarchy that hurts knowledge-generating organizations, it’s the mindlessness that is cultivated by orthodoxy. Bureaucracy is a particularly-toxic form of orthodoxy.

    The worst turn of events in the evolution of Agile development is the use of Agile ideology to justify programmers’ entitlements to be unmanged, and ultimately unmanageable. At this point in the game, I’d rather retrain linguistics and philosophy students to be software product developers that to continue to have to rehabilitate programmers from these misrepresentations of Agile. Ultimately, Agile has become so culturally rotten in the past five years that I wish that it would just go away. Self-Organization in Agile was never intended to mean Self-Determination.

    A leader in a Lean organization is the most skilled worker in the organization. He is also tasked as a teacher. His students are tasked with learning. They don’t get to decide whether they will or won’t. They are in a directed hierarchy, being directed toward greater ability by competent and experienced teachers and leaders. Dissent is still permitted, but poor decisions are still dealt with as poor decisiions, and accountability is paramount. This is a stark contrast to the organizational makeup of even the most “Agile” organizations. This quality of Lean organizations reflects deeper differences between Lean organizations and others – down to the most fundamental of unquestioned organizational assumptions.

    Before we fall in-step with mainstream, pop Agile’s presumptions of Lean as a subset of Agile and thus reflective of the same organizational and behavioral profiles, we could do well to take our studies of Lean beyond the scant few books about Lean that apply only to software development. If we’re not armed with the depths of knowledge underlying Lean, we risk just creating more rotten Agile.

Leave a Reply