Architecture Process: What Those Business Guys Want from Us, Technical People

Making Sense of What the Business Really Wants from Engineering

So, you're an architect. Congratulations, or maybe condolences—depends on the day, right? If you've read my previous article, you know that identifying your stakeholders (and understanding what they truly care about) is the first crucial step in the job.

Architecture Process: Who Is the Stakeholder and How to Find One

But let's talk about something even more practical: What do the "business guys" really want from us technical folks?

Let's be honest. As architects, we find ourselves caught between two camps. On one side, you've got engineering—your home turf. These are your people, the developers and tech leads you've probably grown up with. You speak the same language; you care about the same stuff. But that's only half the story.

On the other side, there's the commercial camp, comprising the business and product folks. Communicating with engineering? You may think it is easy. Will see.
Communicating with the business? Not so much.
That's where things get interesting.

---

---

What Do Engineering Managers Care About?

Let's start with your own house: engineering. Ever wondered what your management actually wants? Turns out, it's not rocket science.

The Business Layer

From a business perspective, engineering managers mostly care about three things:

1. Deliver Faster
   This is all about improving time to market. There's a lot of confusion here. Closing stories and epics is excellent, but if the feature isn't in customers' hands and bringing in revenue, it doesn't matter. The business doesn't care about your burndown chart—they care about when they can start selling.

2. Deliver What You Promised
   Predictability matters. It doesn't matter how fast you move if nobody trusts your estimates. If you say one month but deliver in two, you lose credibility. It's much better to be honest: say two months, negotiate the scope if necessary, and meet your deadline. Consistency builds trust.

3. Balance Maintenance and New Stuff
   Here's where the so-called "spending profile" comes in. How much engineering time goes to maintaining old things versus building new features? If you're spending over 30% on maintenance, it means one of two things: either the business has put your product on hold, or your house is on fire and you need help fixing it.

And all those other things you hear—"let's reduce dependencies," "let's improve code quality"—are just ways of trying to hit the three big goals above.

Reducing dependencies? That's to speed up delivery.

Improving quality? It keeps the maintenance bucket from overflowing.

The People Layer

But engineering management isn't all just metrics and deadlines. There's another layer they care about, even if it's not always spelled out: people.

Most engineering managers quietly worry about three things when it comes to people:

1. How do we scale the teams if needed?
   If business takes off, can we grow fast enough without chaos?

2. How can we prevent our top talent from leaving?
   Good engineers are hard to find. If you lose your best talent, delivery slows down, regardless of the processes you have in place.

3. How do we help people grow?
   Are we investing in upskilling and keeping folks engaged, or just grinding them into burnout?

Interestingly, managers closest to the teams usually care the most about these people's problems, while those further up the chain tend to become more focused on metrics. And almost nobody puts "architecture" first on their list.

Here's the trick:
If you can connect architecture decisions back to these people's concerns—such as showing how technical debt drives good developers away or how clean, maintainable systems make onboarding new hires possible—you'll suddenly find that your voice carries a lot more weight.

And just to be clear, most engineering managers aren't lying awake at night thinking about architecture. They care about business and the concerns of their people. Your job is to demonstrate how good architecture enables them to deliver faster, meet their deadlines, and spend less time cleaning up messes.

If you want to connect with engineering management, talk about how that mountain of spaghetti code makes developers leave, or how you can't hire anyone unless you clean things up. Make it real.

But What About the Business Folks?

Now, let's cross over to the business side. This is where things get both simpler and, oddly, more confusing for technical people. Business usually boils everything down to three things:

1. Growth
Businesses are often measured by the top line—total revenue, or more precisely, Annual Recurring Revenue (ARR). It's simple: if ARR isn't growing, the alarm bells go off. Investment only happens if there's growth potential.

For new businesses, 40%+ growth might be the target. For big, established players, 10% is often enough to keep everyone happy. How do you grow ARR? Mostly by selling to new customers, which is expensive (in B2B, customer acquisition can easily hit 100k per account), or by upselling existing customers, which is cheaper, but often needs tailored features or custom builds.

2. Retention
Growth means nothing if you can't keep your customers. You could grow sales by 40%, but if you lose half your revenue to churn, you're underwater. That's where Net Retained Revenue (NRR) comes in. If you start the year at $10M and lose two customers ($1M each), you'll be at $8M by year-end—an 80% retention rate, which is considered healthy. Anything below that, and the red flags start waving.

Retaining customers is much cheaper than finding new ones, so the business invests heavily in account management, support, SLAs, and quality, all aimed at keeping the revenue you already have. If your service goes down once a day, no one will renew their contract.

3. Profitability
And finally: money. Ultimately, profit is the amount that remains after all costs have been covered. But "cost" gets complicated. The costs of sales and marketing that go into replacing lost customers are just the price of staying afloat. However, the cost of acquiring new customers or investing in new features is considered an investment, not just an expense.

The same goes for engineering. That "spending profile" I mentioned earlier? The time you spend on maintenance is a cost—it eats into profit. The time spent building new features, on the other hand, is an investment that ideally leads to increased sales or happier customers.

And here's the catch: when the business doesn't see growth opportunities, it stops investing. That means they don't need more salespeople to bring in new deals or more engineers to build new features. So, when budgets are cut, it's usually the growth-oriented parts of sales and engineering that are the first to go, not because anyone has done something wrong, but simply because there's no reason to invest further if growth has stalled.

Bottom line:
Understanding how the business side views the world—growth, retention, and profitability—and determining where technology and architecture can contribute, is a core part of the architect's job. Most of the time, this means more than just delivering features; it's about finding those hidden issues and translating technical realities into business terms.

Why Should Architects Care?

So why am I telling you all this? Because your job as an architect isn't just to draw diagrams or pick technologies. It's about understanding where the pain lies—on both the engineering and business sides—and figuring out how technology can help.

Sometimes, it really is as simple as delivering what the business asked for, on time. But more often, the real issues are hiding below the surface—old systems, brittle code, processes that slow everything down. It's your job to find those problems and explain them in business terms.

If you can talk to engineering about time to market, predictability, and maintenance, and you can talk to business about growth, retention, and profitability, you'll find yourself invited to the real conversations.

And maybe, just maybe, those business guys will finally understand what we technical people actually do. But that's not certain.

Want to learn more?

🎓 Check out the course: Modeling, Viewpoints, C4
🌐 Follow us on LinkedIn: Software Architecture Guild
📖 Explore the Free Guide: Jump to Website