Good Engineering Isn't the Point

"Don't fuck up the product."

I was sitting across the table from Scott Scherr, the founder and CEO of Ultimate Software, sharing a drink when he gave me that advice. It wasn't particularly eloquent, and it certainly wasn't the kind of carefully polished corporate messaging you'd expect from the leader of a successful enterprise software company. But Scott had a way of cutting through the noise, and those five words have stayed with me long after my time at Ultimate.

At first glance, the message seemed obvious. Ultimate developed payroll and human resources software, and I was an engineer responsible for helping build it. Of course the product mattered. Customers depended on it, the company sold it, and businesses trusted it with some of their most critical operations. Building reliable software wasn't merely a professional aspiration. It was a fundamental obligation.

But there was something fundamentally different about Ultimate Software, something that Scott understood better than anyone.

Despite its name, Ultimate Software was never really a software company. It was a service company that happened to build software. Exceptional customer service wasn't a department, a marketing slogan, or an additional benefit included with the product. It was the company's defining characteristic. Ultimate had built its reputation on a level of service that helped redefine what customers could expect from an enterprise software provider. The software was how Ultimate delivered that experience, but the relationship was what made the company extraordinary.

That distinction gave Scott's warning an entirely different meaning. He wasn't telling me that software quality was the company's highest objective. He was reminding me that the product was the foundation upon which everything else depended. Customers could forgive a missing feature or an interface that wasn't particularly elegant. What they couldn't forgive was a failure that undermined the trust they had placed in Ultimate to run their payroll and support their employees. The product didn't need to be the most innovative software in the market. It needed to uphold the promise that made customers choose Ultimate in the first place.

Scott knew what business he was in. And perhaps more importantly, he made sure the people responsible for building his software understood it too.

When Good Engineering Becomes the Objective

Years later, when I joined a lending company, I found myself thinking about that conversation. I spent my early days listening to engineers and technology leaders, trying to understand their frustrations and what they believed needed to change. Again and again, the concerns centered on what the business wasn't doing for engineering. There wasn't enough investment in technology, enough time to address architectural problems, or enough appreciation for what it took to practice good engineering. Many of those concerns were legitimate. But what struck me was how rarely the conversations began with what the business actually needed.

We were a company whose economic engine depended on originating and selling loans. Yet many of the engineers I met understood little about that engine. At best, they understood the business line their applications supported. At worst, their understanding stopped at the software itself. They could explain why a system needed modernization without explaining how that modernization would improve the business. They could articulate the benefits of better engineering practices without connecting those benefits to the company's success.

The contrast with Scott was difficult to ignore. At Ultimate, the founder of a software company had taught me that software wasn't the main thing. At a lending company, I was encountering engineers who had made good engineering the main thing. And the responsibility for that disconnect didn't belong to the engineers. It belonged to those of us responsible for leading them.

That doesn't mean their concerns were misplaced. I've spent enough of my career dealing with aging systems, architectural compromises, and short-term thinking to know that engineering quality deserves serious investment. But there is a difference between believing something is good engineering and understanding why it is good for the business. The former is a professional judgment. The latter requires knowledge of the company, its customers, its economics, and the consequences of getting something wrong.

Consider a team advocating for modernization. The technical argument might be compelling. The system is difficult to maintain, deployments are painful, and the architecture no longer reflects how anyone would design it today. But those observations alone don't establish whether modernization should be the company's next major investment. Perhaps the system is preventing new products from launching. Perhaps its operating costs are consuming resources better spent elsewhere. Or perhaps the system is ugly, inconvenient, and perfectly capable of supporting the business for another five years. The right decision depends on understanding the business, not merely evaluating the technology.

Engineering leadership has to be more than an advocate for engineering. Sometimes that means challenging the business to invest in something customers will never see. Other times it means telling our own engineers that an improvement they desperately want isn't particularly important right now. Neither decision can be made well if our understanding of the company ends at the boundaries of the systems we manage.

Keeping the Main Thing the Main Thing

