How to Transform a Business Systems Team Into a Business Engineering Team

First responders versus engineers

Imagine you approach three business system administrators all working on a problem together. You ask them each what they’re doing, and they each describe it differently.

One says they’re fixing a picklist error.
Another says they’re responding to a sales complaint.  
The third says they’re helping the revenue organization hit its Q3 numbers.

Technically, they are all right. It’s the same problem. They just have different perspectives, and those three admins are going very different places because only the third one is acting like a business engineer. Only the third one knows their job isn’t just to build business systems—it’s to build a business. And only that third one is actively adopting and adapting developer and DevOps best practices to manage and continuously improve their business applications, because they see it all as one product.

‍

Businesses that want to adapt need business engineers.

‍

Whereas the first two admins fancy themselves first responders, primarily there to resolve requests, the third does not. They think more like an engineer, and they want to see the full schematic before they make a change. Whereas the first two prefer immediate action, the third tends to pause and reflect. And whereas the first two aim to please their internal customers, the third one feels okay not being loved by everybody if that’s what leads to the right customization for the business.

In today’s business applications environment, too few administrators get to act like that third administrator. Few have the support, tools, or awareness to plan with the knowledge that there’s more than their singular feature, workflow, or application. But soon, many more will have to learn to think this way. Businesses can only innovate and turn demand into cash as fast as their business applications administrators process change and keep pace. Businesses that want to adapt need business engineers.

‍In this guide, we explore ways you can transition a team of first responders into a team of engineers, based on the experiences of several real-life teams.

Teach your team that there are no business applications—only one distributed business system product

Together, your business applications constitute one large, distributed product. That’s how executives, investors, and board members see it. They’re concerned primarily with how workflows succeed, such as the go-to-market motion that turns website visitors into pipeline, or the quote-to-cash system that turns proposals into revenue.
‍

People with this overall view tend to be concerned with the overall forest. But today’s administrators think really hard about the few trees under their stewardship because that’s how they’re measured. They are encouraged to think narrowly about features, buttons, and requests that pertain to their part of the system forest.

That narrow view means administrators tend to optimize for what’s known as a “local maxima.” They’re trying to climb the closest hill they see (which is where their department would function at its highest capacity) and therefore miss a higher, better hill nearby, which is the global maxima, where all departments would function at their highest collective capacity.
‍‍

Let’s consider an example. The marketing team might set a goal of 95% complete and up-to-date contact data in the CRM. That “local maxima” might lead them to invest in a data appending tool that, in its effort to update all the data, overwrites many old, correct contact phone numbers with newer 1-800 numbers. Marketing would hit its local maxima while making life much more difficult for sales, and compromising the global revenue team maxima.

If you can wake your team up to the idea that global maxima exist, and that they matter more than their local ones, you can begin to infuse a sense that there’s an overall structure everyone needs to be collaborating on. That, rather than forming silos with long strings of approvals, or allowing each team or department to develop its own platform-specific language (is it an org or an instance? A rule or a workflow?), everyone should be speaking one language. Because it’s one product.

‍
‍‍

Does this mean choosing “best of breed” systems is bad?

Not at all. It’s great that every department can select and use its favorite systems. But sometimes this creates unnecessary inefficiencies—as when several teams use different project management tools. Look for opportunities to standardize where there’s no downside

‍

Push to build one central business engineering team

Back in 2020, the business systems department at the customer communications platform Intercom found that growth was exacting a heavy toll.

As they built out each business application to support the burgeoning marketing, sales, success, and finance organizations, they hired application-specific teams. But now all the cross-app coordination was soaking up added hours, causing too much confusion, and causing the backlog to rattle out of control. “

Like any company in hypergrowth, we were evolving rapidly,” says Jalal Iftikhar, then Global Director of Business Systems. “Maybe a year back, our business systems unit was all working in silos. Sales ops, marketing ops, and billing each had their own tech stack … it felt like we’d reached the max output from all the teams. How could we get to a level where we were adding more fungibility, thinking about problems holistically, all under one roof to do it fairly quickly, without creating a single point of failure?” That led Jalal and his boss to merge all those teams into one.

