What decades of building taught me about outcomes, architecture and leadership

I've spent the better part of my career building things. Over a few decades, I've built and deployed hundreds of large-scale enterprise applications: social platforms, commerce platforms, fintech products, loyalty systems, each serving millions of members. Different industries, different problems, different teams.

If you'd asked me twenty years ago what I'd learned from all of that, I probably would have talked about technology. Architectures, platforms, scale. I would have been wrong, or at least incomplete. The deepest lessons didn't come from any single platform or industry. They came from the contrast between how different organizations actually operate, and from being wrong enough times to eventually understand what actually works.

What startup DNA really means

Some of the most formative years of my career were spent leading an Israeli startup in Herzliya, where we scaled from 25 people to over 150. I'd worked in large enterprises before that, and I thought I understood how organizations functioned. The team in Herzliya taught me I didn't, not really.

The difference showed up first in how people approached problems. At the startup, everyone, not just leadership, demanded to understand the core nature of whatever we were working on. Not the pitch, not the roadmap slide. The actual mechanics of the problem, with a relentless pursuit of the outcome we were chasing. In enterprise environments, I'd more often seen people optimize for understanding the vision well enough to satisfy whoever they reported to. Those sound similar. They are not the same thing.

It showed up in how we talked to each other, too. Debates at the startup were direct. People stripped out the fluff and got to the point, sometimes bluntly. In enterprise settings, I'd learned to navigate conversations carefully, choosing words with an eye toward who might be listening, who might be offended, who needed to be managed politically. That instinct doesn't disappear overnight, and I'll admit it took me time to unlearn it enough to actually thrive in a room where directness was the norm and not a risk.

Urgency was the other thing that struck me. At the startup, speed wasn't a value statement. It was survival. If we moved too slowly, we didn't get a second quarter to fix it. In a lot of enterprise environments, I've seen urgency that's more performative than real: moving fast in the ways that are visible, while the things that actually matter drift for months.

And trust, I learned, was never given for personality or title. It was proven, entirely, by results. You could be the most likable person in the room and still not be trusted with the next hard problem until you'd shown you could deliver on the last one. That's a harder standard to live by, but a fairer one, and I came to prefer it.

The hardest part wasn't any single one of these lessons. It was scaling the company from 25 to over 150 people without losing that culture. I won't pretend I solved that cleanly. It's one of the genuinely difficult problems in building something, and every leader I respect who's grown a team through that range has scars to show for it, not a playbook. What I can say is that I love that team still, and that Herzliya is where I actually learned what startup DNA means. Not as a phrase people put on a slide, but as something I lived inside of for years.

Outcomes, not just outputs

One lesson from that period has stuck with me more than any other: the difference between outputs and outcomes.

Outputs are visible motion. Features shipped. Tickets closed. Roadmaps updated with green checkmarks. In enterprise environments especially, outputs are dangerously easy to manufacture. There is almost always enough busy work available to make a team look productive, regardless of whether any of it moves the business forward.

Outcomes are a different question entirely: did anything actually change? Did the metric the business cared about move? Did the customer's experience genuinely improve?

I've watched smart, hardworking teams become quietly addicted to features for their own sake, proud of what they'd built, without a clear-eyed view of what objective that feature was ever supposed to serve. It's not a failure of effort. It's a failure of focus, and it's one of the easiest traps to fall into in a large organization, because the org chart rewards visible output long before anyone circles back to check whether it produced a real result.

Startups don't have that luxury. When resources are tight and the runway is finite, the gap between outputs and outcomes gets exposed fast. That's part of what Herzliya burned into me: the discipline of asking constantly, whether what we were building was actually moving something that mattered, not just something that looked good in a status update.

I bring the same question to warranty claims. Software going live is an output. The outcomes our customers care about are three numbers: severity, cost to serve and cycle time. If those don't move, the deployment didn't work, whatever the status report says. I wrote more about that gap in Pilots are easy. Outcomes are hard.