Pat Riley is associated with a deceptively simple piece of advice: "Keep the main thing the main thing." It's a phrase I've returned to throughout my career because it captures something essential about leadership without requiring a complicated framework. But it also contains an assumption that deserves more attention. Before an organization can keep the main thing the main thing, someone has to understand what the main thing actually is.

Most companies can describe what they sell, but what they sell and what makes them successful aren't necessarily the same thing. Ultimate sold payroll and human resources software, but exceptional service and enduring customer relationships were central to its identity. My current company originates loans, but its success depends on an interconnected collection of capabilities that allow those loans to be originated, sold, and serviced effectively. Understanding the main thing means understanding those relationships, not simply memorizing a mission statement or knowing which department generates revenue.

And that understanding cannot remain confined to the executive team. One of the easiest ways to create an organization that struggles with alignment is to reserve strategic context for leaders while giving engineers only the requirements necessary to complete their assigned work. We tell them what to build, occasionally explain who requested it, and then evaluate their performance based on how efficiently they deliver. When they make decisions that optimize for technical convenience rather than business outcomes, we wonder why they aren't thinking more strategically.

But strategic thinking requires strategic context. An engineer who understands how the company makes money, why customers choose it, and what threatens its success can make better decisions without waiting for someone else to interpret every situation. That knowledge doesn't replace technical expertise. It gives technical expertise direction.

What Scrum Got Right

For all the criticism I've directed at Scrum, I think one of its greatest contributions was its insistence that teams organize around an objective. The Sprint Goal, when Scrum was practiced thoughtfully, represented something more meaningful than a collection of stories to complete before the next planning meeting. It established what the team was trying to accomplish and gave engineers a basis for deciding how to accomplish it.

A team organized entirely around completing tasks has little reason to question whether those tasks remain necessary. Its success is measured by delivery against a plan. A team organized around an objective can recognize when the plan needs to change, when an alternative solution might be more effective, or when additional work would contribute little to the desired outcome. The objective provides continuity even when the implementation changes.

Of course, Scrum had its own difficulty keeping the main thing the main thing. Organizations became preoccupied with velocity, sprint commitments, ceremonies, and whether teams were following the framework correctly. The methodology that was supposed to create focus sometimes became the focus itself. Teams could deliver every story, satisfy every procedural expectation, and still accomplish remarkably little that mattered to the business.

I've argued before that AI is making many of Scrum's rigid structures increasingly difficult to justify. I still believe that. But its emphasis on shared objectives is becoming more important than ever. We may no longer need to organize every development effort into fixed two-week increments, but engineers still need to understand what they're trying to accomplish and why it matters.

The limitation is that a Sprint Goal can only provide so much context. It might explain what a team needs to achieve this week, but it doesn't necessarily explain how the company makes money or why that outcome deserves priority. A team can understand its Sprint Goal perfectly while remaining almost entirely ignorant of the business it serves. Scrum offered a mechanism for connecting engineers to an objective. Engineering leadership still has to connect that objective to the business.

AI Is Raising the Stakes

For most of software engineering's history, building software was expensive enough to impose a natural constraint on how much an organization could attempt. Engineering teams had limited capacity, projects required substantial coordination, and even modest changes could consume weeks of effort. That scarcity forced organizations to make choices, although it certainly didn't guarantee they made good ones.

AI is beginning to change that relationship. Tasks that once consumed days can increasingly be completed in hours, and work that previously required extensive manual implementation can now be accelerated through intelligent tooling. Difficult problems remain, and engineering expertise hasn't disappeared. But the cost of producing software is falling, and the amount of work an individual engineer can initiate and complete is growing.

That's an extraordinary opportunity for organizations that understand what they need. It's also a potentially expensive distraction for those that don't.

An engineer who doesn't understand the business can now produce more software without necessarily producing more value. An organization that mistakes technical modernization for business progress can pursue that modernization more aggressively than ever before. AI doesn't resolve the disconnect between engineering activity and business outcomes. It can amplify it, allowing teams to move faster in directions that were never particularly valuable.

