Business Model ≠ Engineering Culture

There’s a belief that quietly shapes how people choose where to work. It goes something like this: “Product companies are where real engineering happens. Service companies are where you survive.”

Where the myth comes from

The logic feels intuitive. In a service company, you’re executing someone else’s vision, someone else’s product, someone else’s deadlines. How good could the culture really be?

Product companies, on the other hand, own the thing they’re building. Surely that breeds craftsmanship, ownership, discipline?

When something frustrates you in your current service company — the processes, the communication, the quality bar — it’s easy to attribute it to the company type. And then you start looking. Looking for a product company.

What actually happens when you find one

You join. You’re excited. And then, somewhere in the first few weeks, the facepalms start.

That was my experience. I’ve worked in both service and product environments with strong engineering practices — and in both with weak ones. But the sharpest lesson came when I moved from a service company I respected into a product company I had idealized.

What I found:

No code review process. Code went in, nobody looked at it twice. Not because people didn’t care — it just wasn’t a thing. There were no ownership of the code that is shipped. And devs continuously were busy. In addition to that there were few if any unit tests”.
No defect management. Bugs existed, but there was no structured way to track, prioritize, or learn from them. Issues were written as a comment to the user story. And thats all what were done with them.
No retrospectives. Problems weren’t discussed because there was no space to discuss them. The retrospective format simply didn’t exist. So the same issues repeated. Sometimes it getting worse: the team had retrospective, but no action points were executed after it. So the team gave up.

Meanwhile, I kept thinking: “We had all of this in my previous service company. And it was good.”

Why service companies often develop stronger practices

It took me a while to understand the mechanism.

In a service company, the quality of your work is directly tied to whether the client pays. Not abstractly — literally. If your delivery is poor, the contract is at risk. That creates a different kind of pressure: one that forces you to develop risk management, track metrics, and build communication norms that actually work.

The team interactions I experienced in service work were more deliberate. Feedback loops were tighter. Quality wasn’t a nice-to-have — it was a survival mechanism.

That doesn’t mean every service company is a model of excellence. It isn’t. But the business model itself doesn’t determine the culture — the people and the systems they build do.

What actually predicts engineering culture

Culture isn’t a feature of the company type. It’s a feature of the people inside it.

A product company can have zero code review and no psychological safety to raise problems.
A service company can have mature engineering practices, strong mentorship, and a team that genuinely cares about craft.
And vice versa — in both directions.

The business model tells you how the company makes money. It tells you almost nothing about how the team operates, how problems get surfaced, or how seriously quality is taken.

What to actually look for when choosing where to work

Stop optimizing for “product vs. service.” Start asking better questions:

Talk to people on the team — not just the recruiter. How do they describe their day-to-day? Do they mention processes, or just outcomes?
Ask about specific practices. Not “do you do code review?” but “how does your code review process work?” The detail in the answer tells you everything.
Read reviews — critically. Glassdoor, DOU, LinkedIn. Look for patterns across multiple sources, not just one or two complaints.
Ask what happens when something goes wrong. How are bugs handled? What happens after a bad release? The answer reveals the real culture more than any job description.

These questions apply whether you’re evaluating an outsourcing firm or a late-stage startup.

The honest takeaway

The grass isn’t greener on the product side. Or the service side. The grass is greener where people are deliberate about building good practices — and where you’re willing to look past the label to find out if that’s actually happening.

Next time you’re considering a move, slow down on the category and go deeper on the specifics. The type of company is the least predictive thing about what it’ll actually be like to work there.

If you want to push back on this — I’m on LinkedIn.