Architecture is a first decision, not an afterthought

Ideas are cheap. Everyone has one. What's genuinely rare is knowing how to construct the architecture that turns an idea into an outcome, and that has to be a first-order consideration, not something bolted on after the "real" business decisions have already been made.

Too often, architecture gets treated as an implementation detail the technical team sorts out once the strategy is locked. That order is backwards. Architecture and business objectives need to be worked together from day one, because the constraints of one shape what's achievable in the other. A brilliant strategy on the wrong architecture doesn't produce a brilliant outcome. It produces a slow, expensive lesson. I learned that one firsthand.

One nuance I'd add, because it's easy to get wrong in the other direction: there is almost never exactly one right architecture. The job isn't to find the answer. It's to make a deliberate, well-reasoned choice among several valid paths, and to understand the tradeoffs well enough to defend that choice when it's questioned. The people I respect most in this discipline aren't the ones who claim certainty. They're the ones who can clearly explain why they chose one valid path over another.

Leadership isn't overrated, but it's taught backwards

I don't think leadership is overrated. I do think it's taught, when it's taught at all, in the wrong order, and usually only partially.

There are three distinct dimensions to it, and I wish someone had explained this to me clearly, early, instead of letting me figure it out through trial and error.

Leading a team. This is the dimension most people are actually promoted for. You show you can lead a group of people to a result, and the organization rewards that by giving you more people to lead. It's the most visible skill, the one every leadership book is written about, and understandably so. It's foundational.

Uniting and collaborating with your peers. This one gets far less attention, and it's arguably harder. In any large organization, getting things done requires working across the aisle: securing support from peers who have their own priorities, their own incentives, and sometimes their own egos. This is where politics genuinely lives, and it demands a different kind of patience and care than leading your own team ever did. You can't manage peers the way you manage direct reports. You have to earn cooperation without the authority to compel it.

Managing up. This is the one nobody taught me, and the one I treated as an afterthought for years longer than I should have. Managing up is its own discipline: understanding that the leaders above you have limited time and attention, and that part of your job is prioritizing the things that connect to what they actually care about. That doesn't mean other priorities stop mattering. It means learning to sequence and frame what you bring forward, so the most important things actually land instead of getting lost in the noise of everything else that's also true and also important.

Here's why I call it backwards. Most development programs start with your team and get to peers and managing up last, if they get there at all. In my experience, those last two decide whether your team's work lands. A great team whose priorities never reach the right desk still ends up shipping outputs, not outcomes.

These three dimensions also don't scale with title. Being excellent at leading a team doesn't make you good at collaborating with peers, and being good at both doesn't make you skilled at managing up. Each one has to be learned on its own, often the hard way.

What it all adds up to

If I had to boil down a few decades of building into a single idea, it's this: outcomes over outputs, architecture as a first-class citizen, and leadership as three distinct disciplines all trace back to the same root. None of it works without the right people, the right culture, and the right DNA.

I've watched the same architecture succeed on one team and fail on another, and the difference was never the technology. It was who was in the room, what they believed mattered, and whether the culture around them rewarded outcomes or just rewarded looking busy. Get the people, culture, and DNA right as you scale, and the rest becomes achievable. Get any of them wrong, and no amount of process or architecture will save you.

None of this is a framework I read in a book and adopted. It's what I learned by living inside very different organizational cultures, enterprise and startup, large team and small, and getting enough of it wrong to eventually get some of it right. It's still being refined, honestly, every time I'm in a room with a new team or a new problem.

At Polygrade, this is the lens I bring to the work every day: my experience, the lessons learned along the way, a return to first principles when the path forward isn't obvious, and an unwavering focus on getting the people, the culture and the DNA right. Everything else follows from that.

It's also how we deploy. Every Polygrade customer works with a forward deployed engineer who is accountable for outcomes, not go-live dates. If you're weighing where AI would move severity, cost to serve and cycle time in your claims operation, we'll run an analysis on your historical claims and show you, stage by stage.