Scouut's Mid-2026 Startup & Scaleup Market Memo
How AI-native companies are approaching work, roles, teams, talent, hiring, compensation and capital.
Introduction
Over the past 6 months, the pace of change across company building has accelerated. How software gets made, how teams are assembled, what companies look for in new hires, what they are prepared to pay and what investors expect all look different from the start of the year.
AI is no longer contained to a handful of choices about which tools to use. Instead, it’s fundamentally impacting the decisions that companies make about work, people and capital.
At the start of the year, many of the practices I observed within startups and scaleups at the forefront were educated experiments or bets. Founders and engineering leaders were hopeful about what AI could unlock, and wanted their teams to adapt early. They were not in the majority, though, and these decisions didn’t reflect those that were being made more broadly across the ecosystem.
I have a useful view into this through Scouut. I’m a recruiter and startup hiring specialist first, and the companies that choose to work closely with us are often among those furthest along in the ‘AI-native journey’. I’m involved in the thought process behind the teams being assembled, the people those teams need and the conversations happening around roles, pay, equity, company design, capital allocation, and more.
This doesn’t mean that everything I see reflects the entire startup and scaleup market as a whole. Even within the ambitious end of the ecosystem, there is a considerable distance between the companies rebuilding around what AI can do and those that are positive about AI, use it regularly, but have kept most of the company surrounding it the same.
The former group is still relatively small, reflecting a growing minority of the global startup ecosystem overall, but being a small cohort doesn’t mean it should be ignored. It’s the companies furthest along the adoption curve who are beginning to set the standard everyone else will eventually need to compete with. For what it’s worth, in places like SF and NYC, the percentage of the market that this cohort represents is much larger than elsewhere. Make of that what you will.
This is also why broad studies of how people use AI cannot be relied on for accurate information about what your most dangerous competitors are doing. A study may describe its participants perfectly and still tell you nothing useful about the capability ceiling. The competition does not live in the average study participant. It lives at the very edge of the bell curve, among the small number of people and teams operating in ways that most participants have never seen. Those studies can tell you how adoption is progressing across a cohort. They cannot tell you what the companies setting the new standard are already capable of.
Across these companies, software production is becoming a capability that more of the company can access, while teams are getting smaller and placing more value and responsibility on each person’s shoulders. This is creating demand for people who can build systems that increase the capacity of everyone around them, and investors are beginning to split over whether smaller teams, concentrated spending and unfamiliar headcount plans represent good company design or an unacceptable level of risk.
These changes are connected, meaning it’s hard to make decisions around one without understanding the rest.
Today we’ll go through what I can see now, the logic behind the decisions being made, which early-year experiments have now morphed into the ‘correct way’ to build a startup, and what would now be considered the wrong, and potentially dangerous way to keep building.
We’ll also delve deeper into how you can and should be hiring the individuals who enable this new, correct way of building, what they’re joining and leaving, who you definitely shouldn’t be hiring, and the knock-on effects that all has for team design, org design, pay and comp, funding, and more.
“The future is here, it’s just not evenly distributed” is a saying that you may have come across - it’d be fair to say the future has arrived in software engineering, and that becoming ‘AI-native’ can’t really happen without excellent engineering. Because of this, and because my exposure is most closely related to building engineering teams, we’ll explore lots of these observations through a somewhat engineering tinted lens.
Make no mistake though, regardless of the lens you or I view through, everything discussed today has company-wide impact, and requires company-wide decisions to be made.
What AI-Native Actually Means
An AI-native company, in simple terms, is a company whose processes are designed and whose team is built around what AI can do, and what it enables, not the other way around. Where a reliable agentic process can remove a person from routine work, companies at the forefront are prepared to do that. Where human judgement is still required, the process should prepare the work and bring it to somebody at the point where a genuine decision needs to be made. I’ve written about this distinction in more depth in AI-Native Confusion.
Using AI Is Not the Same as Rebuilding Around It
A company can use AI heavily without doing any of this. An engineer might be much faster with a coding assistant, for example, while still working through the same queue, receiving the same incomplete context and sitting inside the same assumptions about who is allowed to produce software. The bigger change happens when the route the work takes is rebuilt, so that a company can move from an event to working software with far less human labour in between.
An AI-native company’s aim, among many other things, is to remove the need for a human in the loop as much as feasibly possible. Every human-enabled task is scrutinised, and first principles thinking is applied to ask whether that human genuinely needs to be there at all. In many cases, the answer is no.
What This Looks Like in Practice
I’ve seen examples that I can give, but don’t limit your thinking to just these examples.
Inside a few startups that I work with, when a customer reports a bug, an agent checks whether the problem is real, tries to reproduce it, locates the likely cause, prepares a fix and opens a pull request for an engineer to review - until the final review, there is no human in the loop at all. By the time an engineer is involved, the work has already been investigated and there is a proposed answer in front of them.
For some companies, and perhaps for some people reading, the words ‘reckless’ and ‘dangerous’ may come to mind. But this process is no different to the process that ran before, where a Junior Engineer would run through the very same process that is now agent-led. It’s no more dangerous than the process that came before it. It is, however, faster, cheaper, much more scalable and running 24/7.
In another startup that I’ve observed, a customer conversation or an internal product discussion is transcribed and passed into an agentic software factory, and by the end of the meeting the team has a pull request or even a working version of what was discussed. The first version may need more development, it may be released later or it may be discarded completely, but the conversation has already become something the team can inspect and test.
Previously, somebody would have translated what was said into requirements, those requirements competed with other priorities, an engineer (who was almost certainly not in the room when it was first discussed) eventually picks up the work and the people who were in the original discussion see the result some time later. Detail can be lost and time is added at every point. In many cases, that additional time would have been enough to not build what was discussed in the first place.
But what knock-on impact does that have? What potential customers or revenue have you left on the table? What learning opportunities have you missed out on?
As a purchaser of software ourselves, we have experienced first-hand the speed at which AI-native teams work. When we were making a decision about which CRM to move to, we assessed over 10 providers, and the newest, leanest team was truly on a different level to the rest. When we make feature requests, we get them in hours or days, not weeks or months. In our demo call with them, they were missing a feature that was a dealbreaker for us. That feature was launched within 24 hours.
These are the standards that the small minority of truly AI-native startups are setting, and the standards that all startups and scaleups will be judged against.
In another example, it’s clear to see how this creates a ripple effect within a business, and how other non-engineering roles change as a result. Within a client of ours, customer success and support teams work with agents in the company Slack channel to update documentation and other semi-low-risk content. This kind of work is no longer exclusively bound to engineering teams, and arguably engineering shouldn’t be spending any time or resource on it at all.
There are obvious limits to this. It doesn’t mean that everybody can safely change anything, and engineering judgement has not become optional. But the value of an engineer’s skill set has moved up a level. An engineer’s value and leverage now comes from designing, maintaining and improving the system that produces software. A strong engineer can solve a difficult problem themselves. A strong technical system builder (who will be an engineer by trade) can improve the way the whole company turns customer information, product thinking and technical intent into software, and more importantly, value.
This kind of person is the first piece of this interconnected, AI-native company building puzzle. We’ll spend more time discussing them later.
How Roles Are Changing
This may not be a popular opinion (I will, however, stand by the fact that it’s correct), but assigning specific ‘tasks’ to job functions has always been wrong. Needing to instruct someone through the inputs they should work through, as opposed to the outcomes you want them to achieve has always been a sign that you’ve hired people who aren’t good enough. Nonetheless, whether you agreed with that assessment pre-AI or not, it’s becoming very hard to disagree with today.
AI does lots of things. But it also changes who can actually do things. Who can start a piece of work, who is responsible for the output and outcome, whose time is needed to complete that piece of work end to end - all of these things are changing as a result of AI.
Writing code is now a task for agents. Product decisions will often now get made by engineers in the moment. Product specialists are spending more time with customers than ever before. Although AI in engineering is the underlying cause, almost all roles within an AI-native company look different.
For some companies, this isn’t a problem at all. They’ve always hired people with an outcome mindset, and the outcomes they’re responsible for haven’t changed. They’ll now be expected to reach them far sooner, and perhaps the expectations for the level of achievement have risen, but the direction of the goal remains the same.
How an outcome is achieved now looks materially different though. And for the companies who think about tasks in a fixed way (most companies think like this), rather than fluid tasks and fixed outcomes, problems are on the horizon.
Becoming AI-native, both as an individual or a company, requires a near-complete decoupling of what someone’s responsible for achieving, and how you think it should be achieved. In almost all scenarios, it’s safe to say that the optimal way to do something 6 months ago is not the optimal way to do it now - meaning any unchanged process or job function older than 6 months is now sub-optimal. For an old, corporate multi-national, that may not matter for a few years. For a young startup or scaleup that’s yet to ‘land’ and give investors a successful return, sub-optimal is not something you’ll get away with for long.
All of this is to say that how you need to think about roles, team structures, team functions, and so on has all changed meaningfully. What engineers used to do is not what they should spend their time doing now. The targets that you set for your salespeople should be almost unrecognisable to what they were previously. If your product specialists are still spending days on detailed PRDs, are you even employing a product specialist by the 2026 definition and standards?
What I can’t (or won’t) do is spend much time telling you what these people should be doing, because that would be assigning tasks to a function, which is wrong. What needs to stick with you from this section is simply the fact that change across any and all areas of the company is required (and should be welcomed). But there is a particular caliber of person who will thrive in that type of environment, whilst most others look lost. Unfortunately, many startups today are still hiring individuals who cannot find their way without directions. This was a questionable hire 6 months ago. It is a must not hire today.
Smaller, Senior-weighted Teams
The caliber and shape of individual is not the only changing variable, though. Among those Scouut works with at the forefront, there is an extremely strong preference for teams and overall companies that are smaller, higher-bar, and weighted towards senior hires. Note that ‘senior’ relates to impact expected per head and individual ability, and in practice it means hires with Senior, Staff & Principal titles. There is, of course, some correlation to years of experience, but this should not be confused with age. Also note that the use of the word ‘team’ here applies to both individual teams, and the company as a whole.
In the way that a typical startup or scaleup team would have made a corporate team look painfully large and slow by comparison, the new wave of AI-native startups do the same to teams that would have been some of the leanest just a year ago.
The AI-native startups coming through now represent something similar to a SWAT team, or elite units like the SAS. There is no room for trainees. There is no room for someone who does not have an elite level specialism. The least experienced or ‘senior’ are still a substantial level above almost everyone else in the market, and would be one of the best performers in almost all other companies. The skill gap between the worst and the best in the team has been squeezed massively, with the floor rising to be far closer to the ceiling than it’s ever been before.
But for those who have already built their teams - for the startups and scaleups who have been around for a few (or more) years - the chances that the team you had in 2025 is the optimal team for mid-2026 is nil. I could have told you that without any observation at all, but having observed enough of those teams (some who are now adapting, and many who are not) over the past few months, I am absolutely certain of that statement.
The companies that win over the coming months and years will be those hiring the best person they can into each individual role, and building small, elite, senior weighted, ultra-high impact teams. And whether you’re a startup that’s just about getting off the ground, or a bloated scaleup with 150 people doing the job of 12 AI-native hires, that needs to be the focus.
Why Smaller Teams Are Inevitable
Of course, unless you are that early startup who’s just getting started, there’s an elephant (or quite a lot of elephants) in the room. A small, AI-native team cannot become a reality without the removal of those elephants. But this is different from simply cutting headcount and calling the result AI-native. A small team can still work in the wrong ways, and move toward outcomes through the wrong processes. It’s less that becoming small will lead to becoming AI-native - although implementing change in smaller teams is easier - and more that when you become AI-native, you’ll have no need to be anything other than small.
When an elite, AI-native engineer carries the impact of an entire team (they do - and this is representative of what more and more engineers will be able to do as time goes on), do you really need 24 of them? Would you have hired 24 engineering teams pre-AI, even if you have the capital? For most, the answer would almost certainly be no. So if you’re levelling up the team to have that kind of impact, why would you even entertain keeping that kind of capacity around?
There will be a cohort of people who do not level up, and just like a member of the SAS unit that drags their team down, you can’t put up with that level of performance for a sustained period of time without putting the rest of the unit at risk.
I admit that this is easy for me to say from the sidelines. It’s not me who’ll make those decisions, or lead those conversations with the people you’re parting ways with. But it’s also easy for me to see the early teams rapidly catching the ‘established’ ones, and I’ve actively worked on team rebuilds where dozens of heads were replaced with a handful, with tremendously positive results.
Hiring as a Last Resort
I make most of my money through active hiring, and despite that, I’ll sit here and tell you today that hiring in almost all teams should be a last resort, because the risk of growing too fast and creating team debt is so substantial. Of course, when you need to hire, you need to hire, and the bar for what’s acceptable has never been higher. I’ve written about how this accumulates and why it becomes difficult to reverse in Team Debt.
This has a knock-on impact on both employee compensation and funding discussions, but nothing has been more impacted by this change in team design than the cohort of junior talent.
On Hiring Juniors
My view on conventional junior hiring is, unfortunately, very blunt. For ambitious startups and scaleups, the return on investment from hiring junior talent is very poor. On salary alone, paying 2-3x will get someone who absolutely dwarfs that increased cost in the impact they provide. But a junior’s salary is only one part of their total cost. Things like training, close supervision, correction of work, lack of skilled judgement and additional communication overhead all come with a cost.
There are areas of work where AI can compress the time taken from 1 hour to 1 minute. What it cannot compress (to an acceptable degree, at least) is an hour spent teaching somebody. A junior can’t acceptably compress their learning time, and they can’t acceptably compress the time someone needs to spend supervising them. These are not tasks where leveraging AI brings a return. They’re not tasks that are necessary to build a successful startup, nor are they the kind of unnecessary work that brings significant, disproportionate advantage. And in an AI-native company, if it can’t be leveraged by AI, or if it’s not necessary or bringing disproportionate reward, it shouldn’t exist.
You may notice my use of the word acceptably. AI can help with learning and training. Juniors will progress faster with AI available 24/7 to help and guide them, and the time it takes to get answers to questions, to have your work checked, to run experiments that help build taste and judgement, and so on are all compressed with AI. But if you want to build a successful startup, the level of compression isn’t acceptable, and you can’t have this kind of unproductive work happening in your business. It can happen on someone else’s time (and runway), not yours.
It is true that talented juniors are often more impactful when leveraging AI than many senior individuals out there today - but this is reflective of a skill issue in the senior cohort, not evidence that the junior cohort is a better investment, so don’t be misled. An exceptional senior hire who leverages AI effectively would outperform even the most talented junior AI users by an order of magnitude. There are companies who have unfortunately ignored this advice when I gave it to them, and who are regretting that decision just a few short months later - you don’t need to be one of them.
On a human and societal level, this is an issue - but it is not your issue to solve, don’t try.
The Leaders AI-Native Teams Need
Smaller, senior-weighted companies need fewer traditional leadership roles overall, particularly those whose main contribution would be distributing work, managing coordination and passing information between different layers in the company. When everybody in the team is expected to operate with ownership and judgement, adding people whose job is to manage those people can quickly reintroduce the overhead that very model was supposed to remove.
This does not mean leadership becomes less important. It means the leaders who remain need to be much closer to the work, technically or functionally credible, and capable of improving the systems through which the team operates. Their job is less about keeping a large team moving, and more about setting an extremely high bar, making the few decisions that need leadership judgement, and increasing the capacity and leverage of a small group of exceptional people.
This difference is becoming particularly obvious in the scaleup world. Most of the genuinely strong, AI-native engineering leaders I speak to inside scaleups want to quit. They agree with much of what I’ve described here, can see that their company is unlikely to make the changes required, and do not want to spend the next few years defending a team shape and operating model they believe is losing. Some describe it as a sinking ship. Others may believe that the ship will remain afloat, but have no desire to weather the upcoming storm. Regardless, they want to move on to faster, more nimble ships who can move in ways that allow them to avoid the storm entirely.
Why Most Teams Are Too Big
Production Capacity and Valuable Demand
You might ask (as many have) why I, along with so many others building in this way, am adamant that most established teams are too big.
I was speaking to the technical founder of a Series B scaleup the other month who said, “If my team of 20 engineers suddenly do the work of 4 engineers each, I now have a team of 80 with basically no increased cost. Where is the downside there?”
I’ll tell you. Although an engineering team (you can replace engineering with anything else, the logic is the same) can now produce far more than it could 6 months ago, there is still a limit to how much valuable work exists at any point in time. Your customers do not suddenly have unlimited budgets, unlimited attention or an endless appetite for new features because your team has learnt to build them faster.
The same is true across marketing, sales, customer success, accounting, and more. A company might unlock several times more production capacity while the market it serves, the number of useful problems it can solve and the amount its customers are willing to buy remain much closer to where they were before. Of course, earlier stage companies will expect to grow, but you are not about to serve 4x more customers, or get paid to build 4x more features overnight.
What you can do is experiment faster, and run a higher total volume of experiments to inform correct decision making in a quicker and more accurate way, but this is easier said than done. What’s actually happening in most post-Series A companies is rapid production of slop.
Slop Production
This happens for lots of reasons, and it’s a different reason in different companies. It could be because the bar for talent is lower than it needs to be, and the decisions being made around what to build by those lower caliber staff members are just poor. It could be uninformed leadership jamming AI tools down the throats of staff in an unproductive way. It could be boredom, simply because there’s a lack of work to do and staff feel like they need to do something.
Regardless, slop production is very common, and for the most talented out there, it’s becoming increasingly frustrating working in these kinds of environments. Speaking to multiple engineers at a very well-regarded early scaleup in Sydney, the company is leaning into AI hard, they are redesigning processes to leverage AI well, and they are demanding that everyone uses the best tools in their highest leverage forms (e.g. engineers are very strongly encouraged to orchestrate multiple agents and refrain from using an IDE, non-technical users were pushed onto Claude Code very early on, even before co-work was released because it was objectively better than a normal chat with Claude), but they are increasingly pumping out “absolutely useless features that nobody wants or uses”.
For this company, and many others in a similar boat, the simple truth is that their team is too big. They got a lot of funding before this latest AI step change, grew the team rapidly with good but arguably not exceptional people, and now have far too many people doing way too much work for the stage of company that they are, and the maturity of the customer base that they have.
The Competitive Risk
The risk for them, aside from building an increasingly bloated product that creates sub-par value, is the multitude of smaller, newer, higher-capability startups creeping up behind them. The threat of a more focused, faster moving company with substantially lower costs, much better unit economics and a cheaper, similar (or better) quality product arriving in the next 6-18 months is very real. And if these slightly more established companies aren’t prepared to completely disrupt themselves internally - someone else absolutely will.
The Factory Builder
We spoke earlier about the person, or, as a company scales, the people, who represent the first piece of the puzzle. The preference for smaller, leaner teams is being matched by a demand for these kinds of people. Engineers, almost exclusively at a Staff or Principal level, who can build systems that expand founder and wider company capacity are the in-demand hire. Their individual contributions to the product itself are still stellar, but their bigger contribution is what becomes possible for everybody around them once the process, infrastructure or technical foundation exists.
I refer to these engineers as “Factory Builders”, and I wrote about exactly what they do and unlock in The Factory That Builds the Software, but in summary, their time, judgement, taste, and engineering skill is dedicated to building durable, global (whole company) agentic infrastructure that safely and effectively removes humans from the loop, and enables every single employee to leverage AI to a degree that they could not without that infrastructure in place.
This work begins within software engineering itself, and this is ultimately what allows bugs to be fixed without a human in the loop, and support or product teams to ship to production. The goal is to commoditise much of the pre-AI engineering skill set (including many facets of architectural decision making that may be described as taste or judgement) and provide it on demand for anyone in the company in the form of an agentic task force and system, not a human colleague.
Beyond Engineering
But the work isn’t limited to engineering. It’s becoming clearer that the best person to automate a job isn’t the person who does that job, but an engineer who understands that job intimately. In more practical terms, asking a lawyer to automate a lawyer’s job is a mistake, and asking a factory-building engineer to sit with a lawyer, understand their job intimately, and automate it on their behalf is a far more effective way to do things.
What this means is that, unlike the pre-AI Staff and Principal level engineer, who have always been expected to unlock engineering productivity and increase the impact of the engineers around them, a factory builder impacts and uplifts everyone in the entire company.
There has never been a role that brings with it this much expected impact - but impact can be good or bad, and realised or unrealised, and with that in mind, making sure this person (or people) is in the very top bracket of ability is of paramount importance - as any lack of impact from that person is unrealised impact for everyone else that you employ.
Similarly shaped hires are also appearing outside of engineering - although it’s important to understand that at the time of writing, nobody who’s non-technical has the skill to create this kind of factory, which is why the first puzzle piece will be an engineer. But take my lawyer example for instance - the lawyer you’d pair with the engineer to create your legal factory would also be a top-tier systems thinker. They’d need to understand what the very best legal work looks like, and what outcomes are expected from the very best legal teams. They are effectively the model that you’re trying to clone, and cloning someone who has a limited or average understanding of the function will ultimately lead to a very average agentic legal function.
The People the Factory Cannot (Yet) Replace
Everyone who leverages that factory - all the other humans you employ - needs to bring something to the table that the factory can’t do. If your factory is average, there’s a lot that it can’t do, and you’ll still need to employ a lot of humans unnecessarily. When your factory is exceptional, which is the case for those factories built by exceptional people, the need for humans at the factory worker level is extremely limited, with most hires spending a majority of their time making decisions, and attempting to encode that decision making logic into the factory.
It’s probably at this point that I should clearly state, as some of this starts to sound a bit make believe, that none of this is written as a prediction. Everything discussed up until this point is happening today in AI-native startups, and as mentioned before, it’s these startups - however small the cohort is - that will set the standards that all will be assessed against.
Where the Best People Are Moving
Th best people are not simply leaving bad companies, weak products or jobs where they are underpaid. Many are leaving successful, well-funded startups and scaleups, potentially ones with strong brands, good salaries and roles that they were extremely happy in 6-12 months ago. But many no longer believe those companies are where the best work will happen, and they no longer see them as companies that will win.
Instead, they look around and see teams that were built for the pre-AI model, management layers and process that only exist because of that team size, and attitude toward AI that is 6+ months behind where it needs to be. They are often being asked to simply make the existing organisation or processes faster, or to increase output through AI, when what they actually believe is that the organisation needs to be rebuilt around a completely different way of operating. Once somebody can see that distinction clearly, spending more time optimising the old, sub-optimal way starts to feel very unappealing.
What they are joining tends to look like the opposite. They are moving towards earlier, smaller, genuinely AI-native companies where the team is weighted towards exceptional people, the operating model can be built without negotiating through layers of old company decisions, and one person’s judgement can shape far more of the overall outcome. They want to work with peers who have reached the same conclusion, build the factory rather than fight for permission to retrofit one, and have responsibility and upside that reflect the amount of company leverage they can create.
For leaders in particular, this can mean moving to a company where they manage fewer people but have substantially more impact. The size of the org beneath them matters less than their ability to change how the entire company works, and for them, a smaller title or team on an org chart can still represent a much larger job when they are the person building capability that everybody else will use.
What’s concerning for those on the wrong side of this is that they are actively losing the people most capable of helping them adapt, while the companies already ahead are gaining engineers, leaders, and other excellent operators who have seen exactly where the older scaleup model creates waste, and how the newer model can take advantage of the existing, slower competition. Those people bring the context, judgement and scar tissue from building at scale, then apply it inside a company that does not carry the same organisational debt.
By the time an established company accepts that the operating model needs to change, many of the people who understood the change earliest are often already building somewhere else.
Assessing the New Bar
The First Problem: Is the Job Good Enough?
For those aiming to build in the correct way, it’s nice to think about hiring people who are actually this impactful. But thinking and doing are very different things, and doing, in this case, is exceedingly difficult. There are two layers of difficulty here, with the first being a product and marketing problem.
In simple terms, is the product (the job, and the opportunity to work at your company) good enough to be a legitimate value proposition for these people, and is that product being marketed effectively enough for them to realise? This is very complex and nuanced, and I get paid good money to spend days of my time solving these problems for startups and scaleups, so you won’t find complete answers here. In the factory for my own role at Scouut, this is one of the human-in-the-loop parts that still needs me.
The Second Problem: Assessment
Once you find your way through the first problem, the second problem you’ll face is an assessment problem. The new bar is astronomically high. In startup circles, hiring within the top 20%, top 10%, even top 1% will be the claimed aim from most founders. If we go high with top 1%, I can just tell you now that it is extremely unlikely that you’ll find the caliber you need in a room of 100 people. You’d probably find them in a room of 1000 people, you might not though. But how do you assess and confirm performance at that level?
First, it’s probably helpful to understand why the bar has to be so high, and why the pool is so small. We already discussed how each hire needs to have more impact than ever before - meaning if someone’s marginally better, that marginally better ability is applied across a much greater volume of work or output than before. In racing, a second a lap is a relatively small gap across a single lap, but a minute across 60 laps. When doing a previously normal amount of work, a small gap is small - but in the AI world where each individual employee is inherently doing so much more, a small gap is quite big. The people you hire need to be on the right side of that gap.
But that doesn’t explain why the pool has shrunk. Let’s assume you’re a company that would have typically hired 1 in 100 people, or the ‘top 1%’ (this is not 100 people that you’d meet, it includes everyone you chose not to meet too). If you take each individual that you would have hired and examine their AI usage today, almost all would fall below the new bar. If you named 100 hireable people who sit above your bar in 2025, a small handful, perhaps 3 or 4, would now also be a great AI user. This applies to those you’ve already hired too, by the way - but we’ve already gone over why team change is a must.
Anyway, the point is that to be above the bar being held at AI-native startups on the forefront, someone needs to be elite at whatever it is that they do (engineering, law, marketing, sales, etc.) and elite at using AI. Naturally, that makes that pool very small, because you’re assessing against two non-negotiable skillsets, not one.
Assessing someone’s ability at whatever it is that they do hasn’t changed that much. For an engineer, you’ll still assess whether they’re technically capable through getting them to manually write some code and a whiteboarding session or similar. You might watch them write the code to make sure they aren’t cheating, but it’s still something you’ll assess. If you’re hiring a salesperson, you’ll still absolutely need to assess whether they are fundamentally good at selling, and so on.
Assessing AI Use
What’s changed is the additional need to assess AI usage and capability. But AI usage is a spectrum - and an extremely wide one at that. If you’re assessing prompt quality, you’re assessing AI usage wrong. If you’re asking someone to work through a repeatable question or task with a pre-determined ‘correct process’, you’re most likely assessing wrong. If you’re asking people about how they use AI, and hoping you hear words like “harness” or levels of token spend that signal good things, you may be onto something but you’re still likely running an incomplete assessment, and the results of that assessment may be wrong.
The truth is, elite AI usage is mindblowing. It is literally unbelievable, to the point that you probably won’t believe me unless you’ve seen it - and that’s the point. To assess AI usage at that level, you need to see it. Meaning the best way to assess someone is to watch them.
I have heard feedback from clients about engineers whose agentic workflow reached a point of value in 90 minutes, while actual employees who worked on that very same problem a week prior took a day and a half (with AI).
I can dive into obscure and extremely niche market descriptions to uncover all candidates who fit within those walls within 10-20 minutes, when it would take so long that it’d arguably be borderline impossible for other recruiters with less developed workflows to even attempt.
But if you’re asking candidates to complete a task at home, how do you know if it took them 30 minutes or 3 hours?
If someone asked me to create a boolean string for a LinkedIn Recruiter search, what are they even assessing? They’d be boxing me in, and bottlenecking my ability to do actually valuable work. Why would I ever spend time creating that search string when our sourcing factory has already kicked off a search by the time the call with our client ends?
My point is, lots of people think they know what the best agentic workflows look like, and almost all of those people are wrong. Assessing with a perceived correct answer in mind is also wrong, and watching someone use AI is, as it stands, the most accurate way to assess. What you’re waiting to see is an outlier who stands well above the rest.
Time-to-Value (TTV)
All of the above can ultimately be summed up in a single, measurable metric that I’ve been calling time-to-value (TTV). The better someone is at the job function they’re a specialist in, and the AI that they’re able to leverage, the shorter their TTV will be. Value is the important word, as there are people who can do a lot with AI whilst producing no notable outcome of value at all. If someone can’t reach valuable outcomes through their AI leverage, they are not good at using AI.
You can measure TTV across a few levels of work where acceptable quality would understandably vary. So for example, an engineer might have incredible TTV for prototype-level work, but really poor TTV for production-level work. A lawyer may have amazing TTV for drafts, but awful TTV for anything that needs to be sent to the courts.
The stage and type of company that you are will impact what’s actually most important for you and the team that you’re building. An early stage startup may not care about someone’s TTV for production software with millions of users, but you’ll absolutely care about someone’s TTV for quick experimentation and customer-ready features at an acceptable quality level.
Throughout your entire interview process, and when assessing the new capability levels of your existing team - the leading signal (not the only signal - the leading signal) for quality is a low TTV in the areas that are important for you. This is what you should optimise for above all else.
What Exceptional People Now Cost
Of course, when people reach valuable outcomes far quicker than almost anyone else, and they do that consistently enough that their impact outweighs that of multiple people combined, their own value begins to change.
Salary and Impact
AI-native companies pay a considerable amount above conventional salary references because they believe they are buying much more company leverage than an individual person would have historically provided. They think of them less as an individual employee doing an individual job, and are focused more on the problem the person can own, the systems they can build and the future roles or coordination tax that the company will avoid because they are there.
In my own observations, it is the pre-seed and seed stage companies who are moving more aggressively on compensation than better funded, later-stage companies, with companies from Series A onwards, but particularly through Series B and C struggling to justify these new levels.
This is partly because those companies aren’t actually employing many or any of the people who bring with them the impact and AI leverage that deserves those new figures. It’s also because of internal politics and rules, which should be thrown out as I discussed in Paying for Outliers. But it’s mostly because, for them, a 100% or 200% increase in salary seems entirely ridiculous until their best employees leave for that kind of pay rise.
Salaries are ecosystem specific so I won’t spend too much time on exact numbers here, but in the Australian Software Engineering space for example, salaries on offer for top Seniors are up circa 30-50% depending on what they were previously earning, and I’ve seen Staff and Principal Engineers add 50-100% to their base salary over the last few months.
I’m even aware of a Founding Engineer who was hired on what would be considered a top-tier salary by a pre-seed startup earlier this year. He is a factory builder, and since joining he’s had a level of impact that exceeded expectations by so much that he’ll get a ~30% increase in the coming weeks.
Again, words like dangerous and reckless may come to mind, but it’s hires just like him that will allow this startup to extend their runway further than they’d have first expected. One of our own clients - again at an early stage - had budgeted for 10 technical hires this year. After bringing the 2 best people we could find onboard, they’ve decided that there’s simply no need for any more at the moment, and that runway can be allocated to other things like marketing.
Ultimately, the correct way to view salary is not as the price you pay for a human doing a job. Instead, view money as a resource that you use to purchase impact, and the amount of money that something is worth scales accordingly with the impact provided. Whether that money goes on tokens, marketing, humans, an event, your office, or whatever else - that’s up to you. But for what it’s worth, when you break it down in a “dollar per impact” framework, those paying top of market salaries for top of market people are getting the deal of a century for what is, for now at least, incredibly underpriced talent.
Token Spend
The other noticeable cost attached to exceptional AI-native people is tokens. Engineers we place are often somewhere within, but towards the higher end of, a $1k-$5k AUD monthly range, and I know some who spend considerably more than that. Among the best AI users I know, it is generally accepted that it would be very difficult to operate at an extremely high level of leverage while spending much less.
The exact figure matters far less than the principle. Pricing will change, the models somebody uses in two weeks may be different, and what looks expensive today may look cheap by the end of the year. Like salary, token spend is simply spend. It is money traded for impact, and AI-native teams look at the impact being created, compare it with the spend, and generally conclude that they are getting a very good deal.
Even as a non-technical person, a useful rule of thumb is that if someone cannot justify the cost of a Claude Max (or equivalent) subscription through the impact they create with it, that is a red flag, and hiring that person is probably not a good idea. Creating ROI on that spend is extremely easy for anyone competent.
The people who complain most about token cost are unlikely to have unlocked genuine leverage from it yet. If a few thousand dollars a month allows one exceptional engineer to carry the impact of a team, or allows a small company to avoid hires that would have cost hundreds of thousands of dollars a year, the token bill is not the expensive part. The expensive outcome is constraining that person because the spend looks unfamiliar.
There is an important difference between the cost of AI and the cost of inefficient waste. Agents producing work nobody needs, running in loops for no reason, using expensive models where cheaper ones produce identical results, or repeatedly failing without anybody improving the system are all real costs. But some wastage is not only acceptable, it is probably economically better than making exceptional people slow down to optimise every inch of the system they’ve built. Human time and missed opportunity are expensive too. Being overly careful with tokens can easily save a small amount of money while destroying far more impact than it preserves.
Equity
It’s not just base compensation that’s on the move. When each individual in the company covers more surface area than before, and is expected to have more impact and drive more value across that surface area than before, they expect to be rewarded in a much bigger way for any potential upside they help create too.
As with base salaries, equity varies from ecosystem to ecosystem. Equity allocations in the US are higher than in Australia, for example - despite the fact that US startups also achieve much higher valuations, and are far more likely to reach a valuation that could lead to a life changing exit for early staff members.
Nonetheless, equity percentages in AI-native teams are rising. For Founding Engineer roles, we’ve seen the median rise from roughly 1% to closer to 1.5-2%, and the maximum we’ve seen has gone from 3% to 4%. We’ve also seen early employees have far more success when it comes to negotiating better terms on their equity, with some achieving near-identical deals to if they were a founder or investor, not an employee.
My prediction is that this will continue. Smaller teams mean that the same pie can be cut into bigger slices for the people who actually make a difference and help the company achieve something - and the success or failure of a startup has never been so reliant on the caliber and impact of the early team as it is today.
The Investor Split
Unsurprisingly, for investors, there’s a lot to consider here, and the investor landscape, from my observations at least, is very much split.
Two Definitions of AI-Native
On the one hand, there are funds that are so convinced by the capability of AI-native teams that it is the only style of startup building that they will invest in. On the other hand, many funds are still investing in the older style of building, and actually, there are quite a few funds who will be actively repelled by what AI-native startup building actually entails.
It takes time for investments to pay off, and it wouldn’t be accurate for me to say that either camp has enough realised evidence in the form of financial return to claim that they were right. However, I am overwhelmingly convinced that those in the first camp are right, and those in the second camp are making some very expensive mistakes.
The Economics Already Look Different
It is true to say that there are AI-native startups reaching milestones in months with a few million dollars, that previously took earlier startups years and 10s of millions of dollars. It is also true to say that AI-native startups achieve PMF much quicker than many previous startups have, and that they spend less money in doing so. And finally, it’s true to say that AI-native startups have far more impressive employee-to-revenue numbers and unit economics.
My opinion, based on real evidence that I’ve seen, is that AI-native startups also have a much better understanding of applied AI, value delivery via what they are building, the future of how customers will use and interact with products, and more. For example, whilst older startups and early scaleups spend much of their time building more features so customers can do more, AI-native startups understand that helping customers to do more is probably the wrong approach, and that building capability (agents, perhaps, but capability can be delivered in a number of ways) that allows the product to do work on the user’s behalf is far more helpful, and will be far more durable as the market evolves.
But, if we’re talking about the investor ecosystem today - opinions are split, investment philosophies are split, and if you’re building in an AI-native way, which is what we’ve been discussing throughout this piece, there are a number of investors who will immediately say no for that reason alone.
They won’t hear AI-native and think ‘no thanks’, though. They’ll tell you that they want to invest in AI-native teams, and they’ll genuinely believe that they are. The companies in their portfolio are ‘using AI’, and some even claim that they are ‘doing more’ - but as we’ve been discussing, using AI to do more doesn’t automatically make you AI-native. And when you start pitching the idea that a small, senior, well-paid team can create as much value and impact, if not more than the bigger teams that they are currently funding, they’ll think you’re delusional.
Of course, they think this because they are yet to see it themselves within their own portfolio, much of which is a self-fulfilling prophecy. Companies who pitch the AI-native playbook naturally pay more per head, and many funds don’t fund that kind of spending that they perceive to be reckless or dangerous. But when you turn down the opportunity to invest in any company building in this way, of course you won’t have any portcos achieving the kinds of results achieved by true AI-native teams.
But when investors take a chance on that kind of building, as some investors and funds have, it suddenly becomes the only thing they will consider investing in. I can imagine the kind of conversations they are having with early founders, because I’m having and reading them too.
The Evidence So Far
Scouut had a sizeable role in building the early and growth stage engineering teams at Eucalyptus, a scaleup that recently got acquired for over $1B USD. We have good relationships with a lot of people there, and a lot of people who have since moved on to build at the early stages again. Engineers and operators who know what it took to build a successful company a few years ago now report that they are doing so much more with fewer resources than ever before in the newer, smaller, AI-native startups that they’ve now joined. They are convinced that it’d cost far less, require fewer people, and take less time to reach many of the same milestones again. They’d also be able to avoid much of the bureaucracy and politics that was practically unavoidable in any Series B+ scaleup of the past.
Sam Kroonenburg, who founded A Cloud Guru (sold for $2B), has been working on a new startup called Cuttable, and he’s openly spoken about how much more they’re able to do this time around as a result of building in an AI-native way. If anyone has a legitimate benchmark to compare the new ways to, it’s him.
Josh Foreman, founder of InDebted (Series C), decided to step down from the CEO role so he could lead the launch of an AI-native team within the business itself, all in an attempt to disrupt the company from the inside. Reports so far suggest that it’s going well, further confirming that AI-native teams and companies can achieve more with less, by approaching problems in a completely different way.
The Existing Portfolio Problem
But for every company that’s moving in this direction, there are 5 who aren’t. For investors who want their money in AI-native teams, this is deeply concerning. Whether they’ll admit it or not, they know that many of their existing portcos have awful unit economics in the new world, and teams that are far too big to justify any further funding given the other up-and-coming options available.
When one scaleup raises a Series B with plans to double the team size from ~50 to almost 100, but adapts and instead triples revenue with no overall headcount increase at all, there are obvious alarm bells when others go ahead with the hiring plans anyway, and revenue increases at a much slower rate.
The truth is, regardless of philosophy and what they want to be investing in now, all VC has money tied up in companies who are building in the old ways, and who are unlikely to adapt in time. Some are unaware, and others are acutely aware, placing big bets into actual AI-native teams in the hope that they will outweigh the losses that their prior investments will bring.
Of course, there are other concerns around whether AI-native teams even need that much investment, downward pressure from confident, capable founders on the slice of the pie they’ll give up, and the overall, long-term role VC will even play in startups when reaching PMF and notable revenue milestones costs so much less than it ever has before. Many of these questions have no clear answer yet, but there are conversations happening nonetheless.
The Risks
While the cohort is still a minority, there are a good deal of companies getting things directionally right. What’s holding them back is the quality of execution. In theory, they know that AI should change how work moves through the company, what each person can achieve, how teams are designed and what exceptional capability is worth. The problem is doing one or more of these things without properly understanding why, just because you’ve heard or believe it’s the right thing to do.
Hopefully the ‘why’ is understood after reading this, but it’s worth exploring a few other areas where I’ve watched companies get it wrong.
Engineering Leadership and the New Bar
This is particularly difficult for non-technical founders, who quite reasonably trust their engineering leadership to understand what good looks like. But most engineering leaders are not at the forefront today, even very good ones.
That alone does not make somebody the wrong leader, although they do need to be close. What matters is whether they know that there may be something materially better than what they currently understand. An engineering leader who is open-minded, curious and prepared to have their existing assumptions broken can move quickly. A leader who believes that their current use of AI already represents the frontier is far more dangerous, because the founder may trust a benchmark that is no longer high enough.
The bar described throughout this memo applies to engineering leadership too. If the engineers underneath them are expected to operate with exceptional judgement, build factories and create company-wide leverage, the person leading them also needs to sit above that bar.
There are also engineering leaders out there who are not onboarding with this style of building at all. My very strong advice would be to find one who is.
The Bottlenecks Move
As AI removes one bottleneck, it absolutely will expose, create or move another. Software production may become dramatically faster while review, permissions, deployment or product decision-making remain slow. A support team may be able to identify and prepare a fix while the authority to ship it still sits somewhere else. A Factory Builder may create capability that the rest of the company is not yet structured to use.
Some companies reach the next bottleneck and decide that the leverage was overstated, unsafe or not worth pursuing. The teams getting the strongest results treat the new bottleneck as the next thing to solve. They understand that becoming AI-native is not a one-off implementation. Each constraint removed changes where the next constraint sits.
This is also where legitimate concerns around security, quality and human judgement can become blanket reasons to preserve the old process. The strongest implementations do not pretend those risks have disappeared. They build the permissions, testing, escalation and review needed to stop those concerns becoming permanent bottlenecks on everybody else’s leverage.
Evidence of Real Leverage
The clearest evidence is time-to-value and whether useful metrics and milestones are being reached earlier than before or with fewer resources. Tool adoption, prompts submitted, code generated, hours reportedly saved and token usage can all rise without the company becoming materially more capable.
If customers receive valuable improvements sooner, experiments reach a useful answer faster, revenue milestones arrive with fewer people or work that previously required a new hire is now absorbed by the existing company, the leverage is real. If the main evidence is that more work is being produced, the company may simply be moving faster towards the same outcomes it was already capable of reaching.
This is why good intent is not enough. Companies can understand the direction, invest real money and make visible changes while implementing the model through the assumptions, people and measures of the company they were supposed to be replacing.
The Scaleups
I am very well aware that for a scaleup or someone working within one, this is very likely to have been unpleasant reading. I will take a moment to say that it may not be all doom and gloom, but I also don’t want to overcorrect and pretend that things are fine either - they are not.
Some scaleups are adapting, and some of those are already semi-aligned with much of what has been discussed throughout this memo. They also have customers, distribution, company knowledge, capital and strong people, all of which remain meaningful advantages if the operating model changes with enough force. Many are not adapting, and there will be lots of casualties.
For those that are adapting though, the most likely mistake and risk lies in not taking those adjustments far enough. This is somewhat separate from getting the execution ‘wrong’. The execution is right, but the magnitude of that execution is too weak and too slow.
The Size of the Correction
A scaleup-sized correction will feel extreme. The team structure, management layers, compensation references, role definitions, hiring plans and operating processes were all built during the company’s rise. They are attached to the people, decisions and systems that got the company to this point. Changing them radically can feel like rejecting the very things that made the company successful.
That creates a strong pull towards smaller changes that feel more comfortable. The company raises the talent bar, but not to the level the new model requires. It sees productivity from AI increase, but only by a little. It becomes prepared to pay more, but not that much more. It lets a couple of people go while retaining most of the organisation, when an argument could be made for most to go. Or it accepts that deeper, radical change will be required - but not yet.
Every decision can be presented as progress, and technically, it is. The problem is that a collection of directionally correct, moderate decisions does not necessarily add up to a sufficient response.
The size of the required correction is often difficult to accept because the existing company still works just fine too. There is revenue, there are customers, the product is loved and many of the people are good at jobs that were genuinely important to the company’s success. Removing layers, rebuilding functions and changing the standard against which those people are assessed feels far more confronting when the company is still moving forward.
It Will Not Feel Like Failure
A scaleup in this position may not be behind target. It may still be growing, progressing and achieving many of the things its board expects. AI productivity may be improving and revenue may be rising. Nothing in the internal reporting needs to look like a crisis.
The threat is relative. Internal dashboards compare the company with its own plan and its own previous performance. The market increasingly compares it with companies reaching the same milestones with a fraction of the people, capital and time.
Those companies may still be behind today, which makes them easy to dismiss. Most are still small and relatively unknown. But their cost base is lower, their decision-making is faster, their team was built to the newer standard from the beginning and many of the strongest people leaving established scaleups now want to join them. They do not need the incumbent to stop growing. They only need to move faster than it does. They represent the bear that a scaleup is unlikely to outrun - except the scaleup can’t see the bear at all.
This is why waiting can feel rational until it suddenly is not. The scaleup can adapt later, but by then the talent gap may be wider, the organisational and team debt harder to unwind and the company coming from behind much closer than first realised.
Some scaleups may make the full correction and become formidable because the advantages they already hold are very real, and very valuable. I am very bullish on the InDebted self-disrupt style efforts, and think this is an intelligent play that every Series B+ company should follow, but I am not bullish on scaleups overall. Neither are the AI-native startups who have them in their sights.
The Forefront is the Benchmark
As I mentioned at the beginning of this piece, the number of companies building in the way I’ve described is still small. If you ask ten founders or engineering leaders what AI-native company building looks like, you may hear ten different answers, and it is entirely possible that none of them resembles what is happening inside the companies at the very forefront of all of this. Some will think parts of this memo are exaggerated, imaginative or simply impossible. Others will tell you they are already AI-native while operating in ways that look much closer to the companies they were a year ago.
None of that changes the fact that these teams exist, or what they are already achieving. Once a small team has demonstrated that it can reach valuable outcomes with fewer people, less capital and far less time - and they have - the benchmark has moved. It does not matter that most companies have not reached it yet. What matters is that somebody has, because what has been proven possible cannot be made impossible again simply because the rest of the market is yet to figure it out.
What I’ve discussed today isn’t just stories that I’ve been told about these companies, or reading about what’s happening from a distance. This piece hasn’t required extensive extra curricular research to write. It is lived experience.
Through Scouut, I’m involved in helping founders think through and design these teams, hiring the people who become a part of them, and seeing the decisions, salaries, systems, trade-offs, risks and results up close. This memo is based on what I’m watching happen, and what I’m helping companies build.
So when you think about your own company, don’t set the bar according to what is perceived to be normal across the market, or what a larger and seemingly successful company is doing today. Find the teams achieving things that seem unreasonable, understand what makes those results possible and calibrate against them. The cohort may still be small, but the standard they have created is the new benchmark. Whether the rest of the market acknowledges it yet is irrelevant - as long as you do.