This website uses cookies

Read our Privacy policy and Terms of use for more information.

Becoming a 10x organisation

In part one, we showed how to set the foundation for the whole organisation to use AI well (the data, the context, the person leading it). But even when you get this part right, big change may be slow because the people in your organisation haven’t changed how they work.

That's the hardest part of any AI transformation: getting teams to engage with it and actually adopt it. In part two, we cover how we've approached that at Firmable.

When we started bringing AI and automation across the business, there was naturally a fair bit of anxiety. It’s a big change, and many people don’t know how their role fits into this future or how they’ll need to change themselves. As leaders, our job was to work out who was able and willing to make the transition, how to support them, and how each role would change as AI became part of the work.

When founders first think about getting their team to use AI, many jump to getting as many people as possible to vibe-code solutions. But if everyone in the business were building AI applications, nothing would actually get done.

That said, people who aren't willing to use AI in their day-to-day don't last here.

So the question isn’t how to turn everyone into a builder. It's working out which roles need to optimise themselves and which roles get optimised for them.

How roles change

Some roles are managed from above. An SDR doesn't need to rebuild their own workflow. They need to be AI-curious, and their manager and a small group of builders optimise the role for them.

Other roles have no one above them to do it. A head of finance or a head of marketing has to actively redesign and automate their own job because nobody else understands it well enough to.

Which starts with being clear about what a builder actually is.

What is a builder?

A builder in your organisation in the era of AI should be made up of two things:

  1. A systems thinker.

  2. Someone comfortable enough with AI to execute on building the thing.

The latter can be taught, but the former is largely down to how the person sees the world. A systems thinker is someone who can look at how work moves through the business and see a system rather than a series of disconnected individual tasks. They understand how their team fits into the wider business and connects with other teams.

Take someone running a podcast. Using ChatGPT to research each guest is fine. That's good. Great looks like building a full guest-intake system: research, briefing notes, question drafts and follow-ups that run the same way every episode, and that anyone else on the team could pick up.

This doesn’t mean they’re necessarily super technical. AI has lowered the barrier to entry for this, but they still need the attributes and knowledge of their domain. Marketing still needs creativity and taste. We’re not asking a marketer to become an engineer. We’re asking whether they can see the repeatable machine underneath it.

The gap between good and great is now 10x

Five years ago, the gap between a good operator and a great one in most roles was maybe 1–2x. In AI-native roles, it's closer to 10x.

That changes the question leaders should be asking. The tempting one is "Is this person getting more productive with AI?" Almost everyone is a little. The better question is, "Would an AI-native person in this seat be doing 10x what this person is doing?" If the answer is yes, a personal productivity bump won't close the gap.

The size of that gap isn't the same everywhere. In an SDR team, the step-change for any one rep is limited, and most of the gain comes from the system built around them. In marketing and finance, the difference between someone who has rebuilt their role around AI and someone who hasn't is dramatic.

Here's how that plays out across four of our functions.

Function by function

Sales

When you have a small sales team, each rep and their manager can carry an exceptionally high amount of context about multiple prospects and deals at once. The sales manager of a 5-person team, through weekly 1:1s, probably has a good sense of the logos in the pipeline, which prospects are stalling, which deals need more support, and which rep needs to refresh their pipeline to start new conversations.

But once you have 10, 15 or more reps across multiple territories, no single sales leader can keep track of that context. It stops being a management problem and becomes a system problem.

The job for our sales development reps (SDRs) is to have as many conversations as possible with qualified prospects, with the end goal of booking sales demos. Sales is ultimately a numbers game: the more of these conversations they have, the more meetings they book.

Good AI automation here was to build a team-wide system that ensured they were calling the right companies at the right time, with the right context, so they could have as many high-quality conversations as possible. It definitely wasn’t to get reps vibe-coding themselves personalised solutions.

We built an internal AI app that scores accounts, allocates them weekly across our SDR team and refreshes the list frequently. A rep just needs to open their list of 50 companies to call. They don’t have to think about which ones or spend time finding them.

None of that requires a rep to be a builder. They need to be AI-curious and understand that the list is in their best interest and that spending more time reaching out to prospects will help them hit and beat their targets.

