If it feels like your company is moving too slow, it probably is. When everyone becomes concerned with everything, then nothing seems to move forward. So, when departmental synchronicity hits a point of diminishing returns, the new way forward may be through decoupled operations.
Background
Digital transformation, bringing a new product to market, or modernizing a core platform requires your leaders to compete in a marathon; a marathon where each of their shoelaces are tied to each others’. This approach is clumsy, and you can only move as fast as your slowest runner. The time has come for business leaders to take a page from the book of architecture and engineering schools of thought and decouple departments.
Desperately Seeking Speed
Barriers to entry within high-tech markets have never been lower. Tiny startups now have access to the same (if not better) tooling and infrastructure once available only to behemoth corporations. Executives see the writing on the wall, and now more than ever have a sense of urgency around modernizing operations and capitalizing on new opportunities in order to remain relevant.
Naturally there are many ways to raise top-line revenue and build economic moats to ensure future market share. Some examples include:
- Building new products and services
- Adjusting pricing
- Running promotions
- Cross selling and up selling
- Creating a new and simplified subscription offering
- Minimizing human touch points from customer acquisition and activation
The bottom line is that businesses need the ability to rapidly adapt and experiment as needed. This simply will not happen with status quo management paradigms of the past, as these new (and often uncertain) times require new tactics.
Why Companies Move Slow
There are many reasons why companies move inefficiently. Having seen many different cultures across many different companies, I would assert that the top three issues are usually related to accountability, legacy, and politics.
Unclear Accountability
Unclear accountability christens the top of my slow-movers list as I see it so frequently. Personally, I believe most employees within companies mean well, and actually want to move the ball forward. The problem is: they often don’t know what position to play, or worse, what game they’re even playing!
Today’s corporate culture is increasingly inclusive. We bring lots of people to the table and solicit copious input. Diversity of both thought and of team members is crucial. But in many situations, there are simply too many people at the table. Multiple product managers, multiple program managers, several executives, and so on. Things quickly become convoluted as to who is accountable for what.
Without a decision-making structure, companies start to function more like coalitions of independent governments. If you’ve ever observed a government task force on C-SPAN or perhaps listened to a NATO briefing, you’ll notice lots of talk, and not a whole lot of action.
At the end of the day, every person in the room should have a clear role and responsibility, as well as a clear value proposition for how they’re contributing to the initiative. If a deliverable such as a project plan or technical design doesn’t have one (and only one) individual listed as the accountable party, something’s wrong. Yes, it takes a village to deliver complex outputs. And yes, there may be multiple people contributing to the delivering of whatever thing needs to be delivered. Yet there must be one person accountable for the result, and that person must have the authority empowered unto him or her to ensure things are delivered on time. Without these structures, the lack of accountability will create confusion and churn which will inevitably binge on project time like a python with an unhinged jaw.
Legacy Systems
When I refer to “systems” I’m not just talking about tech; I’m also referring to processes, attitudes, norms, and risk tolerance. It’s battling the proverbial “how we’ve always done things” mindset. Examples include breaking the chains from on-premises IT infrastructure to questioning what customers actually want.
Legacy systems are inherently complex. Yet as with many complex things, you don’t always need to know how they work internally. You simply need to know how to interface with them.
Ultimately, legacy systems are a bit like boat anchors. Sometimes you can reel the anchor up, place it aboard your vessel, then sail ahead with the anchor safely attached. Other times you need to cut the rope and leave the anchor at the bottom of the deep blue sea. You can then buy another anchor at your next port of entry.
Politics
Politics are the most complex of the bunch, as they involve human motives. Perhaps your peer executive doesn’t want you to succeed, or a department head fears your initiative will cannibalize his long-standing fiefdom. Regardless of the root cause, symptoms of politics include stalling, lack of participation, and outright disagreement without rational motives.
The Microcompany Approach
When I envision a “microcompany” I’m borrowing from the microservice paradigm. The theory goes: monolithic things are bad, whilst modular things are good. For example, if a skyscraper needed a fire sprinkler upgrade, you wouldn’t necessarily try to coordinate maintenance for everyone all at once; there’s simply no way you would find a free time slot across thousands of peoples’ schedules. Instead, you would work on upgrading the system floor by floor, and only employees on that particular floor are impacted for a brief period of time. Yet in order for this process to work, the sprinkler system must be modular. In a monolithic system, taking one floor offline takes the entire sprinkler system offline. In a modular system, taking one section offline only takes that section offline, and the remainder of the system functions normally.
The concept of decoupling business unit execution isn’t necessarily new. Similar examples intended to foster expedited innovation include:
- Spin offs – these may be informal “Skunk Works” projects or formal subsidiaries
- Innovation & incubation centers – Internal think tanks and focused “tiger teams”
- Hackathons – Time-bound innovation trials which are typically inclusive of all employees
The problem with these approaches is that they’re either really heavy (e.g. spin-offs) or they’re very light and temporary in nature (e.g. innovation centers & hackathons). What we need is a long-term solution that is both lightweight and persistent.
About Overexposure
One of the problems we’re trying to combat is overexposure; that simply means inundating leaders with too many underlying details associated with other teams.
As you can see in the image below, the engineering leader sees all the complexity of the sales team, and vice versa. When the engineering manager sees just how complex the sales side of the world is, she may be inclined to “design for the future” which may lead to overengineering or analysis paralysis. For example, the sales manager may explain his 2-3 projects in-flight: “CPQ is almost done” and “we’re about to revamp the commissions process.” This will cause the engineering team to pause, and wait for “things to settle” before doing anything at all. In other words, nothing moves forward from a cross-functional perspective.
Decoupling Departments
What is novel about the microcompany approach is how we scale back and limit the focus of information exchange between business units. Traditionally, leaders want to see the “big picture” and ask their peers for things like roadmaps, architectural designs, and future project plans. This holistic approach sounds rational and mature, and within slower moving-companies, this may be fine. But within large companies that have 50+ constantly-changing projects all in flight at once, this approach no longer scales. By the time a roadmap is ready to review, it’s already out of date. The point here is that’s ok! A roadmap should be an ever-changing work in progress; it’s not a milestone that magically unlocks engineering hours based on when it’s published or “completed.”
Removing the breadth of all-encompassing transparency (the overexposed fishbowl) and instead focusing on well-defined “interfaces” between the more opaque swaths of the business may be the way to win.
As we can see, there are two ways for departments to communicate: push and pull. The push layer is where one department pushes a requirement onto another. The corresponding department may accommodate or decline the request, but the request is specific, and formal. Servicing the request does not require broad understanding of all the underlying reasons behind why the request is needed.
Additionally, there is a more traditional pull layer which compliments the push request layer. The pull request layer exists so that if requesters or requestees want to know more about each other’s world, they may explore and learn at their own discretion. Example artifacts here may be self-documenting APIs on the engineering side, or (relatively up to date) sales and marketing plans published to the internal intranet.
Putting It All Together in the Real World
An Example Goal
Let’s imagine that an enterprise wants to test the assumption that a frictionless, self-serve onboarding process would raise revenue.
We don’t need to build new products per se, we just need to acquire and activate new users by allowing them to conduct trials and create sales transactions (e.g. new subscriptions) without needing to talk to a sales person.
The Existing Landscape
Let us assume the following set of real-world variables:
- Engineering has tons of legacy issues
- The sales team has a traditional structure of business development representatives (BDRs) and account executives (AEs) who represent the hunters who find new accounts and farmers who take care of existing accounts, respectively.
- Contracts are inherently complicated. They go through a 20-step configure-price-quote (CPQ) process with multiple approval chains required within the salesOps team.
- Sales is concerned any new process that doesn’t fit into the existing sales structure could jeopardize existing revenue streams
- The new growth team doesn’t care about any of these “legacy issues” and wants to run fast with experiments as soon as possible
The Solution Approach
The chief revenue officer assembles a “tiger team” dedicated to growth, and tasks this growth team with delivering a frictionless onboarding platform in the next 6 months. Let’s assume the growth team has no other competing priorities, and has adequate staffing and budget to execute on this vision. Note this team isn’t just allowed to create a new function, they are empowered to build a very small enterprise; a “microcompany” which handles some aspects of marketing, some aspects of sales, and some aspects of engineering.
Using this microcompany approach, the growth team could build its own onboarding microsite and attach it to a preexisting marketing funnel. (Website visitors who click on “product trial” calls to action are immediately passed into this new onboarding platform.) This platform may be a completely different tech stack from what engineering is currently using for ecommerce, and that’s fine for now.
When prospective users sign up, they enter company (account-level) and personal (contact-level) details. The information is passed via API to the existing ecommerce platform managed by engineering and to the CRM solution simultaneously. Whether sales does anything further with the account can be determined at a later date. Engineering, on the other hand, must be able to ingest the account and contact information, then provision a trial of the online service for a time-boxed period of time. After the trial period, the ratio of accounts which churn versus those that convert is the true measure of the experiment’s success.
Will this approach ruffle some feathers? You better believe it will. Engineering leadership will be upset that a “rogue” team is setting up new technical infrastructure on their own, and there will be all sorts of data management challenges to solve. Sales won’t like the fact there’s a new revenue-generating team in town. Marketing will have all sorts of reasons why the new growth team cannot re-instrument the marketing web properties with new calls to action. But will the world keep turning? Yes, it will. Did you generate new revenue? Yes! Would this have been possible by trying to align status quo departmental processes? Probably not!
Microcompany Trade Offs
As with any process or design pattern, there are trade offs, and the microcompany approach is no exception.
Microcompanies will certainly introduce some degree of (controlled) redundancy. A new tech platform here, a new marketing microsite there, and so on. The lifecycle of these new capabilities must be governed, typically by being absorbed or migrated as to prevent tech sprawl and tech debt.
Microcompanies can create brand confusion as well. If a new web property has a different look-and-feel, a different logo, or a different tone of voice then customers may become confused or reluctant to trust this new customer-facing surface.
Final Thoughts on Microcompanies
I’m not advocating that leaders are to hyper focus on their own deep areas of expertise exclusively. There should always be a handful of experts who understand cross-functional enterprise processes from cradle to grave. (I’m looking at you, enterprise architects.) But this responsibility isn’t for the everyday functional leader. Department heads naturally focus on their domain, their span of control, and their own problems. Unfortunately, this can create tunnel vision, and thwart cross-functional initiatives like bringing a new product to market or altering the ways new customers are onboarded.
Conversely, trying new things shouldn’t require “everyone to know about everything.” This is too complex, and simply doesn’t scale. Moving away from bespoke initiatives and toward utility-grade scale requires us to think about the resilience of the road, not the make-and-model of every car intending to drive on that road. We must think about the safety and volume of electricity delivered; not necessarily every unique electronic device consuming power.
