Imagine a Customer Support team with high turnover and low tenure across the board.
Your customers will only speak to people who haven’t had time or mentorship to become experts. They’ll receive continuous poor service, become frustrated and despite your great product, churn.
Then consider employee morale in an environment void of solid team foundations or successful role models. Unhappy teammates are less productive and the circle of a poor customer experience continues. Why do many support teams fall victim to this cycle? They fail to provide a promising career path to those that join.
Support at Intercom isn’t a career stop gap. It can be a stepping stone to other departments/roles, but we’ve built a team where a long and successful career can be fostered within Support. Many teams provide limited progression (agent → supervisor → ceiling) and experience high turnover, which leads to poor support. Who wants to continuously lose their best people to other teams?! Here’s what we’ve done at Intercom to ensure Support is a team where people can grow, develop and be really proud of their work.
1. Create a plan for employee growth and development
During their first few months, we expect all Support teammates to become product experts and customer conversation ninjas, focusing on little else. Once a teammate is nailing the day job, we gradually involve them in other tasks. Some teammates are involved in both internal and external event management for Intercom. Others build internal tools for front-line teams. They write blog posts, create educational content, and mentor and onboard other Intercomrades. This gives them a taste of people management, a voice in the direction of the team and helps them understand how and why we hire who we do.
As small global team of five at the beginning of 2015, everyone did a bit of everything. But as we grew to 50 team members in 2016 (across PST, GMT and APAC time zones) things became disorganized. There were too many cooks in the kitchen for some tasks. Others would stagnate with little to no attention. So we launched a project to define and assign Areas of Responsibility (AoR), which gives teammates autonomy, ownership and full control of their AoR.
Frontline support isn’t something to be escaped from; helping others solve hard problems is a valuable skill, and it’s fun! Ultimately, we try to find the balance between helping teammates expand their skills while maintaining focus on our customers.
2. Define Success and Progression Paths
Developing teammates’ skill sets is all well and good, but you need to provide roles to put them to use. When our team was very small, it was made up of Support Representatives, Support Engineers and Support Leads. As we got bigger, and teammates became more tenured and skilled, we had to start defining career paths while allowing people to shape their own progression.
Ensure people management is not the only progression path.
We’ve moved people to Lead positions, which is primarily people management and team leadership. But one of the most important things to consider when developing people is to ensure that people management is not the only progression path. So many support departments promote good reps and engineers to management as there’s nowhere else to go. Having amazing CSAT doesn’t mean you’ll be a good people manager. Likewise, you may not be the most technical person but you could be a fantastic leader.
We were careful not to create roles for the sake of holding on to teammates, but we also saw gaps in what we needed and filled new positions with the right people. Early on we experimented with a Senior Support Representative role, which was customer-facing but heavy on process implementation. It simply pulled these folks in two very demanding directions, so instead we built a focused Operations team. We transitioned some team members there and reconsidered what a Senior Support Representative or Senior Support Engineer really should be.
The key to our new structure is focus:
Our new Operations team builds tools and processes.
Senior Support Representatives are masters of our inbox. They mentor our new hires, act as escalation points and hold down the fort as steady rocks in busy times.
Senior Support Engineers maintain their Support-related tech skills while working on more complex escalations and mentoring junior team members. This role is great for people who love leadership and not people management.
In promoting people to such positions, we learned you need to be able to explain why that person was selected and how more junior people can get to that point (should that be the path they wish to follow). This meant defining what success looks like in each support role.
Thanks to one of our Operations Engineers, we created competency matrices for each Support position so teammates can see where they stand and what they need to work on. The important thing to remember here is that although some key metrics are crucial to the success of a support team, success in a specific role is not all about numbers. Our competency matrices list attributes that are difficult to measure in numbers, such as leadership and product knowledge. We substituted numbers here with descriptions as close to the desired behavior as possible.
3. Bridge the Product-Support Gap with Embedded Roles
Initially, part of my role as Lead was to regularly sync with product teams on bugs, issues and their roadmap. We tried to bridge the gap between Support and the product teams to keep our frontline teams informed; however, the effectiveness of meetings began to wane as a Lead’s general knowledge of our product kept the conversations quite lightweight.
At the same time, other Support teammates were deeply knowledgeable in specific product areas and were starting to consider how they might move to one of our product teams. Our solution to both: embed these support teammates in product teams. We found a solution to ineffective product syncs and a role beyond what we previously offered: Embed these support teammates in product teams.
Nobody knows your product the way your Support team does.
Nobody knows your product the way your Support team does. Ensuring that these product experts are spread across the company maintains that culture and keeps the product focus on customers. We created our first Product Support Engineer role in May 2016. Penny started in the company as a non-technical Support Representative, but tirelessly taught herself expertise in their product area. We’ve learned that when we’ve empowered people to shape their own progress, they’ve achieved things we’d never have conceived.
We’ve since transitioned two more Customer Support Engineers to their new Product Support Engineer roles. We’ll gradually move more tenured Support teammates to “embedded” roles, and possibly hire more with a view to embedding them earlier. The most important point is that we maintain a customer voice across Product, so we don’t forget who we’re building for.
Despite the desire to hold on to the best people, you can’t be dogmatic about all of this. Sometimes there isn’t a role in Support that makes sense. Some of our people moved to Sales (and recently a Sales teammate moved over to us). Others became product engineers. As much as it hurts to say goodbye, you can’t hold someone back if it’s best for them to move on. Part of a manager’s job is to help make happen what’s best for the individual.
The important thing is to provide options and if those don’t suit, empower your team to take the next step, even if it is away from support. But if you can offer new hires growth opportunities, a clear progression path and a close relationship with other teams, the number of excellent teammates you hold onto will be maximized.
If this sounds like something you’d like to be part of, we’re hiring support engineers to join our Dublin team.
Comments