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.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.