‍

That led Jalal and his boss to merge all those teams into one.

‍

“We gathered together billing, data engineering, sales systems, marketing systems, and support systems under one umbrella,” says Jalal. “Then, we created a substructure for the business system analysts, the business systems engineers, and the product engineers.”

The result was those teams did a much better job of decoding the business side’s needs. Analysts who used to work directly with stakeholders now also worked alongside other analysts for other applications, and had a much better sense of the overall architecture. They were able to nudge Intercom’s business system “product” toward its global maxima.

How could we get to a level where we were adding more fungibility, thinking about problems holistically, all under one roof?

- Jalal Iftikhar, former Global Director of Business Systems, Intercom
‍

Meanwhile, Monday.com faced a similar challenge

In another corner of the world, the project management tool Monday.com was growing just as rapidly—from a few dozen employees to 1,000 within just five years. Then they went public. That rapid rise caused their business systems team to organize differently from most.

“We don’t adhere to one philosophy,” say Oran Akron, Head of Business Operations, and Raz Ben Ron, Business Applications Team Lead. “We’re about doing things that work and taking all directions at once, in many experiments.” The speed at which they were moving didn't afford them the luxury of building out separate teams for each application. To maintain their velocity and be able to reallocate people as needed, they limited themselves to one BizOps team under the revenue team.

‍

We also think one of the best ways to help everyone move quickly is to hire generalists.

‍

That BizOps team embeds people in each of the different business units in what the company calls a “guild” approach. “We also think one of the best ways to help everyone move quickly is to hire generalists,” say Oran and Raz. “We want our developers to understand the business, and business people to understand the systems. That’s why we have our own developers. It’s one team with its own technical talent.”
‍

Two companies, same approach

Intercom and Monday.com are two different companies that both landed upon what thousands of midsize and larger organizations today are doing: The most effective way to organize a team around what is essentially one business systems product is to have one business systems team. A business engineering team.

‍

The most effective way to organize a team around what is essentially one business systems product is to have one business systems team.

‍

Having just one team inevitably raises cross-application awareness. It allows you to establish organization-wide conventions and processes that make it possible for individuals to cross-train in multiple applications. It leads to more realistic triaging and helps you consolidate inbound requests. (Partly because you’re now thinking about how data flows between systems, not just within.) And it helps everyone see that that constellation of applications must function well, not just one singular one.

Top takeaway

• Consider reorganizing your operations teams based on what your business demands. Some have organized all ops into one business engineering team under revenue. Others organize those teams by business process, such as go-to-market (GMT), finance, general applications, and more.
  ‍
  

Narrow your scope to top-tier systems

The average midsize or larger company has between 175 and 843 business applications, depending on how you measure it. That’s a lot of systems. It’s a lot of competing priorities. And it’s far too much for one central business engineering team to manage. (IT tends to only manage 23% of a company’s business systems.)

We’re advocates of narrowing your scope so you can do fewer things better and overachieve in the areas that matter most. Let your security team worry about which Chrome and Outlook extensions are insecurely storing passwords. And allow the business units to test and incorporate new plugins and AppExchange apps. Focus your attention on the big pillars that support your business’ growth.

‍

Focus your attention on the big pillars that support your business’ growth.

‍

One way to start narrowing your focus is to divide your systems into tiers of importance based on what impact their failure might have on the business. They may not necessarily be the most-used ones, but they will certainly be those that are the most closely tied to the company’s ability to continue driving revenue and improving its products.
‍

Anything less important than Tier 1 or Tier 2, hand off to IT or the business unit. Start by assuming control of the Tier 1 applications and mastering those before incorporating Tier 2. Once those are under control, develop policies for governing all others that fall within the application clusters and constellations.

