There it goes again.
I am sitting in the back courtyard of an Italian restaurant in Stuttgart Untertürkheim, eating spaghetti aglio e olio. With garlic. Luckily my next meeting is on the phone.
My lunch companion is going through the NewPDP material. Then he says:
“This is far too complex, nobody will get it. Take out the Drum Beat and drop the rest.”
I hear this over and over. Too complicated, too much, too big.
But is a simple transformation even possible when you have to turn an entire business system upside down?
I don’t think so. What must be, must be.
On one point, though, he is right.
The Drum Beat really is the piece to tackle first, because it lays the foundation for everything else.
That is exactly why I have detailed it out and made it operationally usable ever since I introduced the NewPDP here in January, in an article. And it is exactly why I will keep going deeper on it.
Along the way, though, I lost sight of the whole.
Four years of work went into this model. And so far I have written almost exclusively about one of its seven elements.
So maybe the complaint isn’t about the size at all.
Maybe it is about the fact that I never explained why each single element is needed and in what order it comes.
That is what I am doing today. And in the weeks ahead.
Please, subscribe to the newsletter so you get the whole story.
But first: what exactly is our problem?
On every stage in German industry someone is currently saying: “We are too slow, we should work as fast as the Chinese.”
But our slowness isn’t the only problem. It is much, much worse: we start far too late!
Not because we don’t know better, but because we can’t or won’t decide.
Slowness can be fought, and we will do exactly that here. But time that has passed cannot be brought back.
And to anyone who believes we will still catch up, I say: keep dreaming. The competition isn’t just clever, it is also damn fast.
So I will pursue both questions.
Why do we find it so hard to start?
And how do we get faster at the same time?
As if that weren’t difficult enough, I have to put one more unpleasant surprise on the table:
We are carrying a huge sandbag on our shoulders that many of our competitors don’t have to haul around.
Because many of our competitors are start-ups or goverment supported. They throw all their money and all their resources at a single topic of the future.
Profitability? That can wait until tomorrow.
Their investors wait patiently, hoping the profit will be all the more enormous somewhere down the line.
I come from the Old Economy.
There the investors want to see profit today, and not a small one either.
The mandate is clear: deliver a solid return today and finance the future at the same time!
That leads to the uncomfortable situation that we have to get considerably more out of the same money and the same people.
As the headline says: develop more without needing more.
Mission impossible?
I don’t think so, because the Old Economy has a few advantages of its own that we can use.
But one thing is beyond doubt for me: it takes a fundamental transformation.
Enough analysis.
Let’s look at the NewPDP, because it is designed as the answer to all of this.
Practices are the areas that have to be transformed, together with the methods that produce the effect.
Their order is chosen so that we first tackle what lays the groundwork for everything else.
In doing so I am already applying a principle I will come back to:
Prioritise the topics that create the highest gain in value right now. And those that produce the greatest loss in value if they are not dealt with immediately.
Enablers concern changes in the environment without which the transformation will not succeed.
Here there is no order. Leadership, organisation and architecture can and should be worked on at the same time.
Curious?
Then let’s take a short look at the essential features of each.
And if you are impatient, just write to me and we will go straight to the topic of your choice.
Pulling together, on one beat.
“We are currently working in QGx.”
I have heard this sentence over and over.
It is linguistic nonsense. You cannot work inside a gate. A gate is a checkpoint.
People say it anyway. Because our process only names the checkpoints and not the stretches in between.
There is no word for the period in which the work actually happens.
That is exactly the gap the Drum Beat System fills.
The Drum Beat gives the in-between a rhythm, a name and points of synchronisation.
The pomegranate tree model creates effectiveness through goal prioritisation and keeping everyone in sync.
The universal four-stroke cycle creates efficiency through error avoidance and structured preparation of the work.
Both are part of the Drum Beat System.
And a single rule carries the whole thing:
A Drum Beat is never stretched.
The moment the beat gets extended, we are back where we came from. Then we are negotiating dates again instead of content.
The Drum Beat System is the lubricant for everything else. When it works, the whole machine runs more easily.
That is why we start here.
Focus builds mastery.
Perceived complexity and volatility have pushed one insight out of view:
Skill comes from repetition.
Not every activity is complex, and not the whole environment is volatile. Repetitive activities in a stable environment exist, and they always will.
For those, the rule is:
Identify them,
define the way of working,
put the same people on them permanently.
And let those people improve their own way of working continuously.
Now comes the objection, and it comes reliably: isn’t that Taylorism?
Half of it, yes. What stays from Taylor is the fixed assignment. What goes is the separation of doing and improving.
I consider this one of the advantages of the Old Economy.
We actually know how to do this. Where it makes sense, we have to do it without compromise again.
And one more aspect: standardised processes are easier to automate and digitise than unstructured ones. That multiplies the efficiency gain.
That is why Learning Standard Routines come second.
Virtual before physical.
Digitalisation is on everybody’s lips. Everyone talks about AI, about virtualisation, about digital twins.
And rightly so.
Working on real hardware is slow and expensive.
So we have to virtualise whatever we can.
No doubt about it.
The challenge sits in that small qualifier: whatever we can.
Even if not everyone will agree with me here: as long as the product is a piece of hardware, a remainder of hardware work stays indispensable.
The decisive change is not to do away with hardware entirely.
It is to develop the same quality and the same functionality with the smallest possible amount of hardware, only far faster and far cheaper.
Now you are asking yourself how that is supposed to work?
That is exactly what we are going to find out.
Ready when it is needed.
I often hear: we have to bring new technologies to market faster.
My observation is that all too often we only decide to develop a new technology once we urgently need it.
That is too late!
But there is also the opposite mistake.
Investing too much in innovative technology too early.
A technology that sits finished on the shelf before anyone needs it is inventory. And inventory ages.
The knowledge walks out of the door with the people, and what is left falls behind.
So the challenge is not only speed, it is the right measure.
How do we manage the development of a technology so that it is ready exactly when we need it?
That is precisely what this practice deals with.
Clear direction, one team.
There are countless models and opinions on leadership.
Only one question interests me:
What does leadership have to deliver so that product development achieves outstanding results quickly and with minimal resources?
One answer up front:
Leading means working too. Whoever only decides is not leading.
What does the team decide for itself, and how is it enabled to live up to that responsibility?
Which tasks does the boss take on from the team, and how reliably does he deliver them?
This is about trust.
“One team” is not a platitude. It is an attitude, a company culture.
As in team sport, there are different players with different roles, and the way they play together has to be clearly understood and practised.
And there, too, you have set pieces.
And while we have the subject on the table, we will of course also look at leading yourself.
Structure follows the system.
For as long as I can remember I have watched the debate over whether a functional or a divisional organisation is the better form. The pendulum keeps changing direction, and in the end we almost always land at a matrix.
Now the agile enterprise is coming into fashion, and at the same time systems engineering is laying claim to the organisational form of development.
That names the actual problem.
Today the matrix has two dimensions: competence, meaning who can do it. And process, meaning how it runs. Systems engineering brings a third into play, namely product functionality.
Only a matrix does not survive a third dimension. Three memberships, three sets of goals, three people with a claim on the same person.
All three still have to be represented. But there can only be one organisation, and inside it one dimension always leads. That is already the case today, either the functional or the divisional one leads.
So the question is not how we add the third dimension. It is which principle leads from now on. And how the organisation is built around it.
We need an answer to that, because without a suitable organisational form fast and efficient work is not possible.
Modular progress.
It is every engineer’s dream to be allowed to develop a completely new product.
I even had that chance several times.
And every time, the organisation swore afterwards never to do such a thing again.
Endlessly expensive and endlessly long.
You are barely finished, and the product is already out of date. The next wishes are on the table.
As a consequence I have spent a lot of time on how to design hardware products modularly enough that improvements and new functionality can be developed incrementally.
Anyone coming from the software world will recognise the increment in that.
Over there it was the same for a long time. In the days of spaghetti code, almost everything had to be redone with every change.
It was object-oriented programming and the architectural principles that followed it that made the increment possible in the first place. That was decades ago.
In hardware, that development is still ahead of us.
Modular architectures have existed on our side for more than twenty years too.
They are simply not well enough understood and not cleanly enough defined.
That is exactly what this element is about. It is meant to close the gaps that stand in the way of incremental product development in mechatronics.
The NewPDP does not define what such an architecture concretely looks like. That would be too specific for a general framework.
It defines which properties and which processes it has to have.
Back to the courtyard in Untertürkheim. Take out the Drum Beat and drop the rest.
Here is my answer.
The seven elements do not stand next to each other, they interlock. Each one creates preconditions for the others, and each one benefits from the others.
That is the nature of a system.
Pick any two of them and ask yourself what one is worth without the other.
And in this shape the NewPDP is already a simplification.
It concentrates exclusively on those elements of the system that carry the greatest need for change in mechatronic product development today.
You can start with one element. In fact you have to. But with one alone you will not get there.
When I write another overview article some time from now, the story will hopefully look a little different.
We will have solved problems we no longer need to talk about, and there will be new challenges instead.
I am not writing this series to be right. I am writing it because I do this transformation together with people who are in the middle of it.
Join me.
And now I am curious.
Which of the seven elements is the biggest problem in your organisation? And which one would be the quickest win?
Write it in the comments, or send me a message directly.
And if you are facing this transformation and would rather not start alone, tell me that too.
Over the coming weeks I will take each element apart on its own. If you want the whole story, the best thing to do is subscribe to the newsletter.
And if you liked this article, share it.
Pass the newsletter on, so other people get something out of it too.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.