A developers blog

What the Heck do you Mean Pace, Don’t Lead

By: Brad

Hi Brad, in your previous post What the Heck is a Team Leader? there was a side note titled Pace, Don’t Lead. What the heck do you mean by that?

I saw a video once of David McTurk Former COO of Bookham Technologys talking about leadership. What he said in the video (Pace, don’t lead) got me to start reevaluating what I felt it meant to be a good leader and what I believed was expected of me in a leadership role. In the video he said that a good leader does not dominate their team, that is they don’t just sit there telling their team how to do things, but rather facilitates the team to lead themselves.


In the video he talked about being at a leadership retreat where he participated in a group activity of trying to get an object over a wire without touching the wire. He was elected as the Team Leader and the event was recorded on video. Upon watching the video he noticed that at the start the team was rather energetic and engaged in solving the problem, and so was he, so much so that at one point he figuratively put on the white hat (reference from construction; the foreman wares the white hat) and said Ok I know how to solve this, you do this and you do that…. In the video he noticed that as soon as he did that the energy level dropped; the team was no longer engaged and no longer cared about the outcome of the project.

Why did the team stop caring?

To reword and expand on David’s answer; No the team members are not just a bunch of lazy jerks but David as the Team Leader sent the message that he no longer cared about them so why should they care about him. As the Team Leader the relative success of the project sits on his shoulders. The team no longer cared if David got reprimanded for failing the project as David so clearly via his actions didn’t care about them.

What do you mean David didn’t care about his team, David is a nice guy!

I’m not arguing that and I’m not saying he meant to devalue his team; it was his actions that caused him to unknowingly send a message to his team that he doesn’t care about their opinions. By putting on the white hat and taking charge he removed the power from the team and sent the message that he doesn’t care about their mind, ideas or opinions, and only needs their brawn; I’m in charge and your just peons to action my greatness.

That is what David discovered by watching himself interact with the team on the retreats video. And that is what I’ve learned by watching David’s video (see link below) talking about what he learned by watching the retreats video, thanks David (see I think he’s a great guy too).

I was having dinner with a college of mine who I hadn’t seen in a while and he told me over a pint of an activity that his company does often when tasked with adding a new feature to their product. They sit in a room as a team and sketch it out on the white board running the design through validation cases to see if it holds water before committing to the approach. He is a junior developer and their organization is ruled by Subject Matter Experts (SME), their word is gospel and the junior people just do their biding. The team my college was on was mostly made up of junior level developers so the Team Manager invited a SME to sit in as a consultant.

In the meeting my college suggested an idea as to how to implement the feature; the idea sparked a vibrant discussion among the team which was getting everyone very involved and excited about the project. Part way through he said that the consulting SME chimed in saying that he couldn’t see anything wrong with the approach but that he didn’t feel like it was the right way to go. He went on to say that he was just a consultant so it was no skin off his noise (paraphrasing I’m sure) if they went ahead with the approach but that he wan’t really a fan of it and didn’t think it would work. Then he left the room to take a call.

My college said that it was like a fire just sucked all the oxygen out of the room; everyone got really quite and no further ideas were generated. Apparently the design ultimately came out of another meeting between the teams technical lead and some Subject Matter Experts and the actual team members (the junior developers including my college) just coded-by-numbers. My college said that that’s just how it is [everywhere] and that he’s just going to keep his head down until he gets promoted to a SME role.

I tried for the rest of the night to convince him that this was not normal (or rather shouldn’t be normal) and that there is a better way largely quoting David’s epiphany here about leadership.

The two major things that I saw that went so wrong (in my opinion) for my college are:

  1. The Team Manager called in a SME as a consultant. Don’t do that! It just undermined the value of the team off the get go. It sends a clear message to the team saying that you don’t value their abilities. Even if that is not the case its the message that will be sent, if your team really is lacking expertise then get a SME on the team, not as a consultant but a full member of the team who is going to collaborate and help the junior members grow.
  2. The SME didn’t try to coach the team to a better solution they just stood up with all their authoritative might and stated I’m right and your wrong. If they really felt that way they should have suggested another approach or indicated where the problem was with the suggested design and ask the team for help on how to solve it. They defiantly shouldn’t have left the room after making such a profound statement.

Looking back at David’s video he went on to say that a good leader shouldn’t lead with authority but rather keep the pace for the team; coaching them and encouraging them to do better.

The metaphor Pace, don’t lead David explains is about a trainer running along side the athlete. The trainer is not running ahead of the athlete telling them where to go but is instead running along side them. Why? Because the trainer wants to encourage them to do better, let them know they are not alone (that they are safe), and that their needs are being met. The trainer is not telling the athlete how fast to run, that is the athletes decision because they are the expert not the trainer. The athlete is the expert they know how to run they just need encouragement to better themselves and that is all the trainer should be doing. The same goes for software development; a good Team Leader shouldn’t be telling the other members of the team how to do their job but should instead motivate them and challenge them; again they are the experts your company wouldn’t have hired them and you wouldn’t have put them on your team otherwise.

So that is what I meant by Pace, don’t lead. Leadership isn’t about leading oddly enough its about motivating. Someone with good leadership skills isn’t the tip of the arrow leading from the front telling everyone else to just do what they do but rather is more like a general leading from behind. They tell their troops that they (the troops) are the best at what they do and don’t need him there holding their hand; they are the experts and that he’s confident they will achieve the objective. Lastly the general says that he is watching over them and will send help if things do get harry; I’m here to keep you safe.

Here is the link to the video assuming its still there, its about 3min and is worth a watch. Pace, Don’t Lead

Thank you, if you have a different view or have any comments or questions feel free to leave them below and I’ll try to answer them as time permits.

Until next time think imaginatively and design creatively


My interest in computer programming started back in high school and Software Development has remained a hobby of mine ever since. I graduated as a Computer Engineering Technologist and have been working as a Software Developer for many years. I believe that software is crafted; understanding that how it is done is as important as getting it done. I enjoy the aesthetics in crafting elegant solutions to complex problems and revel in the knowledge that my code is maintainable and thus, will have longevity. I hold the designation Certified Technician (C.Tech.) with the Ontario Association of Computer Engineering Technicians and Technologists (OACETT), have been certified as a Professional Scrum Master level 1 (PSM I) and as a Professional Scrum Developer level 1 (PSD I) by as well as designated as an Officially Certified Qt Developer by the Qt Company. For more on my story check out the about page here

Feel free to write a reply or comment.