High-performance teams (HPTs) is a concept of organization development referring to teams that are highly focused on their goals and that achieve superior business results. I have been intrigued by the HPTs concept since I started leading teams, and I have read a number of blog posts about this topic. However, the vast majority of the publications only talk about this topic in a theoretical way, with no practical steps a leader can take to transform their team into an HPT. The engineer in me tends to look for “formulas” or “hacks” in everything that I do (building teams, building products, etc), and the lack of any on this topic has been the source of great frustration. After much researching, I finally found a “formula” that resonates with me. In this post, I will share the “formula” and how I intend to use it to accelerate my team’s growth into an HPT.
I am an avid reader of the Tech Manager Weekly publication. A fresh, curated list of engineering, culture, process and leadership articles by CTO Craft, delivered every Monday to my email inbox. I don’t religiously read the publication every Monday. As a matter of fact, I’m behind on a lot my reading. One Friday afternoon, as I was catching up on my reading, I stumbled upon this article by Simon Powers. In the article, Simon describes the following formula:
Performance = Team Potential — Outside Interference.
Upon retrospection, this formula deeply resonated with me. As I replayed the instances during which my engineering team either delivered excellent results or fell short on a goal, I could trace it back to one of the two variables of the above formula. For example, when one of my teams missed a targeted delivery date for a release, it was often due to poor estimation (i.e. low team potential) and/or external blockers (dependencies from other teams) they experienced along the way (i.e. high outside interference).
At this point, the engineer in me kicked in again so let’s do the math. If X = Y — Z, how can I maximize the value of Y, minimize the value of Z, in order to achieve a greater X value? What are the factors within my organization that have historically influenced team potential? What about outside interference? In the following sections, I will attempt to unpack each variable of the formula within the context of my engineering team and organization.
Potential is the latent qualities or abilities that may be developed and lead to future success or usefulness. The people and interactions on the inside of the team make up the team potential. Here are some of the factors that I have observed which positively impact my team’s abilities:
A strong purpose fuels the passion of the team members and gets them excited to get out of bed every morning. As a leader, I need to develop, articulate, over-communicate a purpose to my team, and how our work impacts the business. This is not always easy and requires deliberate effort. But it is required to ignite that team fire, enthusiasm, passion, and keep the flame alive.
Does the team have the needed set of skills to get the job done? A modern agile team would typically need software development, product management, and design skills. If certain specialties are required to solve the business problem at hand, it is imperative I make those skills available to the team. Either by hiring a specialist or leveling up members of the team.
A team with high psychological safety can take risks without the fear of negative consequences. The team members can admit to errors and mistakes without fear of retaliation or criticism. A team should learn from past mistakes instead of hiding them. The moment I sense that my team is not speaking up and asking the difficult questions during team meetings and retrospectives, it’s a red flag.
Velocity, Direction, Acceleration, Position (VDAP)
In Physics, the velocity, direction, acceleration, and position are attributes used to describe the motion of an object. My previous manager, Scott Carleton, had a hypothesis that the same attributes can be applied to a team in motion towards achieving a goal.
The velocity of the team describes how fast it is moving towards its goal. We measure velocity as the number of story points delivered each iteration.
The acceleration describes how well the team learns from past mistakes in order to increase future velocity. Regular retrospectives are a valuable tool we use to learn from our mistakes. But it has been difficult to measure the acceleration that is generated as a result of them.
The direction describes where the team is headed in contrast to where they should be heading.
The position describes where the team stands today, how far behind or ahead they are. We use daily standups to quickly assess our current position.
I have found that when my team has a solid internal process that surfaces their VDAP, it enables the team to move fast, increases autonomy, and develops ownership to take steps to course-correct when the need arises.
Interactions and interference from outside of the team can impede on a team’s ability to deliver on its goals.
Changing goal posts
A moving target is considerably more difficult to hit than a static one. Changing a team’s goal halfway through the course can kill momentum, have an impact on morale, and requires a boost to propel the team onto the new course. In the past, the lack of a long-term vision caused me to change the goals of my team quite frequently. This led to great frustration within the team and ultimately decreased performance.
Changes in leadership can bring a lot of anxiety within a team. The anxiety often stems from the uncertainty of what changes will be put in place by the new leader of the team, department, or function. The new leader often needs to go through a round of trust-building exercise with every team member, while important and necessary, often slows the team’s delivery.
Similar to leadership changes, changes in organizational structure can have a direct or indirect impact on a team. Mergers and/or splits between departments directly impact the teams under them. Re-alignment needs to occur, new goals have to be set, and current goals may change. The departments not directly involved in the organizational change may have to revisit how they collaborate with the ones that are. Amidst all the changes, individual team performance is affected.
Engineers hate being micromanaged, plain and simple. Anytime I tried to micromanage, or get too deep into the weeds, it resulted in frustrations and ultimately the team slowed down. Give the team a clear problem to solve, a clear direction, and get out of their way.
In any engineering group comprised of multiple teams working on the same codebase or product, no one team can operate fully in a silo. The reality is, a team often has to collaborate with other teams in order to get their own work done. In this scenario, it is very common for the teams to step on each other’s toes which impacts overall delivery. An engineer can be blocked waiting for a pull request from another team. A team can deploy code that introduces a bug in a part of the application which is owned by a different team. An engineer can be blocked waiting for a code review from another team. These are some instances of common inter-team interference that I have observed occur. Proper process and guidelines can help alleviate such inter-team frictions.
Now that I have identified the factors that can influence team potential and outside interference in the context of my organization, my next step is to identify which factors I can control. For example, I do not have much control over organizational changes. But I can control the skill sets I look for when hiring engineers. Once I have identified all the factors I can lever, I can create quarterly goals geared towards improving said factors, and ultimately propel my engineering team to higher performance over time.