Overcorrecting and Oscillation
When I started kayaking, I always used a rudder for steering, which is very convenient. But then I learned that most advanced kayakers steer their kayak by shifting their body weight, tilting the kayak and by using a variety of different paddle strokes - their kayaks don’t even have rudders. Needless to say that I wanted to try this myself as soon as I felt I had left the beginner’s state. So I removed my rudder and started paddling. First it went really well, but soon enough the wind picked up just a little bit, and from that moment on I was moving in a ridiculous zigzag course. What was happening? The wind was blowing sideways, and my kayak started moving in one direction. To correct this, I steered in the other direction. But because I was very inexperienced, I did not understand when and how much I needed to counteract. So I often steered too much, which made the kayak now turn in the other direction. This made me counteract again, and again too much. So in effect I was either going left or right, but never in the direction I actually wanted to go. In addition, it was a very exhausting and frustrating.
For those of you who don’t paddle kayak, it’s probably easier to relate to another example: Imagine you check-in to a hotel and you want to take a shower. You turn on the water, but it’s way too cold. Yelling some curse words, you immediately turn the knob in the other direction. After a few more seconds of freezing, you are now being boiled, which makes you turn the knob to the other side again…
Overcorrecting
One issue in both scenarios is overcorrecting, which often leads to oscillation between two extremes, where neither gives us the upsides we were hoping for. In my experience, overcorrecting is also quite common in companies. One striking example being oscillating between the poles of centralization and decentralization.
Imagine, you are a tech manager joining a new organization. One of the first things you observe is that the product teams are blocked all the time, because they are waiting for designs. You also notice quickly that all the designers are part of one central design team. Every time the engineers need a design, they have to request it from the design team. This takes time, because the design team is also working on their own roadmap, and naturally the engineering requests don’t always have the highest priority. Besides the long wait times, this also leads to another problem: Design is always an afterthought for the product teams, because they don’t have strong design expertise in their team. So the designers are constantly playing catch-up, trying to build good design into the product at the very end. Of course that’s not working, and in the end everyone is frustrated!
Knowing about the benefits of cross-functional teams, you decide to reorganize: Every engineering team now has a designer as full-time member, the centralized design team is no longer. That should fix the problem.
Illustration 1: The current state is perceived as the problem.
Decentralized design looks like the solution
Fast forward a couple of months, Wendy takes over your R&D department (congrats to your promotion!). Wendy immediately notices the inconsistent design in your product. The web app looks totally different from the website, which in turn looks different than each of the mobile apps. Just for fun Wendy counts how many different versions of a check-out button she can find: It’s 15! No wonder the product design is lacking consistency, when there are no strong design standards. And how could there be strong standards, when the designers are not talking to each other, because they are fully occupied supporting their respective product team? Wendy starts to dislike these cross-functional teams. To make matters worse, she realized that onboarding for new designers is really tricky. Whenever a new designer starts working, they immediately become a member of a product team, in which they are the only designer. This makes it really hard to understand what good design means in this org. It also makes it hard for designers to improve their craft, because they are not spending a lot of time with more senior designers. When Wendy fully understands this, her decision is made: What the org needs is a strong central design function. So bye bye cross-functional teams! But not before long and someone discovers that delivery has slowed down, because product teams have to wait for design support…
Illustration 2:
What seemed to be the solution (decentralized design),
is now perceived as the problem.
Oscillating between cross-functional teams and functional teams is quite common in tech organizations. And the designers were just one example: You can easily swap them out for data scientists, user researchers, machine learning engineers, or any other specialist function.
While it’s understandable why this happens, there’s a bunch of problems with this approach:
Neither of the two poles might be the best solution. The optimum probably lies somewhere in between, but thinking in binaries makes it hard to even explore hybrid solutions.
There’s a strong focus on the negatives of the status quo, while the things that are already working well are often overlooked.
Big, frequent changes like these might lead to frustration, especially with those who have been through the whole cycle before (“Oh, great, now we are back to cross-functional teams, which we had when I started 2 years ago”).
Moving from one pole to the other often creates unrealistic expectations. Folks might think: “Once we have implemented the new structure, all these known problems will disappear.”
Moving back and forth between two poles makes it hard to continuously improve. What’s the point in reflecting on the old structure, when it’s already decided that this was the “wrong” solution and that the new solution will solve all the problems?
What to do instead?
Whenever we find ourselves in discussions like: “Should we do A or B?” Or “A is surely better than B!”, it’s useful to slow down for a moment and explore the middle ground between A and B. Some questions that are worth discussing (either in a 1:1 setting or as a workshop involving a larger group) might be:
How would a solution look like, that’s 100% on pole A or B? What would be the pros and the cons?
What would happen, if we would do 90%, 80% or 70% of A and B? Would we still get the major benefits, without seeing some of the downsides?
If we are leaning towards pole A: Have we had this solution in our organization before? What was it like? What did we learn? Why did we change it to B?
If we are now moving towards pole A: What do we expect to see? How will we know we are getting what we are looking for? How will we know that we need to adjust (and not go back all the way to pole B)?
Takeaways
Overcorrecting is quite usual in companies: Someone recognizes the problems with the current situation and causes a change to the opposite pole. After a while the downsides of this pole become evident, so the pendulum swings back to the other pole. This organizational oscillation often leads to sub-optimal solutions. Next time we consider making such a big shift, we should take some time to discuss solutions that break away from the common binary thinking and evaluate the gray area in between the two poles in question.
P.S. In this post I’ve used centralization vs. decentralization as an example for oscillation, but there are many others of course. Stable teams vs. fluid teams is another dichotomy that can frequently be observed. Check out this post I wrote on the topic.
Möchten Sie Flow und Effektivität verbessern?
Zusammen mit meinem Bruder Stefan (ja, das sind wir auf dem Bild) gebe ich am 18./19.12.2024 eine Schulung in Hamburg. Dort werden wir mit vielen Praxisbeispielen erörtern, wie man Unternehmen auf Effektivität, Flow und Innovation ausrichten kann.