AI is also changing where human judgment becomes essential. When writing code required most of an engineer's time, much of the profession naturally revolved around implementation. As AI assumes more of that work, engineers increasingly become responsible for defining problems, evaluating solutions, establishing constraints, and determining whether the result is appropriate. Those responsibilities require more than knowing how software should behave. They require understanding the environment in which it operates and the consequences of getting it wrong.

I think back to Scott's warning. An AI coding agent can help build payroll functionality, generate tests, and identify implementation defects. But technical requirements alone may not communicate why certain failures would be catastrophic to the customer relationship. An engineer who understands Ultimate's service-centered business model knows that reliability isn't simply another quality attribute to balance against delivery speed. It's part of the promise the company has made to its customers. That knowledge influences what the engineer asks AI to build, how the result is evaluated, and which risks are acceptable.

AI can work with that context. It can help reason about it and incorporate it into the development process. But someone has to recognize its importance and provide it in the first place.

We've invested heavily in teaching technical skills, introducing new tools, and improving engineering productivity. Those investments still matter. But as AI makes execution less expensive, the value of understanding what should be executed increases. An engineer who knows the business can use AI to explore better solutions, identify opportunities, and challenge assumptions. An engineer who only understands the ticket can use AI to complete the ticket faster.

Both may produce working software. Only one is consistently positioned to help the company make better decisions.

The Main Thing Is a Leadership Responsibility

There's a temptation to treat business understanding as something engineers will naturally acquire through experience. Spend enough years working on a system, attend enough stakeholder meetings, and eventually the larger picture will become clear. Sometimes that happens. More often, engineers become exceptionally knowledgeable about the narrow part of the business they encounter every day while remaining disconnected from everything surrounding it.

We reinforce that limitation through the way we organize teams. We assign engineers to applications, surround them with technical problems, and provide them with backlogs prepared by people who supposedly understand the business on their behalf. Then we ask them to demonstrate ownership, initiative, and strategic thinking. We want them to make decisions as though they understand the company, while structuring their work in ways that make understanding the company largely optional.

Changing that requires more than inviting engineers to an occasional business presentation. Leaders need to explain how the company generates revenue, what drives its costs, why customers stay or leave, and how different parts of the organization depend on one another. They need to connect technical investments to the opportunities those investments create and the risks they reduce. And they need to create an environment where engineers can question not only how something should be built, but whether building it is the right thing to do.

None of this diminishes the importance of good engineering. If anything, it strengthens the case for it. The most persuasive argument for reliability isn't that reliable systems are professionally admirable. It's that unreliable systems can undermine customer trust, disrupt operations, and threaten the economics of the business. The strongest argument for maintainable architecture isn't that engineers prefer clean code. It's that the ability to change software safely and efficiently can determine how quickly a company responds to new opportunities.

Those connections are not always obvious, and sometimes the benefits of engineering investments are difficult to quantify. That's precisely why leaders need to understand the business well enough to make the argument. We shouldn't expect executives to prioritize engineering practices simply because engineers consider them important. We should be able to explain what the business gains, what it risks, and why the investment deserves attention.

When I think about Scott Scherr, I remember a leader who understood exactly what made his company extraordinary and was willing to explain it in terms an engineer could never forget. When I think about my early experiences at my current company, I remember talented engineers who had learned to advocate for good engineering without necessarily understanding the larger business those practices were meant to support.

The difference wasn't technical ability. It was context, and whether leadership had made that context available.

Pat Riley's advice to keep the main thing the main thing remains as relevant as ever. But for engineering leaders, there's a responsibility buried inside those words. It's not enough for us to know what matters. We have to make sure the people making thousands of technical decisions throughout our organizations understand it as well.

For decades, we've worked to make engineers better at building software. We've developed new languages, frameworks, methodologies, and tools, all intended to increase what engineering organizations can accomplish. Now AI is accelerating that progress in ways that may fundamentally change how software is developed.

But the ability to build more software has never guaranteed the ability to create more value. That depends on understanding the business, recognizing what makes it successful, and knowing what it cannot afford to lose.

Scott knew. And he made sure I knew.

Because AI is about to make us extraordinarily good at building things. We had better be equally good at understanding why.