Top takeaway:

• Divide your business applications into tiers of importance and delegate the less important ones.
  ‍
  

Teach administrators to think like engineers

When we talk about people becoming engineers, we’re talking about a lot more than just learning how to code. Knowing a coding language is valuable, but knowing how to think like an engineer is the real art. And one does not necessarily follow the other.

Lots of skilled software developers are great at fixing problems but lousy at architecting systems. To build a great system, you have to learn to become a system thinker, who understands all the complications and complexities inherent to the application, can anticipate problems, and can solve them in ways that work outside the test environment.

‍

Knowing a coding language is valuable, but knowing how to think like an engineer is the real art.

‍

Business engineers have a great intuitive sense of users’ needs, for example, and know that adding more required CRM fields won’t necessarily generate better data. It might actually make the data worse because salespeople are creatures of habit who’ll revolt against change and find workarounds through the deal desk.

Engineers also have a deep understanding of what the overall business is trying to achieve, and can anticipate how their various stakeholders might react to a decision. They know not only their own objectives, but those of everyone they work with. Before they set about building a configuration change, they plan. They adopt Agile and DevOps practices, and implement an application lifecycle.

‍

Engineers do as little work as possible to achieve their goals. They’re mindful of the business’ overall key performance indicators (KPIs), and don’t just rely on analysts. They like to listen to calls and shadow users and see how things are functioning in practice. Above all, they want to understand the problem, not the request, and are constantly training analysts and users to bring them just the facts.
‍

The essential skills of a business engineer

To be a great business engineer, it can help to learn about:

• DevOps
  
• Agile
  
• Sandbox strategies (Salesforce, NetSuite, Zendesk)
  
• The application lifecycle (Zendesk)
  
• Source control methodologies and tools (Git)
  
• CI/CD
  

It can also be a good idea to specialize in one particular area, in what’s known as a “t-shaped business engineer.” You learn a lot about a great many topics, but go particularly deep in one area. For example, if your specialty is NetSuite, learn everything there is to know about payment systems.
‍

Real stories from business engineers:

‍Eliya Elon’s story, Nicholas Erikson’s story

Adopt a DevOps and Agile mode of work

The more your team learns about business engineering, the clearer it’ll become that the most effective mode of work follows DevOps and Agile principles and methodologies.

These practices allow your team to increase release velocity and quality. They’ll also ensure that you’re maintaining resilient, backed-up, error-free records of how your systems are configured, which everyone can collaborate on.

The tricky thing is, DevOps and Agile aren’t one set of tools. And there’s no definitive guide or manual on how to implement these practices. They’re more of a community-guided philosophy, pieces of which you’ll find work for your team, and something you adopt and assemble over time.

Here, we share some practices you may find particularly useful.

Practices borrowed from DevOps, Agile, and more

Agile development
‍In the Agile philosophy, engineers make many incremental changes rather than big, monolithic ones. Rather than save up all the changes for a quarterly or yearly release, they do daily ones. They also continuously incorporate customer feedback, have people work simultaneously on the same systems, hold daily meetings, and more. (The opposite is known as a “waterfall” process, where a long list of tasks are completed in succession.)

‍DevOps and the effort to eliminate wasteful rework
‍If you practice DevOps, you probably build, test, and launch your configurations, customizations, and new apps within one workflow or pipeline. In the past, companies had two teams—one that built things, and one that launched things. DevOps merges them. (Hence the name—”development” plus “operations.”) Teams that practice DevOps maintain multiple sandboxes for testing customizations on their own, with real data and with real users before launching them. (Among many other things.)

‍Version control or “versioning”
‍At its simplest, a version control system maintains a snapshot of every change made to a system. (We’re really simplifying here.) The advantage to this is it’s automatic—you save those images as a byproduct of doing work—and can thus revisit them to debug things or revert if production goes down. It’s also a valuable record for others to figure out who else changed what—pretty valuable when you have a large team distributed across time zones.