Do you give your team the space it needs to flourish?
It’s the start of your work day. You open up your calendar to check your schedule, scan through the list of meetings, and start to note down any prep work you might have to do. Your day is made up of jumping from one video call to another. If you were in an office building, it would usually have meant you’d be dashing from one meeting room to another, so you have to account for the commute time as well and short breaks you allow yourself in between. Because you are so busy in meetings during your work day, you find yourself having to put in some extra time to catch up with all the other bits of work you normally have to do.
It is natural for most of us who hold managerial positions today to have ended up in this position. We were likely given managerial opportunities because we had demonstrated our capability in being able to hold conversations that contributed to key technical decisions, helping our businesses move forward. As we became managers, somehow, we still find ourselves in this same position where we continue to represent our team or area. Others recognize you as a representative and think that it would be obvious to include you in the meeting. But what you have not accounted for is the fact that you are no longer in the know of specific implementation details and you find yourself in meetings having to check with your team for guidance. You think you are doing the team a favor by taking the meeting hit and keeping them away from what could just be noise.
What comes next? Because you are the key representative for your team, you usually end up in the position of conveying the plan on what needs to be done. Your team becomes a team that merely executes your instructions verbatim rather than being autonomous, leading to a lack of consideration in other elements. If you are lucky, then the delivery is successful. But sometimes, you will have made assumptions or missed something crucial and you’ll find yourself in a situation where a bad decision has been made and you have to deal with the repercussions.
Principles that guide us
In Expedia Group, we focus on our key values to drive our way of working and harness a company culture that emphasizes collaboration, empowerment, accountability, trust, and independence:
- Choose fearlessly
- Force simplicity
- Include consciously
- Trust each other
- Go get what’s next
These values overlap with Agile principles. Consider the first statement of the Agile Manifesto: ‘Individuals and interactions over processes and tools’. Our role as leaders is to remove as much friction as possible for our teams to allow them to achieve what they need to.
Many of us are familiar with the inspirational story of the Skunk Works team at Lockheed Martin who developed iconic planes, such as the SR-71 Blackbird. Kelly Johnson who headed the Skunk Works team set up a list of rules and practices that contributed to their success. Kelly put together a small team of engineers, and saw his position as creating the space where they had the freedom to operate away from all the bureaucracy that existed. At the same time, Kelly also made sure that the team had access to talk to whoever they needed to confer with. The team had well-defined objectives but were not given directives on how to achieve them either. Though borne as a product of World War II, these principles are still relevant to engineering teams today. When you look again at Expedia’s values, the Agile Manifesto, and how Skunk Works was managed, at the heart of it, they aim to achieve the same thing: putting together an autonomous team to deliver an objective and making sure they get there with little distraction.
Building future leaders
So what can we, as engineering leaders, do to cultivate effective teams? Let’s rewind back again to the start of the work day. Take a look at your calendar and start identifying the meetings where it makes more sense for representatives to come from your team. Do this regularly to not only give yourself time to focus on other things but also to create opportunities for your team to have those direct conversations and reduce the chances of misinformation. This is not about you getting time back, it is about creating opportunities for your engineers to grow. Your engineers will develop their communication skills and be able to contribute to alignment on outcomes along with being in a position where they are able to provide direction and guidance. These are skills that brought us to the positions we are in today as engineering leaders and we need to invest in developing the next generation.
By placing your engineers into collaboration opportunities, you are also strengthening their sense of ownership of the products that they look after. They know the situation and are better placed at making judgment calls.
Expose your networks
In our leadership positions, we gain access to far more information than our engineers do, and with that comes contacts that our engineers would not usually be aware of as they would usually stay within their focused verticals. Leaders have more horizontal views and can use their positions to provide introductions for their engineers and let them take those relationships further. This allows engineers to create conversation and synergy with other like-minded individuals and may bring about innovative ideas.
We should also give engineers the time and space to set up communities of practice for an area they are passionate about. This is where they can broaden their networks and find more engineers who are equally as interested in the same cause. You may have to initially use your position to help publicize these communities but over time, when the engineers have established themselves, they will be the ones championing the cause.
Product mindset
As leaders, we are expected to have a broader view of our products. We are often the first port of call of any ask from our stakeholders, sometimes deflecting what we see as noise to the teams. We absorb the information that gives us insights into business needs and value and our engineers sometimes never hear about this information. Product mindset is not exclusive to leaders and the product team. Engineers need to be connected to the product vision so that they understand the context of what they are developing. You also want to encourage your engineers to question and be in a position where they are able to make suggestions in approach and influence the product. They should be able to actively partner with product managers in understanding our users and the problems that we are trying to solve.
Define clear objectives
Trust your team to work out what needs to be done. Delegate and take your hands off the controls, but when you do pass on the controls to your team, they still need to know where they are going. Communicate the goal clearly to your team and give them the opportunity to ask the questions they need to clarify. The key requirements should be there but working with iterative development; the team should always be adaptive and flexible where needed. Resist being too prescriptive about the exact route they should be taking. You are there to guide and not there to draw up the route to the destination for them.
We are often biased to our experiences on what we deem as tried-and-tested solutions because we think this is less risky and perhaps the most efficient way to see through delivery. You might be right some of the time, but you also have your own blind spots. Give your team the space to figure the route out themselves.
Building great teams
A big part of our managerial role is in building great teams. We look for diverse personalities and nurture their talents so that they could one day be doing the same. And this is the point where we take a step back so that our teams can flourish. They need to experience what we ourselves have been through in our careers: to have learned from success and failures, to be bold at going after ambitious goals, and to find opportunities to experiment and innovate. Our work satisfaction comes from watching our team members grow to become the tech leaders we know they can be.
