Being a long distance runner has taught me a lot about being an engineering leader. I’ve spent the last 15 years running races of all distances, some of which were great, and others that we’ll just call “learning opportunities”. I’ve also spent those same 15 years honing my skills as an engineering leader, during a career filled with great wins and more than a few “learning opportunities” as well.
This article comes at a bittersweet moment in my career. I am moving on to an exciting new role filled with great people and possibilities, but I’m also moving away from leading a team for which I have an immense amount of pride and respect. The lessons I’ve learned as a runner have translated well into my leadership approach with that team, and I’d like to share some thoughts on the intersection of the two.
Setting the Pace
Running may seem like a very individual activity, but for many, and especially in the world of long-distance running, that is often not true. While a lot of my running is done alone, some of the best or most rewarding runs are those where I am either being pushed to get better or pushing someone else to do the same. In many long-distance races, entire teams are set up, led by runners faster than the rest of the group, whose job it is to run, keep an even pace, and help everyone reach their time goal. While I have never served as a pace setter in a race, I have done it a lot when running with friends or family, and have run with pace groups in a number of races. I have found both being a pace setter, and following a pace setter, to be extremely rewarding experiences, for a variety of reasons.
Being a pace setter allows me to help someone else grow, to provide support for them as needed, and in some ways to enjoy and benefit from the run in a different way. Often times, when running at your own pace, it’s easy to forget to enjoy the run, to observe the environment around you, to think about different routes, or to reflect on the journey at the end. Pace setting forces you to think about the others you are running with, to push them when needed, or pull back when they’re doing well. It also allows you to reflect on your own running and goals.
On the flip side, running with a pace setter always pushes me to be better. While pace setters can’t do the running for me, it always helps to have a positive presence keeping me focused, to see someone running at my desired pace with ease who’ll help pick me up when I start to lag behind. Not only that, but on multiple occasions, I have decided to try to run ahead of the pace setter, which is an amazing mental boost when things are going well.
Leading From Beside
While pace setting was a concept I was intimately familiar with in the world of running, I only recently connected it to my style and approach as an engineering leader. In many ways, what I am trying to achieve is to get my team to run, and run fast. What I like most about pace setting is seeing how the group comes together to reach a shared goal. At times, individuals will be pushed into and out of their comfort zones, supported and challenged by those around them. While being led by a pace setter, it is the positive inertia of the group that is pushing everyone to succeed. It is my desire to build an engineering team with the same characteristic that has informed my decision to lead from beside.
First, let me add some detail on what I mean by leading from beside, and how it compares to leading from the front or behind. Being beside means staying close to your team, but relying on the expertise and experience of its individuals to help it succeed. Put in running terms, leading from beside ensures I’ll be around when the team gets tired and needs a little extra push, and also means that I’ll have to work hard to keep up when they really hit their stride. Leading from beside allows me to both keep an eye out for what is in front of the team, but also to reflect more on what is behind us, and to learn from all of the above.
If I were to lead from the front rather than being a pace setter, I would certainly demonstrate that hitting a fitness goal is possible given my own fitness level. However, what happens if they start to struggle? What if they hit “the wall” and have a tough mental hurdle to get over? While I can’t do the running for them, I will always be there to encourage and help them push through the pain. Most importantly, what if they start to run faster? Am I going to be forced to keep up, or am I just going to be in their way?
What if I were to lead from behind? Leading from behind might give them the sense that I believe in them and trust that they don’t need me, but what if I stop to tie my shoe and the next time they look back, I’m out of sight? Do they think I wasn’t able to keep up, and therefore, are now questioning their own ability? What if they want to bounce an idea off of me, but I’m not close enough to hear it?
What I love most about leading from beside is the effect it has as you add others to the group. I ran an actual race a few months ago, and at one point I passed two friends running together, one of which was wearing an iPhone, and it was playing the Hamilton soundtrack (a personal favorite of mine). As I was passing the runners, Right Hand Man was playing, which has such a great cadence and slightly aggressive tone that it was exactly what I needed to get an extra burst of energy. All I could muster to say to them as I ran by, given my lack of oxygen, was “great choice” but it was amazing to me how much their presence affected my own mindset and performance. This is the same effect I’ve seen when leading from beside. Rather than everyone feeling like they need to look to me for everything, they start to look to each other for answers and motivation, and that is exactly where I want them to be.
The last benefit of leading from beside, personally, is that it forces me to become faster. If my team, or individuals on it, get faster, I need to be faster to keep up. This is exactly what happened with my current team, and I thank them all for it. Not only is the team moving at a speedier pace, but the individuals on it are too, and they afforded me the opportunity to try to keep up and challenge my own fitness level to stay ahead of their rapid pace.
About Those Scissors
OK, so now the team is running, and I’m helping them do so. The real win, however, is when you get the team running with scissors. I not only want to give people scissors, but I want them to have blade sharpeners with ergonomic carbon-fiber handles. Oh, and probably some tape, because sometimes the cuts just aren’t perfect.
So what are these scissors? What am I referring to? Scissors are the tools that I find most important and have nothing to do with development environments, computer specs, or specific technical skills. Instead, scissors are the skills that allow everyone on the team to solve their own problems. These skills include teaching them how and where to find information, who to talk to for answers, and when and how to elevate issues. In my experience, teams move fast when there is as much distributed knowledge as possible. While many teams have subject matter experts, they become even larger multipliers when they share their knowledge to make their whole team faster.
To go full-nerd for a second, I think of it like RAID (Redundant Array of Independent Disks) in the world of data storage. Sure, having a single, high-performance disk is good, but it has a few big problems. First, what if that disk is already trying to do too many things? This is the exact knowledge bottleneck that is seen on teams with a lot of stove-piped knowledge. RAID has provided for increased performance over fast single disks, and distributed knowledge does the same to help teams move faster.
Second, what if that single disk fails? While people hopefully don’t fail in the same way that a disk would, they often move to new teams, want to work on new tech, etc. Having distributed knowledge means engineers can move in and out of the team, picking up important pieces of knowledge, so that no single loss is catastrophic. So, I guess rather than a RAID , what I really want to build is a RAIT (Redundant Array of Independent Thinkers).
Teams can move faster and avoid catastrophic failures when they are comprised of people who can solve their own problems and are pushed to share knowledge. Most leaders stress the importance of growing your network, but I think the important contribution of great leaders is their ability to help teams understand when, and how, to utilize that network in order to achieve better solutions to their problems quicker.
It’s All About the Runners
I want to address what I’m sure is in the minds of some while reading this article. Much of what I’m describing sounds great, but I think it is clear that not just any group of people can make it work. Early in my career I had a great mentor who pushed hard on the “First Who, Then What – get the right people on the bus” concept from the Jim Collins book Good to Great. I am very fortunate to work at Wayfair, a company that hires bright software engineers with whom I have had the pleasure of working. I have no doubt we’re getting the right people on the bus, or maybe the right people on the running team to continue the analogy. However, the next part of Jim’s concept is “the right people in the right seats”, which is a little more complicated.
When I transferred onto my mentor’s team, the first question he asked was “What do you think your role is on the team?”. Rather than posing this question, he easily could’ve said “Here is your role and what I need you to do”. I came to learn later that he loved these types of open-ended questions, which at times felt a little bit like a quiz that I hadn’t quite studied for, but which always ended up in a more nuanced and interesting conversation. Engaging people in defining their role not only clarifies expectations, but often opens up opportunities that wouldn’t have been considered otherwise.
To relate this back to the concept of leading from beside, getting people in the right seats requires understanding who is on the bus, which seat they are currently in, and which seat they want to be in. Since Wayfair has a very high bar for talent, it is an expectation that everyone is thinking about how they are constantly improving and trying to build their skills to move to a seat on the bus where they can make a greater impact. The thing I like most about this idea is that the movement feels more organic and healthy when it is driven by an individual themselves, rather than being dictated by a leader who doesn’t combine the needs of business with the goals and skills of individuals. A great model for success is a bus filled with people who are distributing knowledge and are in seats/roles that they helped define.
Lastly, I want to call out that none of this would be possible without my own manager/leader giving me the freedom to run with my own scissors. My manager and I are different in many ways, but one core principle we share is empowering people to do the right thing for themselves and their teams. In our first meeting when I joined the team, I asked my manager how involved he wanted to be in defining how the team that I would be managing operated. His response, which I’ve used in my own meetings with those that I’m mentoring, was simple: “People don’t need two managers”. Accountability without micromanagement is a powerful combination. Being trusted to do the right thing, but knowing I have support when needed, has been extremely empowering for me personally and professionally.
Practice Makes Perfect
Alright, this all sounds well and good, but does it work in the real world with a fast-moving, constantly evolving organization? I’d like to walk through how leading from beside, while working with a team adept at running with scissors, helped drive amazing results in a short time frame on a mission-critical effort at Wayfair.
Picture this… you have a huge deadline coming up. For my team, this was a massive site-wide sale, and we just discovered that while a lot of people have been talking, some critical requirements have been missed. Expectations are high, but implementation details are lacking, putting the entire effort at major risk. Multiple teams are moving quickly to get their code ready to support the event, but much of the underlying architecture is lacking or incapable of performing the jobs that were going to be asked of it. Oh, and on top of all of this ambiguity, let’s add to it that the upcoming event is a first for the company, and traffic expectations suggest it will be one of the biggest days of the year.
Where to begin? Problems were identified, but a lot had to be done, and quickly. Luckily for me, I already had a team who had been running for awhile, and whose scissors were sharp.
The first step was to move past problems and to start working on solutions. My team and I claimed ownership of a whiteboard and got to work. We bounced ideas around, called out challenges with approaches, drew system diagrams and data flows, and identified opportunities to make our code more generic and powerful. At times I was driving the discussion, at others I was calling out unknowns that needed clarification, and in other cases I was just along for the ride as the team worked through blockers. At the end of the first day we had a whiteboard that looked straight out of “A Beautiful Mind”, covered with boxes connected to functions wrapped in diagrams. It was the result of a group of engineers who were only focused on solving a specific, event-critical problem, with no concern of “who” should be responsible for any part of the solution.
The next day we embarked on making our vision a reality, and one of the members of the whiteboarding crew set off to turn whiteboard into code. At this point I could return to connecting with stakeholders, sharing the vision for how we were going to solve this big problem, and making sure everyone was on the same page, while my team put hands to keyboard to make it real. Now, did they just blindly code away, never asking a question or clarifying the vision? Absolutely not, which is the most important part of learning how to use scissors. Great teams, and individuals, know when to ask questions versus just tackling the problem. We had a number of great follow-up conversations while code was being written: Two days later we had a solid prototype, two days after that other teams were using our code, and a week later we were doing site-wide tests in preparation for the big day.
Why was leading from beside the right answer in this situation? Quite simply, there was no other option. There was no time to get ahead of the team, and the timeline was too short to try and let people get ahead of me while leading from behind. The only way this effort would have been successful would be to have everyone working side-by-side, solving problems in real-time, connecting with the right people to get the job done, and doing their part to make the team successful.
After all of the excitement, including a few long nights of tweaking, fixing, and watching the system we built work successfully, we took away a lot of great learnings from our retrospectives to help us avoid similar situations in the future. The beautiful thing, however, is that in shaping a team that can react and execute to solve large problems quickly during periods of intense pressure and ambiguity, you’ve also built a team that can execute day-to-day with maximum efficiency and success.
Enjoy the Run
Get ready to lace up those new running shoes and pop open that package of shiny new scissors. Helping your team run faster means connecting them with other experts, sharing knowledge, helping them solve their own problems, and being around when they need a hand. I hope everyone gets the opportunity to work with an amazing team like I have. They’ve taught me more than I ever could’ve hoped for, and I am heartened to think about the pride I’ll feel as I see them continue to win race after race.
Oh, and don’t really run with scissors. It’s dangerous.
