To pool or not to pool? That is the question...

In my discussion with other SE leaders, one of the discussion topics that comes up most frequently is the struggle in balancing the size of the SE team with the number of opportunities and salespeople (AEs) it has to support.

In this article i'll outline the challenge with the current SE model for operating and what we might do instead with some real world gotchas from implementing it in the field.

The problem...

SE teams are often constrained by operating ‘ratios’ of X:1 (AE:SE) – with the average seeming to be between somewhere between 1:1 and 5:1 depending on the industry, vertical, technology sector etc. Whilst this sounds good on paper from an being easy to scale point of view’, it doesn’t often consider three simple truths.

·???????? Salespeople do not generate opportunities linearly.

·???????? SEs do not action work linearly.

·???????? All opportunities are not equal.

Opportunities or ‘work’ created by customer demand is far more dependent on buying cycles, budgets, customer urgency, critical failures etc, than it is to do with constant good prospecting (although obviously still important).

This gets even more difficult when you add in the second and third points – not only do SEs not all work at the same rate (differences in skills, experience, familiarity with the customer or product set etc.) but the size and complexities of opportunities differ considerably as well.

This means that unless you’re constantly moving AEs between SEs to cycle upcoming demand, which would be a major headache of logistics and forecasting, you’re going to run into situations where some SEs are slammed because of incoming workload and others are much more available.

The most common allocation of SE resources is that of direct alignment, where an SE is aligned to support one to several AEs on the customers in their respective patches. SEs are usually compensated for this in commission, or bonuses related to the deals they help work on in this patch.?

This approach causes several fundamental challenges.

Challenge one: if resources are ‘fixed’ through direct alignment to groups of AEs and we accept that workload is not generated linearly then we’re also accepting that some of those SEs are going to be busy and some are not.

Challenge two: if we had a system where SEs with lower levels of work at the moment could work on opportunities for other AEs not in their assigned patch, would they want to? Direct alignment and compensation actively dissuade SEs from wanting to work on things they won’t get compensated for and what happens when a conflict arises? What if the originally assigned AE now needs the help of the SE already working on someone else, because until then it had been quiet?

Challenge three: direct alignment can also end up unintentionally giving SEs a less broad range of skills which might not only limit their potential, but it could also limit the organisation’s ability to grow the team from within. In organisations where Sales and SEs are split by size of customer, typically this is done in terms of customer size, SMB, Midmarket and Enterprise (small, medium and large), then I’ve seen it time and again where the AEs focus on finding or growing customers where a small part of the portfolio particularly resonates or has a unique position in the market. For example, in an organisation I used to work for the SEs supporting AEs focused on SMB customers almost exclusively worked on a single product in a portfolio containing dozens. There was no opportunity for them to work on larger and more complex customers that might need a broader range of solutions, and even if there were, not only did they not have the experience to help win those deals, but we ran into challenge of incentivisation and conflict again.

If we look in the round at the overall issues that the direct alignment model causes, it’s no wonder it’s really hard to make sure that SE team sizes are relevant to the workload because the underlying assumption of how that workload scales is wrong. Not to mention the additional challenges with remuneration, incentives, skills and development.

So how do we solve this problem?

Let’s start by going back to first principles on what we actually need:

·???????? We need an SE team that’s scalable, but we need a more reliable method of scaling based on when the SEs are at maximum workload/output, rather than the size of the sales team.

·???????? We need to eliminate wasted ‘capacity’ by not aligning based on something we can’t control (frequency opportunity generation).

·???????? We need to compensate SEs for ALL the work they do, not just the work they do on a specific patch or vertical.

·???????? We need to provide the breadth of opportunity to the SEs to grow and develop across the full breadth of customers and the full breadth of the organisation’s technology portfolio.

?

Now we understand what we need to know and do in order to have a scalable SE team, how do you go about actually designing a method that achieves it?

?

What follows is the method that I’ve used in a few different organisations now to provide that visibility of SE workload in order to right size the team but also help build and develop extremely high-performance teams full of high calibre experts who love working collaboratively.

The pooling and hybrid pooling method

?

Scaling based on workload – the first thing needed is to establish what a baseline for workload is – when do we decide when people are ‘full’? If you look at a standard 40-hour week and work backwards, I always want my SEs doing the following:

·???????? Learning time – 20% of their week – 8 hours.

