As a leader, I understood that I own the consequences of the team's and my own decisions.
What I didn’t know is that you also have some accountability for the decisions made in the past before you were there. Or at least, I ignored how much they influenced all the decision-making.
Understanding the Legacy
I’m a software engineer. I have dealt with Legacy Systems, refactored them, added monitoring to them, adapted them to the new business needs, and even made the obvious mistake of redoing a Legacy System from scratch.
After several years of dealing with Legacy Software Systems, I thought I knew how to deal with them.
Damn. Legacy Software Systems are easier than Legacy Sociotechnical Systems. In addition, I also ignored that all Legacies are Sociotechnical Systems. Therefore, when I dealt with Legacies, I ignored the Sociotechnical part.
Legacies can show in many forms, but I would like to focus on two main categories:
A Legacy without people working on it. The dev team might be working on something else, or they left the organization.
A Legacy with people working on it. People are still working on the products/projects, but leaders/managers or people with the vision/purpose left the organization.
The former is the one I’m most familiar with. A System is abandoned in pursuit of new business models. It starts with a sentence as “we will put this product in maintenance mode to focus on more business priority stuff.”
The latter is one I will speak about in this post. That Legacy is harder to identify. It’s not obvious it’s a Legacy, and it doesn’t feel like it has technical debt only. It can feel like bad management/leadership, poor vision, too much leadership rotation, or lack of direction…
I experienced it when I joined as a leader in a team or tribe.
It happens in other scenarios when an experienced team member or a person with strong influence like a Product Manager leaves and they are being replaced.
This new person will be dealing with a Legacy Sociotechnical System. By having this understanding, we can act on it and acknowledge our ignorance of the past.
Leader A leaves with huge knowledge about the decisions made, commitments, people’s growth expectations, why the teams are organized the way they are, and more. Leader B ignores all of that.
Side topic. Here is a Twitter thread about rotation, learning, and how it affects decision-making quality 👇
Avoiding the trap of “I can do it better”
From now on, we will assume we are leader B. We are joining a team or a tribe, and our leaders start onboarding us in the company context.
Our leadership is busy and we will go straight to the points on the onboarding.
Our culture and purpose
Our deliverables
The team structure
…
What’s not working and needs to be fixed
Leadership wants us to fix what’s not working. That’s why we tend to focus on sharing the bad parts. Still, we don’t share a thing that it’s so important and valuable. What worked. Or the experiments and decisions that led the company where it’s today.
By listening to what’s not working, we start creating ideas and beliefs about why it hasn’t worked. And when we join the team on the day to day, we seek those facts that can confirm our beliefs.
Aha! Here’s technical debt, I could have done that better.
I see, the team isn’t cross-functional!
There’s not enough testing!
In less than a month, we have plenty of facts that confirm our beliefs. Previous leadership didn’t know their stuff.
Does it sound familiar to you? You just got into the trap of Confirmation Bias.
Confirmation bias is the tendency to search for, interpret, favor, and recall information in a way that confirms or supports one's prior beliefs or values - Wikipedia
To make it worst, you find some decisions that you clearly know that they are wrong.
We couldn’t have done that mistake, we’re better than average. Damn! If we could have joined the team earlier, all that decisions wouldn’t be there and we can be in a way better place now!
In the end, we’re a better X than the average. We will do it our way.
Do you know what is that? Another type of Cognitive Bias. In this case, it is the Overconfidence Bias.
The overconfidence effect is a well-established bias in which a person's subjective confidence in his or her judgments is reliably greater than the objective accuracy of those judgments, especially when confidence is relatively high - Wikipedia
👆Image of ourselves when we realize and accept we make mistakes like everyone else and we do the best we can given the situation at hand.
We need to be careful to not accept all the information that we receive as facts. We all have our own perspective of the complexities, what’s working or not working.
When listening to what’s not working, be open-minded.
What led the previous leader to do what they did? What are we ignoring in their context? How can we learn from the past decisions and why they were made that way?
Honor the past
People's work and effort to put the business where it’s today cannot be underestimated. Indeed, it should be honored.
Their work have helped you to get the position you’re in today, they are expecting a lot from you, and you should be grateful that now you can help them in achieving more for more time.
Always consider that you don’t know why they did what they did. Challenge your own beliefs.
You are building on top of other people’s legacy!
It doesn't mean you cannot change it if stuff needs to be changed! It’s about being mindful about you not knowing the full story.
Commit to the Legacy
It’s not about starting from scratch. It’s about getting the Legacy and improving it.
I understood that you cannot adapt everything to your vision or ways of working when you join an organization the hard way. But after fighting the reality and taking a lot of energy with it, I started to accept the Legacy.
If I accept some of the decisions, even if I disagree, I can take steps in a new direction.
If I understand the previous vision, I can understand why the decisions, and we can build a new vision on top of it. That new vision will take into account where we come from. Instead of forcing a team into a new scenario all of a sudden, we take into account where we are and where we want to go.
My recommendation is that when you join a new team/company in a leadership position. Commit to the previous decision as if they were yours. Own them, understand them, and it will bring the different learnings that come with them.
Only then you’re able to drive a new direction to something you believe is better.
Similarities to how we deal with Legacy Software Refactors
Would you change a full legacy system to a new brand new system from one day to the other?
Then, why would you replace a team with another team?
Would you change an MVP Architecture to Hexagonal Architecture from one day to the other?
Then, why would you change the ways of working from one day to the other?
Would you replace some behavior of the Big Ball of Mood Legacy without adding the proper tests to know if you broke something?
They, why would you start moving pieces without being careful about what you broke?
We are dealing with people, and when Sociotechnical System breaks, it will be orders of magnitude harder to fix.
Closing
We need to be way more careful when dealing with Legacy Sociotechnical Systems.
We are dealing with highly complex adaptive organizations, and the best way to manage the future is to understand the past first.
The Legacy is your best ally to build on top of it. Instead of fighting it, join forces to evolve together.
Meme for you
