How to build an AI native engineering org: what we actually did

In March we restructured Monte Carlo’s engineering organization. As I’ve thought about sharing our decision-making process, I’ve wanted to be far enough past the restructure to say something honest, objective, and which other engineering leaders can hopefully find useful.

The short version is that our teams and operating principles weren’t broken, which made it particularly hard. But we weren’t future proofed. And, as the agentic wave comes barreling towards us, we couldn’t risk being functional for today. We had to be ready to operate in a new world order, even before it came for us.

The problem with doing the right things

“Change before you have to” is what Jack Welch, General Electric CEO and one of the most studied business leaders, said. That is a painful yet necessary reality to running a sustainable team – whether engineering, marketing, or anything else.

Monte Carlo was performing well by most conventional engineering measures before we restructured. We delivered on our product roadmap goals consistently and had mature quality control and reliability processes. We had a team that knew well how to ship a complex enterprise product.

The problem, in our case, was that we were executing a playbook built for a different era — one where specialization was the only path to scale, where larger teams meant more coverage, and where careful orchestration of handoffs was necessary because no individual could hold the whole problem in their head.

AI changes all of that. We’ve reached a stage where a PM can ship a working prototype without engineering support and a sales engineer can build a new customer integration without waiting for a sprint. In this rapid-fire world, the old model is inefficient and leaves opportunity on the table.

We needed to rebuild for that opportunity from a position of strength. We essentially changed before we had to.

This is what becoming AI-native looked like for our engineering org.

We ruthlessly flattened the org

Most engineering leaders I talk to have tried to flatten their org at some point. One commonality I’ve noticed among those who have not succeeded in doing so is that they removed the layers, but everything got slower, not faster. People started making decisions that didn’t fit the broader picture, priorities drifted, and the org fragmented quietly. Eventually the layers came back.

The standard diagnosis for why this happens is culture. We talk about how people are not “ready” for it, or that there is resistance from middle management layers. However, I think those are symptoms of a more fundamental problem that does not get named directly: management layers are an information system. Yes, managers exist for coordination, but a huge part of their role is also information dissemination. They keep people aligned on the core priorities, pass down customer feedback, and act as collaborators across different departments.

When you remove management layers, you don’t just change the reporting structure, but you also remove all of that critical context and knowledge sharing. The information that used to flow through those layers doesn’t find another path — it just stops flowing. Engineers are now autonomous, which sounds great, but they’re autonomous on incomplete information. They make decisions quickly, but the decisions are locally optimized. Flat orgs often end up re-adding layers for this reason.

This time it will be different

How many times have we heard that phrase before, eh? In my team’s case, I was truly committed to making the organizational shift different, better, and lasting. This time, there was really something to make it different in a meaningful way from the get-go: AI.

When we restructured Monte Carlo’s engineering org, we went genuinely flat. We built mini-squads with no management layers between functional leads and the people building. Everyone, including me, became hyper-focused on delivering value directly to customers.

What enabled us to solve the information sharing problem seriously this time around was having AI.

AI streamlined, magnified, and optimized nearly everything we were able to do before relying on humans. Customer feedback could be synthesized and routed directly to the engineers who needed it, project statuses could be visible across every squad without a standup, and the cross-team context that used to exist only in the heads of people with the right relationships now became available to everyone, continuously, at zero marginal cost.

The information work that managers used to do manually can now be done by systems. We are not constrained by typical resources to ensure that information is complete, current, and reaches everyone that it needs to reach.

We created an Engineering Effectiveness function to help with this. Its job is team health, operational noise reduction, and building the AI-powered information flows that replace what managers used to do manually. It is the connective tissue that makes a flat org coherent.

Making AI non-optional

Across the organization at Monte Carlo, we went “all in” on AI. It became the imperative that everyone had to use AI more across their daily work. But what does “use AI more” actually mean, particularly in an engineering context? There are so many tools, processes, and risks – and little to no “best practices” in this regard. We had to build the plane as we were flying it.

What worked for us was to be specific. Meaningful, substantive use of AI across engineering meant a radical transformation in how each role operated. For one thing, we got rid of framing roles as “specialists.” We do not see team members as strictly backend or frontend engineers, or even product managers. The incredible thing about AI is that it lets you lean into your core strengths while removing your dependency on adjacent domains, so the boundaries of your expertise are not so rigid anymore – definitely not rigid enough to stop you from building what you envision.

Possibly the most radical thing I said to the engineering org on day one of the transformation: stop writing code.

This is quite a startling imperative; as engineers that is so core to our training, our interests, and our day-to-day. What I meant by that, however, was not so extreme as to say “never write code again,” but rather, writing code should not be your default approach to building. Your default should be to direct AI to write the code, not to write it yourself.

The elements of engineering work that really require human judgment, experience, and creativity are where we should be spending our time — debugging hard problems, architecture decisions, and new feature ideation. The engineers thriving in this new model actually feel quite liberated, as they are no longer buried under the mechanical work of writing every line themselves.

And our early results have been really good so far: PRs are up 73% with 25% less headcount.

Standardization isn’t bureaucracy

One of the key challenges to making a sustained AI initiative is ruthless standardization. When you don’t have it, every engineer inevitably figures out their own setup, approach, and tooling configuration. After all, engineers are wired to solve problems — and they will solve for what they need.

This is not scalable, though, and the issues with individual configurations for every AI use case compounds inconsistencies, which slows down the work. Plus, the people most ready to embrace the change feel like they have to figure everything out on their own. This is not fair, and it’s not good leadership.

We mitigated this by investing early in standardization; shared setups, agent toolkits, and common skill libraries were built. The goal was to make the starting point as easy as possible so that those who were ready and willing weren’t taxed by the startup cost, and also so that we did not have a million versions of a protocol floating around.

Sometimes standards and processes can feel like bureaucracy, especially when people just want to get in and build something. In this context, they were what let us scale autonomy among our engineering team, and this was critical considering what we were asking everyone to do.

What I got wrong

Transformation is hard, and doing so in a rapidly changing environment is especially so. There are definitely things I got wrong, and I learn from these every day.

Initially, I thought of flattening the org as primarily an autonomy problem. People need smaller, more nimble squads with fewer gates and more trust. Of course, we would all move faster! This was partially true, but I underestimated the information problem considerably.

People can only make good decisions with the information they have. When you remove management layers without replacing the information flows, you force engineers to operate on incomplete context. People end up moving fast in the wrong direction, and there are huge bottlenecks and frustration that comes with that. For us, the fix here required building the systems that do what managers did with information, only continuously, at the speed of computers, and at zero marginal cost.

Once that information layer was in place, we could see autonomy thriving across the organization. People could see the end goals and overarching strategy clearly enough to figure out how to solve their specific problems themselves.

Why now

Executing on a complete organizational overhaul is hard and scary; you will meet resistance and people will leave. But now, having gotten through the most difficult parts of it, I am confident that activating transformation from a position of strength was absolutely the right call.

The AI world moves fast. It’s ruthless, and it does not wait for you to be “ready.” I very much believe that the companies that will define the next era of this industry are making these bets now, before they are truly forced as a reaction to crisis.

Our promise: we will show you the product.