The builders sit alongside them. In go-to-market, we’ve ended up with something that looks like an internal applied AI team: builders who can sit with the SDRs, understand the actual problem that can be automated (these accounts are in timeout, these accounts are due a callback), and then go and build that process. You need both a small number of systems-thinking builders and functional operators doing the job.

Our sales team will scale linearly with the business (see our GTM engine article), and this app scales with it. Every new rep who joins the team starts using this AI app on day one.

Finance

Not every team should scale linearly with headcount the way sales does. Finance is a good example. We don’t expect finance headcount to grow in step with the business scaling.

Finance is the opposite of sales. There's no builder team sitting alongside it. Each person in finance has to optimise their own world by building repeatable, automated systems with AI. We started with smaller tasks like monthly consolidation and gave our finance leaders access to the data lake for quicker and more comprehensive reporting.

On the horizon is a major effort to change our ERP tool to something that integrates with our other tools and data lake.

If you’re leading a finance function and not automating things now, you don’t have a future in a finance team, ours or anyone’s.

Engineering and product

Engineering was furthest ahead when we started because shared systems and shared standards were already part of a good engineering culture, and AI coding tools had been widely adopted.

But even where adoption was furthest ahead, the roles themselves are changing faster than we were able to keep up with.

Not all engineers are the same anymore. One engineer who can direct a group of agents is doing something categorically different from one writing code well, and only a small percentage are there (that’s the 10x gap again). Product function is similar. How you create product now is not how you created product three years ago.

We have a product designer who’s a great example. He used to live in Figma, just working on designs with multiple rounds of review with engineers.

He has completely reinvented himself as a design engineer, a role that didn’t exist on our team before. Now, an idea goes straight into a working prototype in our codebase, with an app that reviews the copy, the language, and the colours, which was the bulk of the time he spent in his old role. This app can be used by anyone else in the product and engineering team.

Engineers get something that works instantly and publish it, or something that is mostly complete and just needs integration help.

Managers have to do the work themselves

The middle management role has changed more than any other. A manager can no longer just organise the work and delegate it. They need to do their own analysis by understanding the questions they should ask and finding and synthesising their own answers.

The systems-thinking test doesn’t stop at the people you hire. We believe great leaders in AI-native businesses will absolutely need to be systems thinkers. Leaders have to be analytical and deep enough in this world to sequence it rather than just sponsor it.

If you're a leader, manager, or a non-technical founder, try to see the business as a system and work on creating something valuable for yourself and your team using AI. The good news is it’s never been easier.

I (Paul here) created and published an app on our Labs platform that was mentioned in part one. My app was a simple SDR scorecard, nothing too sophisticated. It took me an embarrassing amount of time to create it. It’s something an engineer in our team could have whipped up in minutes to an hour. But I felt it was best to deliver it end-to-end by myself. Partly, that was a cultural signal that everyone should feel empowered to create and use Labs. The main part was forcing me to understand what the steps actually are for delivering a live app and what’s genuinely possible versus what only sounds possible in a meeting.

Call it personal leadership context. We don’t think you can architect a transition well if you’ve never attempted it yourself.

Hiring for the people you need

The profile you hire for has changed. We've brought in people whose experience was perfect for the role as it existed a few years ago, but soon realised that the job and expectations had changed dramatically.

It was a signal that the org chart wasn't caught up with the tools and pace of the organisation.

So we now index less on experience and more on intellectual horsepower and curiosity.

To support this, we've created an AI fluency framework that sets out each person's level of AI fluency when they join and the level each role needs to reach after working with us. This framework encompasses every team member in the business.

The differentiators at the top of the framework aren't technical. Their creativity, curiosity and taste. Someone without curiosity or taste will struggle, no matter how fluent they are with the tools.

This framework has worked its way into hiring, interviews and performance reviews.

Where to start

The workforce is changing shape faster than the org chart is. As a leader, you now have to attract these people, recognise them in an interview, and then build a structure around them that doesn't exist in most companies.

Not everyone in your company needs to be a builder using AI, but everyone needs to use AI-powered platforms and workflows.

A practical place to start: go through each role and ask whether an AI-native person in that seat would be doing 10x what the current person does. Then decide whether that role needs to optimise itself or needs a builder alongside it. The answers will tell you who to back, who to hire, and where to build.