Team of Teams: What an Agile Sales Team Looks Like

We started Heresy to help solve the problems we saw in sales: bad working environments, no collaboration, and low team morale.

Photo credit: Pedro Henrique Santos

In most sales teams, team dynamic is badly damaged. If you were to ask the public the words most associated with sales teams, the answers would be competitive, cut-throat, individualistic, and stressful. No one would say supportive, cohesive, and collaborative. Yet, if you want any team to work well and succeed, those are obviously the qualities you need.

In traditional sales teams, the goal is not common. Everyone has an individual target and are working like crazy to hit it. If towards the end of the month they are missing quota, their stress levels will skyrocket and they’ll try and hide their problems. If they are above quota, they’ll want to win, so they won’t share the secrets of their success.

Every month some people will win and some people will lose. But every month, the team will definitely lose. Problems won’t be solved; success won’t be shared.

The heretical part of Heresy is to get sales teams working as a team towards achieving one shared common goal. To do that, we want to build agile sales teams.

Small scales

Small teams fix these problems. Or rather, better team dynamics fix these problems, and you need small teams for better team dynamics. The ideal sales team size is 5–6 people.

There are three roles in these agile sales teams:

• The Team Member (AKA the Sales Person). The Team Members are the ones doing the work and closing deals. But instead of being individually focused reps, working towards their own goals, they are team members, focused on the team goal. They aren’t told what to do by the Scrum Master or Product Owner, but work as a team to prioritize their own dealflow.
• The Scrum Master (AKA the Sales Team Lead). The Scrum Master is really the heart of the operation. They are a player-coach, someone who already excels in sales and can use that experience and knowledge to lead their team. They are the person driving cadence each week and keeping the team motivated.
• The Product Owner (AKA the Sales Manager). In software development, the Product Owner is the key stakeholder, the person that cares most about the product. In agile sales, the Product Owner is also a key stakeholder, but what they care about is team performance. They coach Team Members on their sales techniques and fix any systemic, long-term problems that the team are facing.

These roles don’t perfectly parallel those in agile development. But the point isn’t a 1:1 representation. Instead, we want to take the best aspects of team focus and a common goal and adapt them to the sales environment. By keeping teams small and as cohesive units, everyone can work and learn together.

A team of teams

Scaling in agile sales doesn’t come within a team. It comes from adding teams. When we scaled the sales team at Stack Overflow, we added more people, but always kept the team size near to that ideal.

In 2012, our team looked like this:

Just four people. We didn’t even have a proper Product Owner. Instead, everyone on the team was involved in frontline sales, everyone had their own pipeline. But we did have a Scrum Master to keep the pipeline moving and morale high. One year later, we looked like this:

Instead of growing out a single team, we split into two. We also added a sales manager. Now they could concentrate on increasing the performance of each of the salespeople, leaving Scrum Masters to lead their own teams and keep cadence up.

A year later we were this:

At this level, we added a director to oversee sales strategy. The overall breakdown at each level starts to look like this:

• 5–6 people per team
• 1 Scrum Master per team
• 1 Product Owners per 2–3 teams
• 1 Director per 5–10 teams

In 2 years we 7X’ed our sales team. But you wouldn’t know it if you worked there. For the people on the ground, they worked with the same tight-knit group every day. At this point each person was just ~3% of the whole. If the structure was flat, they would be practically anonymous in the organization.

But they were 20% of their team — a big part. Everyone was still a part of Stack Overflow and everyone was invested in the success of Stack Overflow. But everyone was focused on their team’s success first.

This way of scaling has three major benefits:

1. No matter how much the overall sales organization scales, everyone is still a big part of their team. And each team is a big part of the sales success.
2. Now competition is no longer a solo endeavor, it is now a team game. At Stack Overflow, each team had their own name and culture. If you were a “Shoreditch Shore” you wanted to beat “The Wolves of Old Street” each month. The rivalry is still there, but the cut-throat competition dissolves.
3. Knowledge can flow from one team to another through the Product Owners. As they manage multiple teams, they’ll want success to propagate. What works with one team will quickly transition across the entire organization.

By building a sales organization as a team of teams, success travels from the individual to the team to the organization as all look to achieve that single common goal.

Small teams can still be dysfunctional

The team at Premiere Properties is an ideal agile size — four strong — but they are still failing.

Small, parallel teams aren’t unique to agile sales, and aren’t a guarantee of its success. A small team is a necessity to perform well, but it isn’t enough to build the cohesion, trust, and collaboration needed for success. For that, you need the other elements of agile that build around these small teams.

Strong internal leadership

Small agile teams essentially lack any top-down instruction. Each team acts as a self-organised entity, responsible for its own dealflow. Targets might be set organisation-wide, but how one team gets there could be entirely different from the next.

A lot rests with the Scrum Master. They are the linchpin of the agile sales process. But Scrum Masters get to that position exactly because they have the traits necessary to perform the job well. As proficient sales people, they already understand how to keep cadence high and what is needed to get the most out of a sales team. Even if they aren’t extroverted motivators, they will still motivate the team through the excellent work they are doing.

The right metrics

The problem at Premiere is that Mitch and Murray want to manage results instead of managing performance. They are setting a target and saying that unless the reps hit it, they’re fired. But the reps don’t perform well, so will never hit the target.

Agile manages performance instead of results, because performance defines results. Scrum Masters and Product Owners are looking for performance gains inside teams rather than being purely results orientated. For instance:

• Does a Team Member need help closing deals?
• Are cold email conversion rates across the board too low?
• Is the team moving too slowly to hit the goal for the week?

The team still cares about the overall result, but they view it through the lens of their performance and what they can improve on each week and month.

The right processes

All of this only works with the right processes to help the teams succeed:

• Sprints. Because teams are managing performance instead of results, they need to iterate quickly. Agile teams work in blocks of time called “sprints.” For monthly sales targets, each sprint will just be 5–8 business days. For quarterly targets each spprint will be around 20 days.
• Standups and Reviews. At the start and end of each sprint is a standup (start) and review (end). This allows the team to discuss what is in their dealflow for the upcoming sprint and decide a plan of attack as a team, then discuss the successes and failures of the sprint and what they need to do differently for the next sprint to get iteratively better. Both of these are run by the Scrum Master, showing again the importance of this role to the team.
• Monthly retrospectives. Every month, the teams will get together with the Product Owner to discuss how the sprints that month progressed and what needs to be improved.
• Burndown charts. Because agile teams need to work quickly in sprints, they need data quickly. A burndown chart keeps the team updated constantly on what they need to do, pretty much every hour, to hit their goal for the end of the current sprint. This way, there are no surprises waiting for the team at the end of the month.

Agile works fast. That is why small teams are suited so well for this approach. They can move fast, iterate fast, and support each other easily.

Small teams are supportive teams

A major benefit of this approach is support and morale — because everything is out in the open with the burndown and sprints are so quick, no one can get too far behind the pack. Problems are quickly identified and help is there for any team member from the Scrum Master or Product Owner.

With agile sales and its small teams “bad working environments, no collaboration, and low team morale” can disappear. Instead of sales teams being seen as the epitome of a selfish environment, they can become an example of teams working together, learning from each other, and all achieving a common goal.

========================================

For help keeping track of your sales metrics and workflow, head over to heresy.io and signup for your (free forever) account.

Originally published at blog.heresy.io on January 22, 2018.