Systems break down in many ways large and small. In the fit systems enterprise, teams and leaders watch out for archetypes. These are patterns of dysfunction that can easily crop up inside any of your operating systems or meta systems.
It’s helpful to differentiate between meta archetypes and garden variety archetypes.
The Meta Archetypes
There are three meta archetypes that can afflict the enterprise:
- No value breakthrough
- Close, but no cigar
- Value breakthrough, then decline
No Value Breakthrough
In the “No Value Breakthrough” archetype, the company never gets past the first generative imperative.
The concept was interesting enough to attract an early investment, but now the company can’t find product / market fit. They can’t translate cash into customer connectedness. The product disappoints. Prospects don’t buy. This is a failure of the product development system. This archetype is common with early stage startups, but also with the investments large enterprises make in innovation experiments.
This can be expressed as a balancing feedback loop that instigates a negative reinforcing feedback loop, as follows:
The lack of traction creates a negative feedback loop back to the investor, who concludes that her stock of investable cash can be better deployed elsewhere. Starved for money, the company cuts back on its capacity to find a value breakthrough. People are let go (decline in the staffing stock). The best-performing survivors leave (decline in the competency stock). Morale plummets (decline in the motivation stock). Eventually, the business slides into bankruptcy.
The Way Out
The only way out of this archetype is to achieve a value breakthrough. Banish denial: face the truth that your first (or second or fifth) product iteration is dead. Spend more time in the market, talk to more prospective buyers, learn more about the problems / needs / obsessions / opportunities. Then test faster — with lighter, easier-to-create prototypes. Iterate until you find market truth, or until the money runs out.
Close But No Cigar
Here, you think you have a value breakthrough. You can sell your product to customers. But as time goes on, you learn that you can’t keep them.
Perhaps the value proposition of your key feature is solid, but you have persistent integration issues with customers’ legacy technology. The customer is forced into workarounds to take advantage of your feature. Because these integration issues are hard to resolve, your development efforts focus elsewhere. Investors are fooled for a couple of funding rounds. Customer acquisition seems solid. You are fooled too, so you invest aggressively in marketing and sales. You hurry to scale. As churn rises, you try to solve revenue shortfalls by selling faster. The more cash that flows into the revenue engine, the more sales you make — but the more churn you experience a few months down the road.
You pour what product and engineering resources you have into building new features that extend your existing product, without addressing the integration problem at the core. You have shifted to the product management system, before the product discovery system has done its job. Nothing you develop in the product management system can be fully appreciated by your customer, because the nefarious integration issue is too big of a value blocker.
Eventually, you cap out — each month losing as many customers as you sell. The cash you have spent on trying to spike sales and create new product features could have been used to solve the integration issue. Now, absent an investor story, cash becomes tight. Investors give up and force you to cash out, taking the best bad exit deal you can find.
The Way Out
Never sell your way out of a product problem. Listen to your data. Look at your Net Promoter Score number for customers 4 months live — and make sure it’s at least 40. Don’t scale until you are sure you have sufficient product / market fit.
Value Breakthrough Then Decline
This archetype is often at play in companies that have already scaled up. They initially rode the wave of a hot product, with a big value breakthrough followed by years of continuous value optimizations. As the company grew in revenue, it also grew in size and complexity. With revenues scaling steadily, your investors encouraged you to shift to the adaptive imperative. Breakthroughs in scaling and efficiency drove further growth in company profit. Investors seeking continuous returns loved your combination of steady revenue growth and increasing cost efficiency.
But then the market shifted. Your company didn’t notice. Caught up in internal optimizations, you lost touch with your customer.
New competitors introduce simplified feature sets and lower prices — creating the innovator’s dilemma. You don’t want to match on price, because you’ll decrease your own revenue. You try to add more features so as to hold the price. But because your feature additions aren’t tied to your customers’ real emerging needs, more and more customers see you as overbuilt and overpriced. Your product management system begins to sputter.
As revenues flatten, you work harder to extract cost savings. As a result, less money is available for new product innovation. A negative reinforcing feedback loop kicks in. Customers begin to flee, good employees leave, revenue declines and inevitably profit begins to slide.
The Way Out
Keep the product discovery system and product management system active. Continuously invest in new product innovation, especially during times when your existing product is winning big in the marketplace. Bring “startup thinking” to new investments and projects. Create entrepreneurial rewards for leaders who create success. Protect the startups you’ve spawned from the mother ship’s smothering behaviors.
The Garden Variety Archetypes
The roster of garden variety of archetypes is a tool all employees can use to aid in diagnosis of systems and domains. If you sense an archetype is at play, take it seriously and test the hypothesis.
Here are the garden variety archetypes:
- Limits to Growth
- Accidental Adversaries
- Symptomatic fixes that backfire
- Policy resistance
- The tragedy of the commons
- Declining goals, declining performance
- Success to the successful
- Leadership as enablement
- Rule beating
- Seeking the wrong goal
These system traps arise inside companies when individual actors pursue “small purposes” that work against the “enterprise system purpose”. Let’s explore each of these archetypes:
Limits to Growth
In the early growth of your company, your engineering team’s rate of output was high. Everything was new. The team collaborated well and engineers acted as generalists to get done whatever needed to be done. You built a great product, which led to success. With success came more funding. With more funding, you built a larger engineering team. This increased your development capacity, enabling you to expand your product feature set. As a result, your product platform became more comprehensive, supporting more and more customers. This created more funding and an even larger engineering team.
But in the past year, productivity has declined significantly — especially with regards to new product development. Now, work must go through a formal prioritization process. Engineers are specialized. Directors of engineering manage teams of engineers. With multiple projects going on simultaneously, it has become much harder to coordinate work so that every engineer is fully utilized. And with thousands of customers, the flow of bug fix requests consumes more and more of your engineering resources. So the resources available to build new features and products are increasingly scarce. New product development has slowed to a crawl.
This is an example of the limits to growth archetype. Success creates new success — a reinforcing feedback loop — until some limit (in this case, resource coordination constraints and bug fix demands) causes a balancing feedback loop to emerge.
At the system level, the limit to growth archetype might look like this:
At the productivity per input unit level, it might look like this:
The Way Out
To solve for this system trap, the mental model shift is to stop focusing on the reinforcing loop (the rate of output). Focus instead on the balancing loop — on the factor that is limiting the growth. If you can release the limiting factor, the output will start growing again. In the example above, you might create a separate product and engineering team dedicated solely to new product development. Or you might invest in coordination resources, so as to increase engineering utilization. Create smaller, cross-functional work groups and empower them to make decisions (as Spotify did — see Chapter 2). If you break work down so that small teams can be self-organizing, they will look and act more like the product and engineering team you had when the company was brand new.
In this trap, partners who should be collaborating together act as if they are adversaries. One partner acts in self-interest in such a way that the other partner is harmed, causing that partner to react in a way that harms the first. This can happen between departments, such as marketing and sales, or product and engineering. It often pops up in channel partnerships, and between headquarters and the field.
The pattern looks like this:
At first, Partners A and B work in close coordination. A’s success advance’s B, and B’s success advances A. All goes well for a time. But then, A implements a fix that unintentionally harms B. B doesn’t recognize the source of the problem immediately. It reacts to the problem by implementing a fix of its own. This fix results in a negative impact to A. Both A and B fall into a self-destructive cycle, with each partner optimizing for its own benefit at the expense of the other partner. Soon, each partner begins to distrust the motivations of the other.
The following feedback loops show the evolution of this archetype over time. The following diagram¹ doesn’t conveys the point in three stages:
In the above diagram the stocks are boxed in black, the relevant flows are boxed in blue and the feedback loops are green. The bold “R’s” and “B’s” designate the reinforcing and balancing feedback loops.
This was the archetype at play in the story about a newspaper that I shared in the Introduction. The Sales department in that newspaper flaunted ad deadlines because it made it easier on their customers — advertisers. But the result was to send a late-week tsunami of ads into Production, which lacked the staff to handle the spike without excessive overtime and stress. This caused Production to move back the ad deadline. Sales responded by increasing the percentage of late ads, ignoring the new deadline. In the rush to produce the mountain of ads, production workers became sloppy, causing the ad error rate to spike. Low ad quality reduced advertiser confidence, leading to lower ad sales. Because of lower ad sales, sales people made less money. Sales and Production were caught in an accidental adversaries archetype.
The Way Out
To break the pattern, the partners must shift their mental models. This starts by widening circles of interest to encompass the whole system, not just each partner’s part of the system. When problems arise, partners need to come together to discuss what happened. Begin with first principles. Do the shared goals of the partnership remain valid? Do they advance the purpose of the overall enterprise? If so, what local incentives prompted fixes that ultimately hurt the partner? Do these incentives need to be changed? Accidental effects of local fixes are likely to happen again. No partnership design can predict everything. Make sure feedback loops are in place to detect adversarial impacts quickly. Put collaboration mechanisms in place to surface problems and mutually resolve them.
Symptomatic Fixes that Backfire
Perhaps you have fallen short of your revenue target. The product’s level of value delivery falls short of “gotta have it” customer conviction. To solve the problem, you increase incentives for sales reps for any contract closed this quarter. Sales reps work hard to pull deals in from the subsequent quarter, to maximize their extra incentive payout. Promises of product value are made that can’t be delivered. By the skin of your teeth, Sales makes the quarter. In the subsequent quarter, however, you face a bigger problem — not only is your pipeline starved of bottom funnel deals, the absence of last quarter’s incentive has reduced the sales team’s sense of urgency. So you decide to repeat the incentive. But it doesn’t work as well as the first time; you fall short of the quarter’s goal. Then, a couple more quarters down the road, you begin to face early, unexpected churn from dissatisfied customers. So you increase sales incentives more, hoping to compensate for the lost revenue.
Or perhaps your engineering team is experiencing excessive attrition. Your best people are walking out the door. This has caused a decline in engineering output. You become concerned about the backlog of critical projects, and the downstream effects of the brain drain. So you implement a “stay bonus”. But then you notice that engineering productivity has continued to decline. Noticing checked out employees, your VP Engineering begins to micromanage the daily output of each engineer. Morale falls further. Now it seems like most of the engineers on the team have quit and stayed. Throughout the team, engineers fidget as the end date of their stay bonuses approach.
These are two examples of symptomatic fixes that backfire. The pattern looks like this:
At first, the fix seems to work. The problem declines in severity. But soon it creeps back, worse than ever. Next thing you know, you are engaging in ‘whack-a-mole management’ as you try one symptomatic fix after another.
The symptomatic fix acts as a balancing feedback loop. You intervene in the flow (a new incentive, or a stay bonus) so as to improve the stock (revenue performance, or engineering output). But there is a separate, hidden reinforcing loop that creates a vicious cycle.² Because the symptomatic fix did not address the root problem, a delayed counteracting feedback loop (unintended consequences that exacerbate the root problem) overwhelms your symptomatic fix, causing performance to worsen.
Symptomatic fixes emerge from flawed mental models. Your understanding of the system may be overly simplistic: ‘there’s the problem, go fix it.’ Or your timeframe of concern may be too short: ‘just fix it now; we’ll deal with the consequences later.’ Or your personal interest is out of alignment with the enterprise’s purpose: ‘I’m responsible for this number — if I don’t fix it now I’ll lose my job.’ Or the consequences of problem discovery are so great, it’s better to hide the problem: ‘get rid of this by any means necessary.’ Or the problem is an inconvenience that encroaches on what ‘really matters’; ‘let’s just do something to make it go away for now.’ The common denominator is an expediency mindset. You are unwilling to do the work and take the time necessary to get to the root.
With people, symptomatic fixes tend to harm motivation. With workflows, symptomatic fixes exacerbate bottlenecks. With technology, symptomatic fixes can cause a technical system to slow down or crash. With money, symptomatic fixes can lead to cash flow interruptions or, in the extreme, bankruptcy.
The Way Out
As always, the first step is for leaders to change their mental models. Symptomatic fixes are attractive to leaders because they deliver temporary relief. But a sophisticated leader understands and resists their seductive temptation. They know that these fixes mask underlying problems.
When a negative symptom arises, the sophisticated leader will ask the “five why’s”.
Why did revenue fall short of goal? Because salespeople didn’t sell enough deals. Why didn’t salespeople sell enough deals? Because we didn’t have enough Opportunities. Why didn’t we have enough Opportunities? Because the mid funnel conversion rate was lower than expected. Why was the mid funnel conversion rate lower than expected? Because customers who thought they were interested in the product became less interested the more they learned about it. Why did they become less interested? Because there is a key product gap that caused most customers to back away. Ah hah. Now we know the root of the problem.
The idea is to step back and think more holistically. Map the system. Consider all interdependencies inside the system, and even system-to-system interdependencies. Think about the interactions between people, workflows, technology and money. How are these four elements of the system revealed inside its stocks, flows and feedback loops? Consider how the system’s purpose fits into the overall enterprise’s purpose. Are they aligned? Before you intervene, make absolutely sure you have identified the root of the problem.
More broadly, as CEO you must work to build systems thinking competency in upper and mid management leaders, and eventually all levels of your company. Encourage everyone to watch out for local or individual incentives that unintentionally work against the broader enterprise’s purpose. Encourage people to challenge sacred cows and point at elephants in the room. And be especially careful not to use technology to advance a symptomatic fix. Technology is expensive, takes time to build, often has hidden interdependencies and can be hard to unwind once implemented.
For years, your company grew briskly. The companies in your chosen customer segments considered your product (“Full Feature”) the clear leader in its field, delivering breakthrough value. For years, they lined up in droves to buy it, driving your revenues higher and higher in a virtuous cycle. But a few years ago, a competitor emerged that delivered a “good enough” value product, at a much lower price point. Since then, your sales have stagnated, and recently revenue has begun to decline.
You were quick to act. You recognized the need to offer a new, lower-cost, more lightly featured product (“Lite”), even if it meant that some enterprise customers might downshift from Full Feature, costing revenue. Product and engineering delivered. Lite exceeds the feature set of your competitor, at a similar cost. You launch the new product to your sales team with great fanfare.
But five months later, sales of Lite have been dismal. Even though sales of Full Feature are declining in year over year comparisons, they comprise almost ninety percent of last quarter’s sales. Lite comprises just ten percent.
What has happened?
As you dive in, you learn that salespeople hate to sell Lite. Lite pays just ⅓ the commission of Full Feature. Because your sales team’s experience is selling at the C suite and VP level, account executives continue to sell to the targets they know. The price point of Full Feature is appropriate for a C level or VP level decision, so they lead with Full Feature. Lite remains in the back pocket, only to be proposed in a pinch. They know that to sell Lite effectively would require a higher velocity sales motion, selling to the director level. But your high-paid, senior enterprise sales team doesn’t want to work at this pace. So they don’t. You call the sales team together. You describe the competitive dynamics that are at play, and how critical it is to the company’s future for Lite to start winning in the marketplace. The sales team nods, seems to agree, and claps when you are finished. But nothing changes.
Policy resistance looks like this:
Policy resistance occurs when resistance is the rational response of a human actor in the system, given prevailing incentives and competencies. The actor’s internal incentives create a balancing feedback loop that works against the policy.
Upper management wants Lite to succeed, even at the expense of Full Feature. Mid management, judged on total revenue performance, isn’t so sure. Frontline salespeople are sure that selling Full Feature is better for them, and that Lite works against their interests. If upper management’s efforts succeed, it comes at the expense of the sales team (lower commissions, harder work). If the sales team’s resistance succeeds, it comes at the cost of upper management (failure to mobilize an effective response to competition). So Sales continues to sabotage the strategy, pushing Full Feature instead of Lite, with mid management acting indecisively and upper management pushing in the opposite direction.
The Way Out
In the face of policy resistance, one option is to overpower it. Occasionally, when the stakes are very high and time is very short, this may be the right response. But in most instances, it is not. Submission may work in the short term, but it often comes with negative downstream consequences — a symptomatic fix that backfires. More often it is better, in the words of Steven Covey, to “seek win-win”.
The mental model shift starts with sharing the problem. In the above example, upper management, middle management and frontline sales need to talk with each other — to reveal why this policy shift is so important, and to reveal the hidden incentives at play that are causing the policy to fail. Once the underlying system dynamics are revealed, all actors can creatively engage the problem to find systemic solutions. In this example, perhaps the existing sales team can return to selling just the Full Feature product, while a new sales team is recruited to sell Lite — comprised of salespeople who have previously sold at the director level, at Lite’s price point and at the necessary sales cadence.
The Tragedy of the Commons
Let’s say your company has 500 employees. Perhaps you are old school, and your IT infrastructure is on premise. It has a definitive limit to its compute capacity. Or perhaps you’re on the cloud, but you can afford to spend only up to a given amount of money to compute.
For the past couple of years, you have worked hard to build company-wide commitment to becoming a data driven enterprise. Inside your CRM, ERP and product systems, you have large datasets ready to be analyzed. As you gain success with democratizing data inside your company, more business analysts start conducting data analysis. As each analyst gets the hang of it, new ideas for new analyses arise. The number of big data workloads to be processed starts to rise. But capacity is high, so all analysts are rewarded with powerful data insights. Interest in data analysis spreads throughout the company, prompting more workloads, tapping more of the compute capacity. Business analysts rush to process more workloads, fearing to lose out compute capacity to other analysts. Demand begins to grow exponentially, until the capacity limit is indeed hit. At that point, analysts encounter increasing delays. Even mission critical analyses are now caught in the backlog.
Or perhaps you have a channel sales partner, plus a direct sales team. Selling rules have not been carefully defined. In an important sales region, prospects begin to be approached by both your direct team and your channel partner. As the direct team realizes it is competing with a channel partner for customers, the team starts to blitz the region. In response, the channel partner does the same. Soon, the channel partner and direct sales team are tripping over each other, selling to the same prospects. These prospects quickly become fed up, kicking both of you out. The rich field of prospects becomes overstressed, degrading performance for everyone. The final straw is broken when you learn that price wars have broken out between channel and direct.
These are examples of the tragedy of the commons archetype. Ecologist Garrett Hardin coined the phrase in 1968. He shared the example of herdsmen pasturing sheep in a village commons. When one herdsman brings his sheep into the commons, they eat to fulfillment with no harm done. But then another herdsman, who has been grazing sheep on his own land, figures to save by letting his sheep into the commons. More flocks follow, until the commons is filled with sheep. At that point, the sheep are eating so much grass, the food supply collapses. As the hungry sheep dig up the grass from the roots, the entire lawn dies off, leaving all sheep hungry. That’s the tragedy of the commons.
It looks like this:
As a feedback loop, it looks like this:
The Way Out
To solve for this archetype, each actor must understand that the resource has limits, and is not just for him. This mental model shift can be accelerated with data visibility. If all actors see capacity usage in real time and are alerted when constraints are being approached, this supports acceptance of rules to manage the commons.
The rules that govern use of a common resource should be designed to advance the enterprise’s purpose, not just the subsystem’s purpose. One simple solution would be to establish a maximum level of simultaneous use, and then queue on a first come, first served basis. But not all demands are the same. Some have much greater impact on advancing the enterprise’s purpose than others.
A truly effective rule set will differentiate user access privileges based on importance and urgency, consistent with the enterprise’s purpose. To determine relative importance and urgency, leaders need to look holistically across the enterprise and understand deeply the interdependencies inside the operating systems and meta systems. The more systems thinkers you have throughout your company, the more likely it is you will come up with a balanced rules set for governing the commons.
Rule-setting to manage common resources is particularly important in the DataOps and engineering systems. The purpose of these systems is to increase leverage throughout all operating systems, in service of the enterprise’s purpose. How development projects are prioritized, how operations issues are triaged and how data analysis privileges are allocated are decisions of the highest order, to be made with great care.
Declining Goals, Declining Performance
For the past three quarters, your startup has fallen short of the board-approved revenue plan. The reasons are many — sales hiring has been slower than expected, your new product release was delayed and a promising channel partnership fell through. But now you’re facing dissention in the executive group. Your execs depend on their annual bonuses, which are tied to fulfillment of the plan.
So you lobby your board to reduce the goal. Given all the headwinds, it’s amazing you’ve done as well as you have. If we want to hold on to our stellar team and keep morale high, we need to adjust the goals into a more ‘reasonable’ range.
Here’s another example. Three months ago in accounts receivable, the average days outstanding stood at 45 days, ten days worse than the year prior. For context, it’s important to know that your company serves a sector under cyclical distress. Ironically, this has helped sales — because more than ever, customers value your product’s cost-saving properties. But they also have weak balance sheets. Despite the steady sales growth, customers have begun to slow-walk their payments. Which is a problem, because you are understaffed in AR. Even worse, over the years a watch-the-clock, DMV-like culture has developed in the department.
After months of complaints, you recently relented and changed the days outstanding goal from 35 to 45 days. What happened? Now, two months later, it stands at 55 days. Once again, AR employees are lobbying for another goal adjustment — “more in touch with the new reality”.
These are examples of the declining goals / declining performance archetype. It looks like this:
Management sees the changing of a goal as a necessary evil to deal with ‘reality’. The goal must have been too high in the first place. Falling short of a goal is a sin, and if performance can’t meet a goal, the goal should change so that we never fail. This goal adjustment is envisioned as a one-time, unnatural act. But employees see a pattern — ‘our performance must be fine, because they always change the goals to match.’ Goals were established so that performance could rise to the standard, but eventually the opposite begins to happen — standards fall to the level of actual performance.
Here are the feedback loops at play:
The Way Out
The mental model shift is to appreciate the capacity of the enterprise to continuously improve, while also appreciating that improvement takes focus, creativity, hard work and resources. Without continuous optimizing interventions, any system will tend to degrade. If you are not green and growing, you are ripe and rotting.
Standards, when aggressively realistic, motivate behavior. To establish these goals, observe the performance of the best actors in the system. Set goals that match top tier performance. As you see top tier performance rising, raise the goals. Then make sure you are providing sufficient resources and support for system actors to achieve their goals.
And when you fall short of a goal, involve everyone in the post mortem. What can be learned the next time? Attack the problem, not the people.
Two of the most capable executives in your company are your VP Marketing and your VP Sales. They are a big part of the success you have already achieved. After years of steady growth in one market segment, you have begun to cap out. It is time to extend your product to a new market segment. Your VP Marketing conducts an analysis, and determines that the next logical move will be to enter segment “X”. But at the same time, your VP Sales has been out in the market talking with salespeople, customers and prospects. He has determined the most promising next segment will be segment “Y”. These two different points of view are first aired in a heated exec staff meeting. When the VP Marketing completes his presentation, your VP Sales describes the proposal as “idiotic”, and proceeds to present the counter argument.
After the meeting is over, you immediately call one-on-one discussions with both of your executives. You challenge them to figure it out. But no agreement can be found. Salespeople start to sell in Segment Y. Marketing begins to build campaigns for Segment X. It becomes a running argument, with real work occurring in both camps, one at cross purposes with the other. Your repeated attempts to intervene fall on deaf ears. It has become a power struggle. Marketing and sales have become incapable of working effectively together. After one last failed attempt, you decide to side with your head of Sales and fire your head of Marketing. Within six months, a third of the marketing staff has left.
Here’s another example. Your competitor has fairly close feature parity to you. You are both targeting the same market segments. As your superior revenue engine begins to yield market share gains, your competitor drops its price. You quickly follow, dropping your price to match. Your competitor follows again, dropping further. You respond with a radically aggressive price cut well below your competitor’s price, hoping to squeeze it out of the market. But now your gross margins have fallen precipitously low. When the competitor cuts even deeper, you are left struggling with what to do. You match the price, but now offer a “switch bonus” if a customer switches from your competitor to you. Your competitor quickly responds. Unit sales stabilize, but revenue and profit have crumbled.
These are two examples of the escalation archetype. It occurs whenever two participants fall into a win-lose pattern of competition. Here’s how it looks:
In the escalation archetype, A reacts to B’s activity, always seeking to counteract it. As A’s activity level rises, B’s activity level rises in response. In systems terms, the state of B’s stock becomes the desired state of A’s stock. Like this:
In an escalation scenario, the stock at stake is always an indicator of system power. Just like a superpower arms race, the goal of one party is always to match or exceed the power of the adversary.
The Way Out
To break out of an escalation pattern, you must shift your mental model from win-lose to win-win.
The best way to escape is to avoid getting into it in the first place. Inside your company, you can develop collaboration as a cultural norm. You can coach executives and middle managers on how to “seek win / win” in cross-functional partnerships.
If you find yourself stuck in an escalation pattern, you can unilaterally disarm, breaking the cycle. For instance, if the escalation pattern is with a head-to-head competitor, you can choose to enter a different market segment and begin to further differentiate your feature set. You can change your business model to make a head-to-head price comparison more difficult.
Or you come together with the adversary, and seek to identify a set of engagement rules that allow room for both of you to operate independently. Of course you can’t, for legal reasons, do this with a competitor.
If your rival and you operate inside the same company, the mature leadership step is to work together to figure it out. Seek deep understanding of the other’s goals and perspectives, both personal and professional. This will provide you context to pursue win / win solutions.
Success to the Successful
Your VP Sales’ first anniversary was last week. When he arrived a year ago, one of his first moves was to overhaul the sales compensation structure. He introduced a monthly “salesperson of the month” bonus — $3000 to the top performer. He also has created new account assignment rules. Every time a new qualified lead comes in, the top three salespeople from the previous month get first dibs at taking the lead (in round robin order). As a result of this rule, every hot prospect is taken by one of the previous month’s top three salespeople, up to their handling capacity.
For the first six months, these changes caused a big uptick in sales. Four salespeople quickly emerged as rivals for the salesperson of the month award. Salesperson A won it in month 1, B in month 2, C in month 3 and D in month 4. Then A won top honors in month 5, and B in month 6. The rivalry drove significant monthly sales performance increases from these top four. And since most top quality leads were going to them, their individual performances pushed steadily higher.
The problem was with the other sixteen salespeople. At first, their performances remained stable. But as the performance of the top four separated further and further from the performance of the rest, the latter’s motivation fell off. It wasn’t fun to be a loser month after month. Starved of good leads, the pack slid down in monthly sales performance. Now, a year later, you have made the tough decision to fire your VP Sales. Overall sales are down versus prior year. Five solid, middle-of-the-pack salespeople have left the company. And the Sales department, once a source of enthusiasm and energy, now shows unmistakeable patterns of rivalry and escalation. A once vibrant sales culture has devolved into turf wars and infighting.
The success to the successful archetype looks like this:
As feedback loops, it looks like this:
The Way Out
The success to the successful archetype depends on a flawed mental model. The model presumes that more resources for top performers and less for all others will increase top performer performance without a cost to the performance of all others. But of course, that’s not true.
Optimizing the allocation of resources and rewards is delicate work. Ensure your goal is in full alignment with the enterprise’s overall purpose, not just a time-bounded local purpose. Increasing the performance of a few is not the goal. Just making this quarter’s sales quota is not the goal. Your objective is to increase the overall system’s long term performance. Don’t steal the future’s performance to achieve today’s goals.
Breaking out of this system trap is best achieved through continuous experimentation and optimization. Your mission is to devise an allocation of resources and rewards that retains and motivates top performers, while simultaneously ensuring all others are engaged and motivated as well.
Leadership as Enablement
Your co-founder and VP Engineering is an outstanding architect. She devised the schema for your entire technology stack, and built an outstanding product. Success led to funding, which led to more engineers. Today she leads a twenty-person, hand-picked engineering team. But engineering productivity has fallen steadily over the past two years. You’ve begun to sense that your head of Engineering is a much better architect than she is an acquirer of talent.
She has devised a management approach to ensure her middle-of-the-road team does not architect and code with middle-of-the-road quality. All schemas must be sent to her; she fixes them. She conducts regular code reviews and makes changes herself. The problem is that she has become the department’s bottleneck. A large queue of unreviewed work has piled up. As she fixes everyone else’s work, she spends less and less time talking with her employees.
Architects and engineers have fallen into a co-dependent pattern with her, increasingly seeing their submissions as “first drafts”, knowing that she will complete the “final draft”. The responsibility for quality work has been delegated upwards to her.
Whenever a large enterprise deal moves to the Opportunity stage, your VP Sales takes over. Account executives become assistants on the final mile towards a deal. Since he is an accomplished enterprise sales executive, he has a high conversion rate. But last quarter, the number of enterprise deals at the Opportunity stage exceeded his capacity. He was forced to let assigned account executives carry four large enterprise deals towards close. Since these AEs had little experience in traversing the final mile, none of the four deals were closed within the quarter. For the VP Sales, this provided further proof that he is the only one sufficiently capable at big game hunting when it matters most.
These are examples of the leadership as enablement archetype. It looks like this:
The leader perceives that the only way to produce quality output is for the leader to do it. The leader’s superior competency ensures it will be done right every time. Rather than focus on developing the competency of subordinates, the leader assumes their inferior competency is a constant, and a constraint to work around.
Here are the feedback loops:
The Way Out
The flaw in the mental model is the assumption that having a leader with superior competency do it herself when her team falls short will yield maximum output. There are two problems. First, the leader’s personal capacity quickly becomes a bottleneck. And second, subordinates are not afforded the opportunity to develop their skills. Denied responsibility for solving difficult challenges, and denied the encouragement and development tips a good coach provides, these employees languish and become co-dependent.
To solve for this, the cycle must be broken. Stop the enablement, and make subordinates fully responsible for top quality work. Keep standards high. Don’t relieve the symptomatic pain of consequences.
Leadership is leverage. The high leverage leader uplifts the competency of subordinates through challenging assignments and insightful coaching. This is a key systems design principle: the more a system can self-organize, the more healthy it is. It’s the job of leaders to continuously uplift the competency and self-organizing capacity of the teams they lead.
The product road map is the result of a formal review and prioritization process. Feedback is gathered from Marketing, Sales, current customers and prospects. Key strategic questions are reviewed in exec staff meetings. The road map is updated monthly. Once established, the road map is used to allocate work to architects, back-end engineers, application engineers, database engineers, front end designers and product managers.
One day Fred, your head of sales, buttonholes his good friend — a top engineer. He explains there is a huge sale hung up by one small feature your platform lacks. “How much work would it take to build it?” The answer comes back that it would take him two weeks full time. But it would disrupt the project he’s already assigned to. “ Fred indicates if it’s done in four weeks he can get the sale. “Any chance you could do it on the side, say half time, under the radar? Just say your other stuff was taking longer than expected?” His buddy does just that.
The approved project falls behind schedule by five weeks. Working on the secret project created a ripple effect — one engineer’s two-week slip in deliverables for the approved project produced delays for other engineers, creating unexpected lags and bottlenecks. As a result, the timing of a major product announcement is thrown off, forcing media cancellations and last minute re-bookings that cost of $400,000. The secret project is done on time, however, enabling the VP Sales to close one additional sale, worth $100,000.
Here’s another example. A multi-step hiring process is in place at your company. For engineers, it requires rigorous testing, coding projects and separate interviews with at least three engineers. There is also a group interview with non-engineers, to test culture fit.
Your VP Engineering is presented with a rock star candidate sitting on two other job offers. This engineer comes recommended highly by someone she trusts. His resume is impressive, having worked at other successful companies doing work similar to what you need. He seems intrigued about your company and is interested in the work. But he needs your VP Engineering to make a decision right away — he has no time for a complicated, bureaucratic process. She decides to hire him on the spot. Six months later, his productivity and code quality is top class. It is clear she made the right decision.
Here’s a third example. Salespeople have been instructed there is a $100 expense limit on meals with clients. This rule applies to all three hundred salespeople across the country — whether they be in Albuquerque New Mexico or San Francisco. As a result, most submitted client meal expenses end up between $95 and $100. Most sales reps comply with the letter of the rule.
However, one sales rep based in New York City has consistently flaunted the rule, submitting expense reports with meals running well over $200. He is also the fourth best salesperson in the company.
During an internal audit, an accounting manager notices a pattern of infractions going back six months. She tallies up the excess charges and submits an order to the payroll department to deduct the excess amount from the salesperson’s next paycheck. When the salesperson discovers the payroll deduction, he becomes so upset he quits on the spot.
Rule beating is dysfunctional when it works against the enterprise’s purpose. If the rule’s intent is in alignment with the enterprise’s purpose and it is broken, that’s dysfunctional. If the rule’s intent is in alignment with purpose and is met to the letter but not the spirit, that’s dysfunctional. If the rule’s intent is out of alignment with the enterprise’s purpose, following the rule is dysfunctional; breaking it is functional. The next functional step would be to rewrite the rule.
The Way Out
When presented with a rule beating incident, the first mental model shift is to start with first principles. Is the rule itself appropriate, given the enterprise purpose? Perhaps the rule serves one function’s or one operating system’s local purpose at the expense of the overall enterprise purpose. If that’s the case, the right step would be to applaud the rule beating and rewrite the rule.
If the rule is consistent with enterprise purpose, then the next step is to better understand the motivation behind the rule beating. Attack the problem before you attack the person. What purpose was served by rule beating? Was there a legitimate need not accounted for in your rules? Perhaps the rules need to be creatively redesigned to better account for these unmet needs.
Rule beating can also occur due to selfish behavior. When that is the case, the person is the problem — and you must act so that person shifts behavior or faces the consequences.
Seeking the Wrong Goal
Your B2B SaaS product has just emerged out of beta. Many of the assumptions you had about your product’s value have been confirmed, but you have been surprised to learn that your biggest opportunity is not to sell small subscriptions to thousands of developers, as you had originally thought. Rather, you now believe there is a large enterprise sale available to you — big subscriptions sold to the CTO and VP Engineering level.
But your largest investor invested because he believes in freemium-based technical businesses — where free developer use up to certain limits yields small initial subscriptions, which then “land and expand” over time. He acknowledges enterprise opportunities can emerge, but is convinced that can only happen once developers have adopted your technology through small subscriptions.
You, on the other hand, are convinced he’s wrong. You have studied the impact of your product on your first customers. You have talked with prospects. You have learned that the value of your product is very significant at the VP and C suite level, but less important to developers. You do not have confidence developers will try it as a free product, nor convert to paid. You fear that by pursuing the developer path you will waste time and miss the enterprise opportunity.
But money is starting to run short. You need this investor to participate fully in the next funding round. So you set aside reservations and launch your product selling to developers via a freemium offer. The investor joins in the next funding round, but it’s a small one. Eight months later, sales are stagnating. The freemium approach failed, and you have recently pivoted to the enterprise sale. But now you have run low on money and time.
Here’s another example. You created an incentive for your VP Marketing to maximize the number of leads generated for sales. She mobilizes campaigns designed to drive any type of engagement she can from a wide variety of prospects — both within and outside of the top priority segments. The campaigns are successful, in the sense that the number of leads spikes significantly higher. But lead quality plummets. As a result of the large increase in low quality lead volume, the VP Marketing receives a large quarterly bonus. Sales records a big miss on its quarterly revenue number.
Here’s how it looks:
The Way Out
Step back. Challenge the “tiny purpose” mental model. Look holistically at the full context. Reflect on the true purpose of the system. Specify indicators and goals that are in alignment with this purpose. Balance activity and outcome metrics; do not confuse effort with result.
Every archetype is like a reference architecture; you can use it for diagnosis. The meta archetypes and the garden variety archetypes presented here are system traps. You are likely to find one or more lurking inside your company if you look closely enough. Just as a doctor learns how to detect and diagnose a diverse array of diseases, so you as CEO must know the common archetypes so you can detect and diagnose them.
But it’s not enough to diagnose — you must also be able to intervene in a way that yields the desired result. Each archetype presents a pattern of dysfunction. To find your way out, you must intervene in the system.
That’s the subject of the next chapter.
- ISEE Systems. “Applying Systems Thinking and Common Archetypes” Online Training Course. https://www.iseesystems.com/store/Training/applying-systems-thinking/index.aspx