This is the single most important thing any SE can do – technology changes so quickly, as do customer buying habits that unless you’re learning you’re actually going backwards. Add to this learning from colleagues – Solution Engineering is a team sport. No-one knows everything and every SE has slightly different knowledge from the SE next to them. Sharing, pooling and distributing this knowledge is THE key difference between a good SE org and a great one.

·???????? Thinking time – 10% of their week – 4 hours.

Being an SE is hard – there are a thousand variables from customers, from technology vendors, technology that’s deployed etc. It’s critical to have time to just think, mull a problem over, whiteboard something out – and do that whilst walking the dog, or doing the washing, or driving to pick the kids up from school. Time to just think leads some incredible solutions to some really challenging problems.

·???????? Customer time – 70% of their week – 28 hours.

This is the bit we care about understanding. The only people who can tell you how long something might take is the SE doing the work. You can’t shoehorn in project sizes, standard lengths of deliverables or anything else along those lines. The SE needs to learn, through doing, how long something takes them and make sure that data is recorded somewhere central, accessible and sharable.

Once we’ve established our ground rules for how much time an SE should spend on customer work, and we’re reliably getting our SEs to allocate times to their workloads, we now have a much better understanding of how busy the team is. If there are 280 hours available across the team for customer work (value N), and we’re consistently seeing through trend analysis that we’re using 250 hours (N roughly minus 1) – it’s probably time to start hiring. Finding great talent, onboarding them and getting them up to speed can take way longer than you think – it’s better to go early than late, though flex this as your business needs – any extra time you’ve added to the available workload pool is time to build better demos, to collaborate about sales plays, more time for training – whatever it is, it’s not wasted time.

?

Eliminate hotspots – The next item to solve is to eliminate the hotspots across the alignments and the best way I’ve found to do this is to remove the alignments entirely. This sounds counterintuitive to the way that Solution Engineering has traditionally been done it’ll make sense, bear with me.

The concept of direct alignment is a good one and makes sense – we want to build relationships with both AEs and customers, but the most important one of those is the customer. Even then, does every customer need a specific relationship with an SE? Most customers in the small to mid-market spaces are looking to solve a specific challenge: a problem in their business that needs a resolution. This is more of a transactional type of engagement – the same is if you were buying a car or a house – it’s a major purchase, you want due diligence, you want to kick the tyres on every facet of the solution, you want the same person to talk to throughout the whole process etc. But once you’ve been through all the steps and you have the car or you’ve moved in, that’s it. Until at least the next time you need a car or to move house.[MOU1]? SMB and Mid-Market engagements need SE support, they can be incredibly in-depth and complicated but what they don’t often need is an ongoing relationship after the project has ended, that’s what an AE is for, to manage the account.

If we’re not going to directly align workload, how else do we get work to our SEs? We pool it.

Every time an AE has an opportunity (and they’ve done some suspect/prospect work), they ask for an SE. I’ve seen lots of different ways of this working but the best ways are quick and automated – a simple request function in the company CRM that the AE can raise from within the customer window and fill in some brief details about (who, why, when) – and then a SE ‘kanban’ style view, in the same CRM, where we can see all the work coming in and the individual workloads of each SE.

This has four distinct advantages over direct alignment (possibly five depending on how your SE team is setup):

1)????? SEs can self-regulate their workloads. SEs will know how long an opportunity might take, they know the timescales of the customers and they know what other work they’ve currently got on – they can then decide to pick up work if they’ve got spare capacity to do so, or not if they don’t. This evenly spreads work across the entire team, eliminating the boom bust of the alignment method.

?2)????? SEs can work on a range of customer challenges, not limited by vertical, or technology, or size – but instead pick work that challenges them and interests them. Over time this means that SEs get exposed to a much broader range of possible permutations on building customer solutions making for much more experienced and well-rounded SEs.

?3)????? SEs get exposed to a much broader range of salespeople. In my experience as an SE every salesperson was different. Some were awesome at one set of activities and others they needed help or training on and vice versa. By pooling resources, the SE community gets a fast track on understanding what works well when collaborating, what doesn’t, and what learning and enablement feedback needs to be made to Sales to help them grow and get better.

