Read through a list of The New York Times bestselling books on how to set goals and you’ll find many converge on one curious idea: Goals are mostly a bad idea.

Instead, people who achieve truly remarkable things seem to prefer to set systems. In his book Atomic Habits, author James Clear explores this premise: Goals encourage activity, but not necessarily growth. In fact, they may punish growth. 

Why? Goals are binary. You check them off or you don’t. You either win or you fail. Mostly, you fail. All of that progress you made in pursuit of the goal doesn’t count, and goal-setters struggle under a cloud of discouragement when their best repeatedly falls short of perfect.

But if you instead set a system, you celebrate small wins. You encourage incremental improvement, holistic thinking, and you reach that goal after all. I have found that nowhere is this idea more immediately applicable or tantalizingly transformative than in business systems, where we desperately need some new thinking.

(Skip ahead: Learn about the new practice of “business engineering.”)

The business applications profession is changing, and it demands systems thinkers

The enterprise SaaS market is highly mature and still growing at a remarkable 10% year over year. The reason for that is not simply that modern companies like to use SaaS—it’s because they need it.
‍
SaaS creates internal efficiency and has become a foundational competitive advantage for companies that use it. Just picture a business that didn’t—they announced they were abandoning the cloud in favor of on-premise, or paperwork. It wouldn’t scale. It wouldn’t survive. It wouldn’t be competitive. And try as they might to cut redundant applications (enterprises have an average of 843), no sizable company today can exist without their vital core—CRM, HCM, ERP, marketing system, and the like.
‍
But things are coming to a head. So much SaaS dependence and the fact that tech stacks develop in silos causes them to careen toward unmanageable complexity.
‍
With business systems managers only reacting to others’ goals, their work doesn’t line up. Errors compound, requests conflict, and the people who manage them face daily discouragement, for nobody ever gets through their backlog.
‍
I think it’s time for a new way of thinking about our business applications because these factors will only grow more acute:

• We’ll have more cloud-based business systems, and;
• They are vital to business operations
• They are numerous—843 applications per enterprise
• The complexity and history within each application is constantly growing
• Their interoperability is crucial
• They are managed by many people in many geographies
• They grow into tech stack silos (what I call “app constellations”)
• Yet, business work streams must operate horizontally across those silos (quote-to-cash, hire to retire, etc.)
  

How’s that for a complicated equation? It’s very difficult to set goals for these teams when even the smartest people managing these systems can’t describe the ideal end-state. The story is still unfolding.

So instead, we should encourage them to focus on building systems, and being systems thinkers who consider the structure of the whole “product.” We need them to be opinionated and exacting—to triage their time and ignore unimportant requests in favor of building durable systems that don’t accrue a paralyzing amount of technical debt.
‍
There are of course a tremendous number of practices these teams can adopt from software engineers, who already operate this way. But there’s also one big thing we can do to help these teams do more systems thinking, and that’s by starting to call them “business engineers.”

Managers execute, engineers design

We don’t take advocating for the new practice of “business engineering” lightly. But we’ve watched other teams try on all other approaches and other titles and they don’t seem to fully convey the magnitude and importance of the work these people do. On top of that, the complexities are mounting—their scope is lengthening, their responsibilities are multiplying, and they’ll need new, interdisciplinary skills. We have to prepare for this future, as it’s right around the corner, and “systems manager” no longer cuts it.
‍
Calling these individuals “engineers” suggests more authority and responsibility for the integrity of the entire business systems structure. We cannot have people building the “product” upon which the business runs simply by executing requests (read: accepting goals) from each line of business. We need them to play air traffic controller for those requests—to think of outcomes, not tasks, and to think of systems, not simply activities.
‍
Increasingly, these teams are centralizing under the office of the CIO (often called “business technology”), which is the right move. But we think consolidation also must go further. All too often, these team members are spread across lines of business, or loaned out to those lines of business. A central business engineering practice and department would do a better job of coordinating work across app constellations, and connect them.
‍
And finally, gathering everyone under a unified title allows the people doing that work to gather and share wisdom. These individuals are the unsung heroes of modern business. They, more than perhaps any other group, are responsible for sustaining revenue growth, and fighting off decline. Their success is the company’s success.
‍
We at Salto want to see more of the leaders shaping this future connect and trade notes. And that starts with defining the practice.

So if you’re on board with this idea, what steps can you take? An easy start is reading about business engineering. Another is considering giving your “managers”—who already carry so much of this weight—the well-deserved and much-needed title of “engineer,” and seeing how their thinking changes, and what it does to your systems.