Pull Systems instead of Push to drive team change
A change lead by the team instead of the leader
2021 has been a he*l of a year. Full of improvements, changes, deliverables, and meaningful relationships. Overall, I’m proud of how far we have pushed ourselves and excited about what’s coming next 😄
In this post, I like to share with you the huge learning I had as a Leader of, I would say, 2 teams in at least 3 different contexts and moments.
Ego factor ( ￣^￣)
I joined Creditas in March 2021 as Engineering Manager, full of energy and ideas, biased ideas, and willing to make an important impact soon. Half needing to prove myself, half impostor-syndrome/ego.
I admit I have an ego, in the past years, it has been conditioning my life decision-making. After some time and therapy, I have been able to recognize when I’m being led by it instead of being myself.
The ego also affected, to some degree, how I lead the team, and in specific, how I introduced change just after joining Creditas. Lucky me and the people around me, I have been able to manage it better and better.
By the book 📕
You might know that I’m a book lover and sometimes I’m square-head, if I don’t find something logical or that doesn’t make sense, it’s hard to convince me.
I had an opinionated vision of how an engineering team should work, in terms of practices, methodologies, and team composition. I’m always open to new information to make better decisions, but the degree of changing direction sometimes I’m as flexible as I should be.
It happened when I joined Creditas. I wanted to help build an incredible team, a team that:
Does Pair-Programming
Trunk-Based Development
Continuous Deployment
Observability and Monitoring
Test-Driven Development
…
That’s a lot, and it means asking the team a lot. You can either:
Be super strict during hiring, which doesn’t make any sense because very few engineers excel at all that stuff, and it will take you years to build the team.
You hire people with an amazing attitude and you coach those skills
I went for the second option.
Attitude is key, but it depends 😅
It depends on how you are introducing change.
Push based system
To be honest, most of the resources available are about this type of change. Digital Transformation, Agile Transformation, (or the wrong interpretation of them)… Someone at the top decided that we need to do XYZ. Yet, we think that by introducing coaching and learnings we are doing a great job.
You present the idea to the team.
What about trying this? It comes with training and we will do some katas, book clubs, or discussion panels.
Because you hired people with a great attitude, you probably get a yes to try new stuff. They hopping that today, in this job, they have more freedom to decide how to work and try new stuff.
Today, I disagree.
Because my expectation was that, after the training, the methodology, tool, or practice be implemented in the team. Yes, you can think of I’m being a good leader because I provide training during working hours! I’m so good!
Still, a top-down approach or a Push-Based Approach. It has several drawbacks:
You don’t give the team the option of not adopting a new methodology, practice, or tool.
Looks like it’s forced to be done this way, yet they might not feel the improvement you were willing to get from the new approach to do stuff.
Team members feel trapped and unable to say no to the new approach, leaving them few actions to improve their work environment, one of them is to leave the team or the company.
You might succeed with the first or maybe two times you purpose something to the team to try, after some time, you will start experimenting some resistance to change.
You’re burning people and their good attitude. Because you’re not giving them the option to say no.
That’s when I learned more about Pull Based Systems to introduce change.
Pull Based Systems to drive change
Pull Based System to drive change is about creating situation awareness about the problems or the improvements you think are worth addressing with the team, yet giving up to the team adopt them whenever they feel more confident they are ready to experiment to introduce an improvement.
As a leader, you’re not in the day-to-day. Assuming which are the next things to improve are exactly that, assumptions. You might know which are the good things that are worth improving based on your experience, and there’s a good shot that you’re right.
Yet, it’s better to collect data and metrics to show the team how you resonate about the things you consider important to be improved.
Showing the metrics to be improved instead of the improvements
That’s your role as a Leader, drive direction. What I have been investing more and more time with the team is about how I think it’s best to measure team performance and drive actions to improve it, aka Situation Awareness.
4 Key Metrics of Accelerate
You can learn more about the 4 Key Metrics in Accelerate’s book or the 4 Key Metrics Community https://community.4keymetrics.dev
You can also find some posts I have about them like:
Cognitive Load
A concept I learned from Team Topologies.
When we talk about cognitive load, it’s easy to understand that any one person has a limit on how much information they can hold in their brains at any given moment.
Understanding if the developers have a high cognitive load, we can take actions to reduce them. Maybe they are unable to apply direct improvements compared to the 4 Key Metrics, but being able to identify if they can take some actions is awesome.
Flow Efficiency
The formula is straightforward. Yet, measuring it has been a good challenge. Learn about Flow Efficiency, and when you feel confident start giving that to the team.
I consider the first two, 4KM and Cognitive Load, to be better for the team to drive improvements than Flow Efficiency, yet take it into account.
Creating the picture of Ways of Working
⚠️ I’m still experimenting with this idea, read with caution!
Just imagine that you, instead of forcing down the methodologies or ways of working to the teams, you create a good picture about the things you aim to promote inside the company, like a vision of “we consider a team is going with software excellence when they start adopting/excelling at X, Y, Z practices”.
Then, teams will know what you are going after yet you’re not imposing it on them. Each team is in a different context and situation at hand, expecting that rolling out those practices to all of them and causing the same impact is non-sense.
Instead, each team with the situation awareness can go to a group of people that are experts in each practice or methodology you want to introduce into the company, and they ask for help on that matter.
This is a mind-blowing approach 🤯
The team accepts the change based on their pains, availability, and willingness to improve. You don’t push change but you help the team to pull the improvements.
Did you notice the paradigm change here?
Also, I wanted to share that this Pull Based System follows the adoption curve. Those willing to take the risk and adopt the practices are more willing to go there and adopt them proactively, and those that are more skeptical will adopt them when they don’t have another choice.
I learned that it doesn’t matter if skeptics don’t adopt the new ideas, they won’t do it either in Push or Pull-Based approaches. Yet, the enthusiasts and visionaries will lead the change in the teams for them without feeling the pressure of push-based.
A WIN-WIN SITUATION!
Continuous Improving Mindset
Didn't I share with you words of Accelerate yet? 🤣 Sometimes I feel that I repeat myself a lot.
Yet, Accelerate Book had a key part in driving change in the team in a Pull-Based Approach. I can summarize Accelerate as a Continuous Improving Mindset.
Early in the creation of the team, we did one thing. Create the Accelerate’s Book Club and dedicate one hour a week to discuss the chapters.
Since then, the team drives most of the improvements by themselves. I’m not saying that they do everything by themselves but proposing what they want to improve, and then we find the way to do it as a team.
I consider at least 3 different scenarios of improvements:
Team self-sufficient. The team identifies and improvement and they just implement it without leadership support.
Team with leadership support. The team identifies, but the improvement area is either out of their boundaries or requires help because there’s no team member with the knowledge to drive the improvement.
External support. The improvement is out of the team and leader responsibilities boundaries and requires organization support.
I have underestimated how the team can come by themselves with solutions, and drive them, and I even notice those improvements in my day to day but able to identify the good outcomes on metrics like Lead Time and Change Failure Rate of 4 Key Metrics.
Summary
A pull-Based System to introduce change is awesome and we can learn a lot by following this approach, yet it has downsides. Mainly regarding the team’s continuous improvement mindset.
In the end, it’s a trade-off and it will depend on your situation.
I wanted to share with you a new approach I learned and that it’s paying off! I hope you enjoyed it! Help me create more awareness for other managers and leaders that only know push-based approaches as I did some months ago 😄
Book and Course references
Dynamic Reteaming
One of the best discoveries this year. It’s not explicitly dedicated to Pull Based Systems to introduce change, but it covers a good portion of it on the mindset behind Reteaming. Worth every penny.
Platform as a Product - Team Topologies
In the Platform as a Product course by Team Topologies authors, they address the topic of the adoption curve of a Platform when the platform is optional, and how this brings a lot of value to the platform itself.
By applying the same concept for methodologies, you need to create a set of Ways of Working that is enough good that people adopt them because they provide high value in their day-to-day job instead of being imposed.
I will dedicate a post specifically about Flow and what I’m learning from Manuel Pais and Matthew Skelton.
Meme for you
Thanks for sharing these thoughts, Aleix! I really like the idea of setting a vision and letting the teams decide how to catch up with that vision. Any insights around how to go about teams that are more resistant to complying with that vision?
I reckon that not every developer is open to trying TDD, pair programming, trunk-based development, etc, but yet those are practices that add value, I was wondering what was your experience convincing the more resistant people to go in the direction that you find ideal or if in the end they convinced you to change your mind.