?4)????? Pooling brings a degree of support, cooperation and development that you don’t get with direct alignments. SEs that can see each other’s workloads, customers, and that have the financial blockers removed are much more inclined to want to help each other. SEs are curious by nature, they want to learn, to see new ways to solve challenges and apply solutions in innovative ways. You get seniors leaning into projects with juniors to lend some wisdom and juniors surprise seniors with a solution they’d never encountered before. This not only helps make them better at their jobs faster and drives customers satisfaction, but it helps develop really strong camaraderie and performance within your SE community.

?

5)????? If your business runs a ‘majors’ program or some variation on that theme, where one or several SEs specialise at a particular technology area then pooling allows them to really focus on developing that specialist knowledge – there’s little point in being a major in technology (x) when in direct alignment most of the customers instead use technology (y).

?

Pooling is not a panacea; it does have its own challenges but for the most part, across most customers and most opportunities it does provide much more benefit than costs.

There are two commonly brought up downsides with this model:

·???????? What happens when SEs start to cherry pick or avoid particularly difficult requests from specific salespeople? This can be a problem for sure, but it is solvable. To start with, you hired awesome people – SEs are thoughtful and considerate for the most part as it goes with the job – explain what you’re doing and why you’re doing it and remind them of where they’ve come from. Furthermore, in a pooled model with a good CRM that shows work in a ‘kanban’ style format – it’s very easy to see and analyse the variation in an SEs workloads. You can incentivise them as part of their objectives and measure to take opportunities across a broad range of subjects (where possible!) and use that as part of their performance and development every quarter.

?

·???????? Salespeople invariably don’t like this model. In every organisation I’ve launched it in, the loudest objections are from the AEs that suddenly lost their ‘person’ the one they leant on for any and all things technical. Getting support of Sales leadership is critical here. There are upsides for sales – firstly, they get well rested SEs that aren’t in danger of burnout, secondly, over a period of time they get more well-rounded and experienced SEs that can help win them more complex (and more lucrative) deals, and lastly, for those AEs who run their SEs ragged and were constantly waiting to add on another opportunity, they’ve now got a pool of resources to draw upon, the individual is no longer the bottleneck.

?

There are also financial benefits to the organisation, the business knows exactly the right size of the organisation and additional headcount is now based on demand rather than expectation which often saves the business money.?????

Hybrid pooling - now that we’ve taken care of most of the workload, what do we do with the Enterprise customers, the ones that really do need a SE relationship alongside their AE? In this scenario there really isn’t any substitute for direct alignments, however with one caveat, we align now at the customer level – not with the AE.

The customer is the most important part of the equation, they’re the one either we, or they, (hopefully both!) see value in a technical alongside a commercial relationship. That has little to do with the AEs other accounts beyond the one in question.

Alignment at the customer level means both that the SE has a direct hand (and incentive!) in forecasting because they need to know what their upcoming workload looks like and that it’s much easier to align particular skills or experiences to the right customer. For example, you’ve got an SE with experience in the banking industry and there’s a particularly tricky client, or one with tons of potential, and we want to ensure our most experienced SE can deliver. We can do that.

Alignments this way should be treated as semi-permanent, you don’t change them unless you have to.

SEs aligned in this way can also use some of their ‘less busy’ periods to do what we want senior SEs doing – teaching the juniors, talking to product management and helping enhance features, speaking at events, promoting the business externally and any number of other things.

?

?

Compensation – In direct alignment models, SEs tend to only get paid on the accounts that their AEs are aligned to – and anything outside of this requires raising the dreaded ‘exception’ with the compensation team, finance and any other number of places.

Having fixed data linkages like this is horribly frustrating for both those at the sticky end, the SEs, and the teams having to implement it.

A much easier and simpler way to recognise SEs on what they work on is have themselves ‘align’ or ‘tag’ themselves on an opportunity-by-opportunity basis. In each case I’ve come across the work required on the CRM system and by finance is usually at a minimum, but the flexibility achieved is game changing. There are obviously some checks and balances required here to ensure that one rogue individual doesn’t end up tagging themselves on everything and anything but some simple spot checks: documentation created, frequent recorded contact with the customers, detailed briefs and weekly deal reviews, as well as hiring great people knocks 99% of these issues on their head.

However, there is still one challenge here – if we still compensate individuals on their individual work when they’re pulling from the pool of work – how do we stop people aligning themselves to the most lucrative opportunities?

