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.
When I found resistance to try new stuff, not about adopting a new thing, I wondered which was the reason; is it a lack of a safe space? is that they were tried in the past and they didn't succeed plus got the blame for it? is that they experienced the blame culture?
So, focusing on how I manage when team isn't open to try new stuff:
I aim to find those answers on our 1:1s, usually is more a fear factor than a lack of wanting to improve the workspace. It's a way more human factor than anything else.
In that situation, I try several things:
- I take the blame if something goes wrong.
- I'm dedicated with the team, we spend time together doing pair-programming to see and share the benefits of the proposal. Show don't tell approach here.
- I reduce the scope of the delivery. Giving slack time for learning and creating this culture of experimentation starts reducing the friction and barriers.
What's not optional for me is the _culture of continuous improvement_. That's for me a must, because everything else follows from this mindset.
Therefore, I align this for the Performance Review. Exists the expectation to be open-minded and try new stuff continuously. So, it's part of the culture and how the job is rewarded.
And of course, at the end, you celebrate when people learn from failures and you want to help them gain confidence that they won't be punished by failing.
At the very end, people that didn't adopt this mindset of try new stuff, they left by themselves the team or I, as leader, have the responsibility to let this person go if we don't see a mindset change after several months of feedback, because it might harm the _continuous improvement culture_ we aim to build. Hard but necessary.
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.
Thank you a lot for your words Felipe!
When I found resistance to try new stuff, not about adopting a new thing, I wondered which was the reason; is it a lack of a safe space? is that they were tried in the past and they didn't succeed plus got the blame for it? is that they experienced the blame culture?
So, focusing on how I manage when team isn't open to try new stuff:
I aim to find those answers on our 1:1s, usually is more a fear factor than a lack of wanting to improve the workspace. It's a way more human factor than anything else.
In that situation, I try several things:
- I take the blame if something goes wrong.
- I'm dedicated with the team, we spend time together doing pair-programming to see and share the benefits of the proposal. Show don't tell approach here.
- I reduce the scope of the delivery. Giving slack time for learning and creating this culture of experimentation starts reducing the friction and barriers.
What's not optional for me is the _culture of continuous improvement_. That's for me a must, because everything else follows from this mindset.
I usually present them the Celebration Grid (https://management30.com/wp-content/uploads/2015/03/celebration-grid-1024x732.png), and why it's important to see failures as successful experiments.
Therefore, I align this for the Performance Review. Exists the expectation to be open-minded and try new stuff continuously. So, it's part of the culture and how the job is rewarded.
And of course, at the end, you celebrate when people learn from failures and you want to help them gain confidence that they won't be punished by failing.
At the very end, people that didn't adopt this mindset of try new stuff, they left by themselves the team or I, as leader, have the responsibility to let this person go if we don't see a mindset change after several months of feedback, because it might harm the _continuous improvement culture_ we aim to build. Hard but necessary.