When talking with your teams, are there certain words you tend to use more than others? Through a variety of interactions (1:1’s, team meetings, workshops, etc), I realised there are 3 words I found myself regularly using. It reminded me of the what2words geocode system. Mine are mindset.balance.judgement. I see them as my 3 words of leadership. These won’t help me navigate to a precise location, but I find them useful in guiding how teams and individuals navigate different situations.
Here’s how I think about each one…
How we approach different situations is quite telling in our attitude and overall outlook. Work life is full of ups and downs with an ongoing cycle of challenges such as: changing requirements, deadlines, production incidents, hiring freezes, redundancies, etc. They can weigh us down and affect our thought process.
The growth/fixed mindsets may come to mind. While we need to understand these when working with individuals, when I say ‘mindset’, it’s more in the context of teams and delivery. More often than not we’re asked to do more with less. So how teams navigate through the decisions they need to make often determines the success or failure of a project.
There are different contexts I find myself saying “mindset” but the 2 most common ones are product mindset and testing mindset.
What are the different ways we can approach the requirement or problem in front of us to achieve the most value for our customers? Many times engineers simply ‘do what they’re told’ – requirements come in, they implement what’s written on the ticket. This isn’t using a product mindset.
It’s not solely down to the Product Managers to determine every product decision, the team must be involved. Engineers need to develop a commercial understanding to form their own opinions on what would be of value. This means being closer to customers or customer facing business functions. This provides more data for the team to discuss and increases opportunities for them to influence a change of direction.
I’ve seen a lead influence the Product team to change their strategy on a new feature which resulted in this feature being showcased by marketing and sales teams. This was all because the lead had a product mindset and was passionate about the value it could give to the customers.
The more we can develop our product mindsets the more we help our businesses succeed. Enabling more time for hackathons or ‘20% time’ allows engineers to work on their ideas and even spark innovation across teams that could change business strategy for the better.
Many engineers are too focused on their coding and not the testing. When they finish it’s ‘throw over the fence’ to be tested. This doesn’t work in fast moving organisations, especially those that only have automated testers (or no testers at all!).
The mindset I look for in engineers is if your code is ready to be merged, it must be good enough to go into production. This means engineers are responsible for its quality, ensuring there is appropriate coverage, be it unit/integration/E2E tests implemented. They should have confidence that change does what it’s intended for without adversely impacting other parts of the system, even if it’s behind a feature flag. This mindset doesn’t come naturally to everyone. It means thinking about testing early during planning and ensuring it’s factored into estimates.
This is why ‘mindset’ is in my 3 words and I use it regularly across multiple areas. Ultimately, I aim to challenge people’s thinking (including my own!) so we can learn together.
I find that with everything there’s a balance. This might even be my most used word! We have a tendency to go too far in certain directions, even extremes, without a more measured approach.
I notice myself saying ‘balance’ quite often in conversations. Emotions can drive us into making decisions, add our biases into the mix and we can end up rushing into situations without properly assessing different factors.
The reality in work life is that things happen that we don’t agree with, many of these are out of our control. How we react though is in our control. A balanced approach allows us to measure options without making rash decisions that might take longer to put right.
Even in times when decisions need to be made quickly. Being able to put guardrails around certain actions can minimise any negative impact if they prove to be wrong. Having an awareness of different options and how they might play out enables ‘balance’ in the thought process.
I often use ‘balance’ when talking about people’s use of time. How we use our time is a skill, so encouraging others to consider the value of different options and outcomes helps them to prioritise. I tend to ask questions like: How much time should you spend on this? How much documentation is enough? How much testing is the right amount? Can you finish one task off before starting on another?
As I said, with everything there is a balance, so the more I can encourage a measured approach across teams the more confident we can be in our direction.
This is showing the ability to make sensible decisions. We all make hundreds of decisions every day, many we don’t even think about. However, within engineering and product development, there can be many layers of uncertainty. It’s here that I ask people to use good judgement for their individual choices and as a team.
- Which change will be of most value to our customers?
- What are the trade-offs for making this change?
- Do we really need to do this?
- Should I increase the test coverage or fix a defect?
- How can this project be sliced and deployed early to learn its value?
In a busy working day, leaders don’t have time (or even the context) to make decisions for the teams. Plus, it would only slow things down if they do! I’m looking for engineers and leads to show proactiveness by making judgement calls based on the data they have and showing the ability to understand and make trade-offs.
When more autonomy is given to teams, making good judgement calls is essential. They have to take responsibility for their use of time and ensuring their output is of business value, this needs good judgement.
Wrong decisions are ok as long as there is sensible reasoning and it didn’t take long to realise the mistake. This is how we learn and grow. Engineers need a safe space to make mistakes. If we’re not making mistakes are we really challenging ourselves?
Many of my conversations around ‘judgement’ is installing confidence in the person so they (or their team) can make the decisions. I look for healthy discussions between leads, engineers, and PMs where they weigh up trade-offs and make judgement calls to move forward.
Obviously, there are exceptions with urgent issues. Even so, good communication is vital throughout, making visible what the decision is and why. If anyone disagrees or wants to understand more they can ask, otherwise, the flow of the team continues.
These are my ‘what 3 words of leadership’. They are used in many different contexts of working life. I also have different expectations depending on the level of the person.
For a junior engineer, it’s about supporting them in how they think through different situations. It’s not about being right or wrong but thinking through the many options available along with their trade-offs to decide how to move forward. For senior levels and leads, I’m looking for them to be role models, taking initiative while having aptitude to make sensible decisions.
Over to you, what are your 3 words of leadership?
This is also posted at https://www.linkedin.com/pulse/what-3-words-leadership-stephen-sitton-70due