EXPEDIA GROUP TECHNOLOGY — INNOVATION
Delivering with a Sense of Urgency
A framework for personal leadership
At Expedia Group™, we like to keep things simple and deliver fast. This creates an exciting and dynamic environment to work in. Engineering managers usually have some concept of a north star or direction on a project. However, it can often be a challenge to define “fast” using concrete progress metrics. Without a strong metric, if you start talking about going faster, it can quickly cause panic because team members jump to the conclusion that they are going “slow” now.
Instead, we often fall back to business judgement-based measures of velocity that can be susceptible to individuals’ perception. It can feel unfair to be measured by perceptions. But I believe that this can be an accelerator in an innovation project, as it encourages closer collaboration and trust-building with your stakeholders. That trust often comes down to you and your team presenting themselves with a sense of urgency. So how can a leader of the group increase that sense of urgency to foster trust?
The framework presented here is my own design to engineer success for you and your team.
Defining a sense of urgency
When I want to work on a cultural aspect of my team, I always look for a definition that I can transform into actions before I start. For a sense of urgency, I wanted to test my own leadership influence rather than try to change team dynamics. This is because I believe that most delivery quality aspects are impacted by how the team is managed rather than any individual contributor on the team.
So, I needed to find a definition of how a leader can demonstrate a sense of urgency. I used an article from Rob Llewellyn called “20 ways to create a sense of urgency” (link). This was a great article, but I felt like 20 were too many, so I selected 10 that felt the most useful. Now I had a definition that I could transform into action.
Demonstrating a sense of urgency
For the next three months, I tried to follow these 10 behaviours. Some examples of how I demonstrated them are:
- I removed tasks from our work in progress that were not immediate delivery goals.
- I explained the impact of not meeting our delivery deadlines — including possible sanctions we might face. This was a tough conversation to have with a group of people already working very hard.
- I worked with our product team to build a clearer roadmap of the outcomes we were after and the priority of each.
- Once a week I would take 5 minutes after a standup to share the roadmap and our progress towards it and highlight problem areas.
- I would tell the team about deadlines that were coming up and give my level of confidence in the delivery of each.
- I re-introduced stakeholder demos at release points to ensure we weren’t becoming complacent about releases and had a chance to celebrate them instead.
- I kept notes of actions people had asked of me personally and always followed up — I left no hanging conversations. If I could not deliver, I notified them immediately and negotiated an alternative.
- I made transparent & prudent decisions to unblock delivery at the cost of incurring either technical debt or a lack of team consensus
The following table shows the 10 behaviours that I selected, the feedback I received and from whom I received the feedback:
Did it work?
This was the first time I tried to change a team dynamic by focusing solely on how I personally behave. I didn’t know how far that personal demonstration would influence the team around me. What astounded me was that across the three-month experiment, people consistently gave me feedback that directly linked back to one of the behaviours I was consciously selecting. The feedback in Table 1 is just examples that were documented — there were many more informal or verbal examples. If you are a leader of a group of people, this is both empowering and humbling to realise.
That said, some behaviours were less well reflected back at me than others. For example, I put an inordinate amount of time into tracking action items that were sitting with me and maintaining accountability for those. In return, I only received a few non-direct pieces of feedback for that. By contrast, I didn’t do much more than normal to remove obstacles but that was the overwhelming area of positive feedback for me. I think this is a combination of what colleagues expect and what the current pain point is. In general, the team expected that I follow up on tasks, but removing obstacles was seen as more difficult and more important to the team. It meant that small effort in that behaviour exceeded expectations. In hindsight, 10 behaviours were probably too many and I should have focused on what was needed at that time — it would have saved me some energy.
If you are an engineering leader and you are operating in an environment where clear delivery metrics are elusive, or you have deliberately chosen to use collaboration and trust, how you behave will have a direct impact on the collective sense of urgency. Ultimately, this urgency manages stakeholder perceptions, which gives your team the space it needs to flourish while also driving your team to deliver faster. Why don’t you pick one of the urgency behaviours described here as your next quarterly goal?
