In 2024 I created the LEAD podcast with my good friend Geert van der Cruijsen. In this podcast we explored the various aspects of building an engineering culture. We made quite some episodes. With guests and without guests. And I thought it would be a great idea to share some of these stories combined with my insights from these episodes on this blog. All credits do not go to me. They go to Geert as well, and to our guests. And of course to Xebia, the company I work for, for making this possible.

---

In this episode, Geert and I invited Harald, co-founder and CTO of Atlas, to talk about how you build an engineering culture when you’re just starting out. Because it’s one thing to optimize culture and process in a large organization with plenty of resources. But what do you do when you’re a six-person startup with limited time, budget, and people?

Harald’s story was insightful because it showed how some principles scale down very well, and others need to be stripped back to the bare essentials.

Start Lean, Stay Product-Oriented

When Atlas got started, they had nothing but an idea and a few people. In those early days, you simply can’t afford heavy processes. Harald made it clear: minimize processes to what is absolutely necessary. You need code reviews, you need some testing, but most synchronization processes that larger companies rely on can be skipped if you make sure everyone stays aligned in other ways.

Their way of doing that was simple but powerful: everyone in the company is product-focused. Even deeply technical people are expected to engage with customer feedback, understand how their work affects the customer experience, and use the product themselves. One thing I loved was how they run internal challenges to build the coolest maps with their own tool. This keeps everyone engaged with the product, not just the code.

The Balancing Act: Prioritization and Tradeoffs

In startups, you are always playing a game of 90-10. You need to get 90% of the value with 10% of the effort, whether it is in security, performance, or feature development. Harald shared how difficult it is to balance all these priorities, especially when you have engineers who, by nature, want to optimize and perfect things. Sometimes you simply have to let go, accept good enough, and move on.

For deciding what to build next, they use a simple but effective framework: plot features on a two-axis chart of effort vs. business value. If you cannot confidently place a feature on this chart, it is a sign that you need more research, more customer input, or better technical understanding. It’s not fancy, but it works.

Scaling Without Breaking the Culture

As they prepare to scale, Harald is very aware of the coming challenges. Up to around 12 people, you can still work like a single team. Beyond that, you need middle management, more structure, and you risk losing some of the cultural magic that makes early-stage startups fun and effective. The plan is to grow cautiously, building a small but highly skilled team first, and only scaling up when necessary.

What I found refreshing is how they balance hiring senior “Navy SEAL” engineers who can thrive in ambiguity, with also giving room for junior people to grow. Juniors are given slightly bigger challenges than they think they can handle, which allows them to stretch, learn, and grow into bigger roles.

Trust and True Ownership

Trust is the foundation of their culture. New team members get responsibility early. They can deploy to production after a few weeks. If something breaks, they are responsible for fixing it. But Harald is also clear: this is not about blaming individuals. It’s about creating a team culture where everyone feels ownership, but where mistakes are learning moments, not finger-pointing exercises.

This is DevOps at its core: you build it, you run it, you own it. Not as a slogan, but as a lived reality.

Architecture as a Scaling Tool

When we talked about knowledge sharing, Harald made a great point: good architecture helps here. A well-structured system with clear separations of responsibility makes it easier for people to work independently and lowers the need for constant knowledge transfer. They are not going for microservices just for the sake of it, but aim for a handful of clear, understandable services.

This allows them to grow without making the system too complex to manage or understand.

The 90-10 Rule: Not Just for Engineering

One of the broader lessons Harald shared is how the 90-10 principle applies not only to software, but to life. Whether it’s reading, working out, or eating healthy, finding the small changes that deliver the biggest benefits helps you go far without burning out. It is about being pragmatic, focused, and accepting that perfection is rarely necessary.

That mindset is probably one of the reasons Atlas has been able to move so fast. Their customers see new features on almost every login. Bugs get fixed quickly. And the pace itself creates goodwill with customers, because they see continuous improvement.

For anyone building teams, whether in a startup or in a larger organization, there is a lot to learn here. Keep it simple. Stay close to your customer. Build trust. Prioritize relentlessly. And empower your people to own what they build.

The original Episode

If you want to listen to the original episode, you can listen to this