Well, the old adage is that compensation drives behaviour and the behaviour we want is one of collaboration and teamwork – so keep the compensation mix the same at 70/30 or 80/20 (basic/variable) depending on the organisation, and the value the same (depending on level of the SE) but we pay out against the target set against the overall number of the teams the SEs support. i.e. we move to a pooled compensation model too – we win together, and we die together.

For the SEs this has two positive effects – it removes the ‘what’s in it for me?’ question – as they’re all now profiting if we’re helping hit the overall number and it removes some of the monthly/quarterly fluctuations that can occur when, or if they’re aligned to a ‘good’ or ‘bad’ patch. The one downside with this approach is with the overachieving of individual targets, and therefore compensation for those aligned to a ‘good’ patch. It is much more difficult for the team to together overachieve than it is for individuals to do so.

In all the time I’ve been discussing this method, I can think of only one SE who was truly unhappy about moving to a shared compensation model and that was because they were aligned to a patch that regularly delivered 150% of their number. Ultimately, we dealt with it a different way, but I think that was more an issue with patches and targets than the system overall.

?

?

Development – In discussing this model of pooling and hybrid pooling (some customer-based alignment, the rest pooled) – one the absolutely key benefits to the organisation is in the development of the SE team.

Anytime you subdivide the SE team by size of customer, vertical or anything else, you’re limiting their ability to grow from experiences outside of those subdivisions. There’s definitely an upside to having people experienced with the nuances of particular customer segments: finance, healthcare etc, but in my experience this is better shared at a team level – for example one person works on a challenging project in healthcare, they document and share the specifics on the deal and that experience has now been gained by everyone. Though this doesn’t exclude the possibility of using a ‘majors’ program (overlay specialisms) if really specific or niche knowledge is required.

Over a period of time the sheer variability of vertical, technology requirement, customer challenge and nuance and size of opportunity has the potential to create an extremely strong Solution Engineering team which self-reinforces through bilateral teaching and grows with every new project delivered for the customer.

Furthermore, something else that comes up time and again in a direct only model is that of cover. What happens when one of your SEs is away on leave? Either you’re adding workload to those that might already be busy, or you’re potentially having SEs without a requisite skillset fill in, or you might run into compensation challenges – what happens if the covering SE starts a big deal and does the bulk of the work before the original SE gets back. Who gets paid? All these challenges are mitigated by pooling – with a similarly skilled and experienced team with a known capacity of slack in the system, the cover can be handled customer by customer, rather than by a whole AE at once and load balanced to ensure that no-one gets burnt out and people get the

Lastly, as I discuss in one of my other articles on ‘Measuring Solution Engineers’ – being able to tweak, tailor and develop your SEs on an individual basis through SMART objectives is fundamental to helping them grow. Pooling and being able to have almost every project visible to an SE means you can tailor their growth as the SE required. Have an SE missing a critical piece of the technology portfolio? Set an objective for the next quarter to have them focus on deals where they’re likely to position or discuss it. Have an SE that really wants to specialise in a particular facet of the portfolio (datacenter/security, AI etc)? Great – set objectives around working in that space.

?

Conclusion

As I stated earlier, pooling is not a panacea but, considering the original question for this article – balancing the size of the SE team relative to the workload – it is a much more dynamic and flexible way of working that brings a ton of benefits beyond just having the right size team.

Most organisations with an SE department that I’ve spoken to are always challenged by three things – size of their incoming pipeline of work, the business not truly seeing the value being provided because it’s always mixed in with AEs and developing high performance teams. Fundamentally this happens for two reasons – one the most commonly used model is not fit for purpose anymore and secondly, the data and tools to do something different and demonstrate success haven’t been there.

Now with great customisable CRM tools that are widely available to most organisations, and therefore the ability to capture and see the right data and information now is the right time to revisit the model of SE operations and ensure that it’s fit for work in the 21st century.

Pooling your SE resources and customer needs gives the ability to truly right size the SE team based on their actual workload, rather than based on an arbitrary ratio that doesn’t take any account of the wild variability of customers, people and opportunities. Combining this right sized team with the ability to see workload in real time: develop the team in a flexible, collaborative, and scalable manner, eliminate hotspots of knowledge and workload, simplify pay structures and massively increase the performance and collaboration of your most valuable assets, the SEs – it’s easy to see why organisations are willing to challenge the status quo and explore another method of getting the most from their SEs.

?