Big Tech Hiring Narrows Around Engineers
On July 11, Business Insider turned a venture-firm dataset into a simple hiring chart: software engineers now account for 55% of hiring at major technology companies, up from 46% in 2019.
The same summary carried the harder line for the rest of the org chart. Engineer hiring was down 11% from 2019. Design hiring was down 48%. Product management was down 39%. Marketing was down 36%, according to the Business Insider article, which cited SignalFire’s 2026 State of Tech Talent Report.
That is not the story many workers expected two years ago. The fear was that coding assistants would make engineers the first large white-collar group to be cut. The data points somewhere else. Big Tech hiring is smaller, but the slice reserved for engineers is larger. The functions around them are losing more ground.
The pattern matters because org charts do not shrink evenly. When a company freezes a product manager, designer, marketer, recruiter or entry-level role, the work does not vanish. It moves. Engineers spend more time interpreting customers. Managers spend more time reviewing AI-assisted output. Founders write more job descriptions. Senior employees train fewer juniors. A customer may wait longer for the answer that used to come from a support layer.
AI did not remove the support layer. It made companies ask whether they could afford to name it.
That question now belongs in the hiring plan. If the company is going to run a senior-heavy engineering core with fewer adjacent roles, it needs a file that says which work moved, who absorbed it, what failed, and when the next support hire is cheaper than another engineer doing non-engineering work.
July 11 put the org chart into the news
SignalFire’s report had been public before the Business Insider story. The news hook made the data visible because it fit what laid-off workers, founders and hiring managers have been seeing in fragments.
Technical teams are not hiring as if 2021 returned. SignalFire says hiring at large tech companies is running 25% below the 2019 baseline on a trailing-12-month basis. It calls the current level the lowest since the 2023 crash. But the decline has not hit each function in the same way. Engineering held up better than design, product and marketing.
That gap changes the meaning of “AI productivity.” For a software organization, productivity used to mean how many engineers could ship a feature, keep a service alive or close tickets per sprint. In 2026, it increasingly means whether a smaller company can ask engineers to carry more of the work that used to sit around code: product discovery, customer understanding, incident communication, quality review, documentation, go-to-market support and internal tooling.
The public story often says AI lets companies do more with fewer people. The private meeting asks which people.
If a company cuts a designer and keeps an engineer, the engineer may now own more UI decisions or rely more heavily on AI-generated prototypes. If it cuts product management, engineering managers may arbitrate prioritization with less translation between customer, sales and technical reality. If it cuts marketing, product and engineering leaders may write more launch material, demo scripts and customer education. If it cuts recruiting, founders and hiring managers spend more time sourcing, screening and closing.
Those are not free hours. They are hidden budget transfers.
The distinction matters because many AI plans still count only the visible headcount change. They count the role frozen, not the work reassigned. They count the seat saved, not the review hour added to a manager. They count the smaller team, not the opportunity cost of a senior engineer spending Friday afternoon cleaning up customer-facing copy from an AI tool.
That is how an org chart becomes misleading. It can look leaner while the work becomes more tangled.
SignalFire measured a smaller hiring pie
SignalFire’s 2026 State of Tech Talent Report frames the reset in three numbers.
| Hiring signal | SignalFire 2026 data | Operating implication |
|---|---|---|
| Major tech hiring | 25% below the 2019 baseline | Companies are not simply returning to pre-pandemic growth plans |
| Software engineer share | 55% of all hiring, up from 46% in 2019 | Technical talent takes a larger slice of a smaller hiring pie |
| New grad and entry-level hiring | Down roughly 65% at Tech Majors and about 76% at early-stage startups versus 2019 | The on-ramp into the industry is much narrower |
The engineering share is easy to misread. It does not say engineers are safe in an absolute sense. Engineer hiring is still down. It says other functions are being compressed faster.
That compression is the useful signal. It suggests that companies still need people who can build, integrate, debug and operate technical systems, especially as AI becomes part of the product and the work process. But they are testing whether adjacent work can be absorbed by tools, managers, founders, senior engineers, agencies, contractors or customers themselves.
The answer will vary by company. Some product managers were performing work that an AI-assisted engineering team can now cover. Some marketers were producing content that a smaller team can draft and test faster. Some design work can move into component systems, product analytics and AI prototyping. Some recruiting coordination can be automated.
But some support roles were never merely coordination. They carried judgment.
A product manager who knows which customer request should not become a feature is not the same as a backlog groomer. A designer who catches a trust problem in a medical, financial or workplace interface is not a decoration layer. A marketer who can explain a complex AI product without overselling it protects the company from bad promises. A recruiter who can separate real AI workflow skill from keyword noise saves managers from expensive interviews.
If a company removes those roles, it should say where that judgment went.
The danger is not that every support function must be preserved. The danger is that the company treats support work as waste until a failure proves otherwise.
That failure may look like a product that ships faster but solves the wrong problem. It may look like a sales demo that promises more than the product can safely do. It may look like a hiring process full of AI-fluent candidates who cannot perform the real task. It may look like a senior engineer burning time on work a lower-cost specialist could have handled better.
The smaller pie forces a harder question: which support work is overhead, and which support work is part of product quality?
Engineers held while adjacent functions shrank
The gap between engineering and adjacent functions is not only a labor-market artifact. It reflects how AI has been adopted inside technology companies.
Coding assistants and agentic development tools raise the ceiling for some engineers. A senior engineer can ask a tool to draft code, tests, scripts, migration notes or implementation options. That does not remove the need for judgment. It can make judgment more valuable because more raw output appears faster.
This explains why the “AI code apocalypse” thesis has aged poorly. Engineers are not only typists of code. They decide what should be built, how a system fails, which dependency is acceptable, how a data model will age, when an AI suggestion is unsafe, and how much risk can sit behind a customer workflow. AI can help with several steps. It does not own the consequences.
The same logic can hurt adjacent functions. If a product manager’s role has been reduced to writing tickets from decisions already made elsewhere, AI and a senior engineer can compress that work. If a designer mainly produces variants inside an established design system, AI-assisted prototyping can cover more of the surface. If a marketer mostly repackages product claims, AI can produce more drafts than the company needs.
The roles at risk are the ones whose value was never made explicit.
That is the management failure inside the data. Many companies can name an engineering deliverable: a service launched, a bug closed, a reliability target hit, a model integrated. They struggle to name the product judgment, design review or market translation that prevented bad work from shipping. When budgets tighten, visible output wins.
AI makes that bias sharper because it creates plausible substitutes for work that was already poorly documented. A prototype can look finished. A product brief can sound coherent. A marketing page can read cleanly. A generated UX flow can pass a meeting where nobody is paid to notice missing edge cases.
Then the cost returns later.
The product team learns that customers did not need the feature. The sales team learns that the messaging created wrong expectations. The support team learns that the interface produced avoidable confusion. The legal team learns that a marketing claim was too broad. The engineering team learns that the shortcut created more rework than it saved.
None of that means companies should keep every old role. It means each cut should include a work-transfer note. If design headcount drops, who reviews trust, accessibility and user comprehension? If product management drops, who owns customer prioritization and roadmap tradeoffs? If marketing drops, who controls claims about AI capability? If recruiting drops, who protects managers from noisy funnels?
The engineer may be the right answer in some cases. The answer still needs to be written down.
AI-native startups show the same compression
The startup data points in the same direction, with a sharper edge.
A 2026 Harvard Business School and INSEAD working paper, “AI-Native Firms”, links Y Combinator and U.S. venture-backed startups to Revelio Labs workforce data. The authors find that AI-native firms are about 25% smaller than non-AI firms in the same industry cohort. Their engineering share is 13% greater in the abstract, and the body of the paper reports roughly 5 percentage points more engineering share in the YC sample. Entry-level workers and managers each make up about 15% less of the workforce. Senior workers are about 20% more common. Hierarchies are about half a seniority level flatter.
The paper’s strongest point is not that every AI startup is smaller. It is that the product itself can absorb work that older firms would have handled through people and hierarchy.
That matters for the Big Tech data because it gives a second mechanism. The shift is not only about internal tools making employees faster. It is also about products that move work out of the vendor’s organization. If an AI product does the work that a services team once did, the company can scale revenue without hiring the same delivery layer.
This is why a support-layer cut can look rational and still create new risk.
An AI-native startup may need fewer operations workers because the product automates the operation. It may need fewer managers because the team is smaller and more senior. It may need fewer entry-level workers because there is less routine work to assign. It may need more engineers because product capability, infrastructure, evaluation and deployment quality are the company.
That model can create impressive output per employee. It can also narrow the labor pool. A senior-heavy, engineering-heavy company draws from people who can already operate with ambiguity, tools and customer pressure. It has less room for people who learn through routine work, supervised repetition and gradual exposure to messy customers.
The result is a company that may scale product value faster than it scales people. Investors like that. Workers entering the market experience the other side.
There is also a practical limit. AI-native firms still sell to humans. They still need someone to understand customer exceptions, contracts, workflow boundaries, failed deployments and implementation pain. The smaller the support layer, the more often that work falls to engineers, founders or customer-facing technical employees.
Some startups embrace that. They hire forward-deployed engineers, solutions leads or AI deployment workers who sit between product and customer. Other companies pretend the product will make that work unnecessary until the implementation backlog proves otherwise.
The pattern is not anti-human. It is anti-vague. If a company is smaller because its product does more, the remaining human roles need clearer boundaries, not fuzzier ones.
Product and design need a new evidence file
The most exposed support functions have to change their proof of value.
For product managers, the old claim was often coordination: gather requirements, set priorities, write specs, run rituals, align stakeholders. Some of that work can shrink. The more durable claim is decision quality. A product manager should be able to show which customer signal changed the roadmap, which feature was killed, which risk was found before engineering time was spent, and which metric proved the choice right or wrong.
For designers, the old claim was often production: flows, screens, prototypes, visual polish. AI can accelerate parts of that work. The more durable claim is user understanding. A designer should be able to show where a generated pattern failed, where a user misunderstood an AI output, where accessibility or trust changed the product, and where design reduced support or compliance cost.
For marketers, the old claim was often content volume. AI has made volume cheap. The more durable claim is market truth. A marketer should be able to show which customer segment understood the product, which claim converted without misrepresenting capability, which launch material reduced sales confusion, and which words were avoided because they created legal or trust risk.
For recruiters, the old claim was often pipeline movement. AI can source, screen, schedule and summarize. The more durable claim is signal quality. A recruiter should be able to show which candidate evidence predicted performance, where AI keyword matching failed, which hiring manager hours were saved, and which interview step protected the company from a false positive.
This is not a plea for every function to become more analytical in a generic way. It is a budget defense.
If a function wants a headcount line in a smaller hiring pie, it needs an evidence file that survives a CFO meeting.
The meeting usually does not start with a theory about support functions. It starts with a backlog. A product manager leaves and the team delays backfilling the role because the roadmap feels obvious. Two weeks later, a senior engineer is rewriting a customer note, a designer is pulled in late because the generated flow confused three beta users, and the founder is deciding whether the launch claim is too broad for a regulated customer. The headcount saving is still on the spreadsheet. The work has already moved.
| Function | Weak evidence | Stronger evidence in an AI-compressed org |
|---|---|---|
| Product management | Tickets written, meetings run, roadmaps maintained | Customer tradeoffs resolved, engineering time saved, bad features killed, adoption or retention improved |
| Design | Screens produced, variants tested, brand consistency | User errors reduced, trust problems caught, accessibility defects prevented, support load lowered |
| Marketing | Assets shipped, campaigns launched, traffic generated | Claims controlled, buyer confusion reduced, qualified pipeline improved, risky language removed |
| Recruiting | Candidates screened, interviews scheduled, reqs managed | Manager hours saved, false positives reduced, candidate proof improved, offer quality protected |
| People operations | Policies written, surveys run, training assigned | Manager behavior changed, escalation paths used, AI review standards adopted, rework reduced |
The evidence file should not make support roles defensive. It should make them sharper. A role has to protect a cost, create a decision, reduce a failure, or help the technical core spend more time on work only it can do.
That is a higher bar, but it tells the company what the role protects.
Recruiters still belong in lean teams
The easiest support role to underestimate in a lean technical company is recruiting.
Ashby’s 2026 State of Startup Hiring report analyzed more than 1,200 venture-backed startups, 32,000 hires and 11 million applications. It found that more than half of startup talent teams already use AI across multiple recruiting workflows. It also found that startups involving recruiters earlier hire meaningfully faster, cutting time to hire by nearly a third at the smallest stages.
That is the counterpoint to the “founder can do it all” version of lean hiring.
In a small AI company, founder-led hiring is useful because the founder can sell the mission, assess taste and protect early culture. It becomes expensive when every role needs the founder’s calendar, every candidate needs bespoke explanation, and every rejection teaches the company nothing about its funnel. AI tools can remove scheduling and drafting work. They do not remove the need to define the role, assess evidence and close the right candidate.
The SignalFire data says the overall tech hiring pie is smaller. The Ashby data says process still matters inside that smaller pie.
Those two facts belong together. A company may hire fewer people, but each hire becomes more consequential. A senior engineer who joins the wrong team, an AI deployment lead who oversells, a product manager who cannot operate in a technical culture, or a designer who cannot reason about AI failure modes can cost more than the salary line shows.
Recruiting work also changes when AI enters the org chart. The recruiter has to ask whether a role is a tool-user role, an output-review role, a workflow-owner role, a product-seller role or a system-builder role. The recruiter has to translate that answer into a screen the hiring manager can defend. The recruiter has to keep the market signal clean when candidates and employers both add AI words too quickly.
That is not coordination. It is quality control for the org chart.
For founders, the practical question is not whether to hire a recruiter early. It is when the founder’s hiring hours become more expensive than a recruiting owner who can build a repeatable process. The trigger is not headcount alone. It is role ambiguity, offer delay, interview load, candidate quality noise and founder time.
If the startup can name those costs, the first recruiter becomes easier to justify.
Manager span hides the missing work
SignalFire also reports flatter org charts. Engineering manager span has risen from around 10 direct reports to 12, while entry-level hiring has fallen. The exact numbers matter less than the direction: fewer layers, wider spans, fewer beginners.
That structure looks efficient on a slide. It is harder in the week.
A manager with 12 senior engineers can survive if the team has clear architecture, strong documentation, mature incident practices, and people who can use AI tools without flooding the review queue. A manager with 12 mixed-level employees, fewer product partners and more AI-generated output has a different job. They must review more work, explain more tradeoffs, coach more judgment and notice more failure modes.
Microsoft’s 2026 Work Trend Index puts numbers around that management layer. Microsoft says organizational factors such as culture, manager support and talent practices account for twice the reported AI impact of individual effort alone. Frontier Professionals in its survey were more likely than other workers to say their manager openly uses AI, sets quality standards for AI work, creates space for experimentation and encourages ambitious work redesign.
That is a manager workload, not a slogan.
If a company removes adjacent support roles and increases manager span, the manager becomes the pressure point. They inherit product translation, quality standards, AI review norms, career coaching, incident triage and hiring calibration. AI may help them summarize, draft and analyze. It can also create more material to inspect.
SHRM’s July 2026 workplace research shows the same pattern from the worker side. Across 5,875 U.S.-based workers, 41% reported using AI at work. Among workers in organizations with AI in the workplace, an average of 46% of their work involved AI assistance. The share was 34% for individual contributors, 49% to 50% for managers depending on the report display, and 63% for directors and above.
Managers and directors are not bystanders. They are deeper in the AI workflow.
That means manager span needs a new calculation. It cannot be only number of direct reports. It needs to include review load, AI-output surface area, number of unsupported functions, customer exposure, junior ratio, incident frequency and hiring load.
A team with 12 senior engineers, a strong product partner and a clear design system is one structure. A team with 12 engineers, no product manager, no designer, two AI agents in the workflow, customer commitments and three new hires is another.
They should not share the same span target.
Role-compression audit for the hiring plan
A hiring plan should now include a role-compression audit.
The audit does not need to be complex. It needs to prevent the company from pretending that a frozen role equals disappeared work.
| Audit field | Question for the hiring plan |
|---|---|
| Function | Which role or function was reduced, frozen or delayed? |
| Work transferred | Which tasks moved to engineers, managers, founders, AI tools, agencies or customers? |
| AI task shift | Which part of the task is now drafted, summarized, ranked, generated or automated by AI? |
| Human owner | Who is accountable when the work affects product quality, customer trust, hiring decisions or compliance? |
| Manager span | Did the cut increase review, coaching, hiring or incident load for a manager? |
| Entry-level effect | Did the company remove routine work that used to train junior employees? |
| Customer risk | Which customer promise, workflow or support burden could break if the work is under-owned? |
| Candidate proof | If the company hires later, what evidence will show a candidate can own the compressed work? |
| Support budget | Is a specialist hire, contractor, agency, tool or manager capacity cheaper than pushing the work to engineers? |
| Failure signal | What event would prove the role was cut too deeply? |
This file turns the org chart from a headcount list into a work map.
It also gives CFOs a better question. A product manager, designer, marketer or recruiter does not need to win a “nice to have” debate. The useful test is whether removed work now costs more inside another person’s calendar, or inside customer churn, engineering rework, poor hiring, compliance risk or lost learning.
Some cuts will still be right. A company may have had too many coordinators, too many meetings, too many handoffs and too little technical ownership. AI can expose that. It can help a smaller team move faster.
But the audit catches the false savings. If a senior engineer spends 20% of their week doing customer translation because no product or solutions partner exists, the company should count that. If managers have wider spans and more AI-assisted work to review, the company should count that. If new grads cannot get hired because routine work is gone, the company should count the future talent cost.
The role-compression audit is not a defense of the old org chart. It is a way to build a new one without hiding work.
Junior workers need a path through the narrower chart
The most durable cost may sit outside this year’s budget.
SignalFire says new grad and entry-level hiring has fallen roughly 65% at Tech Majors and about 76% at early-stage startups compared with 2019. PwC’s 2026 Global AI Jobs Barometer adds another layer: AI-exposed junior roles are seven times more likely than the least AI-exposed junior roles to require traditionally senior skills such as leadership. Skills in the most AI-exposed jobs are changing more than twice as fast as in the least exposed jobs.
Those two findings belong in the same paragraph. Companies are hiring fewer beginners, and the beginner roles that remain often ask for more senior judgment.
That is efficient only if the labor market can produce senior people without giving juniors a place to become senior. It cannot do that indefinitely.
AI changes the apprenticeship model because it removes or accelerates the routine work that taught people how systems, customers and organizations behave. A junior engineer who no longer writes simple code may still need to learn why a simple change breaks production. A junior designer who can generate a flow still needs to learn why users misunderstand it. A junior product manager who can summarize customer calls still needs to learn which complaint matters. A junior recruiter who can screen with AI still needs to learn when a candidate is performing fluency rather than demonstrating skill.
The smaller org chart therefore needs deliberate learning work.
That may mean protected review rotations, AI-output QA assignments, customer-shadowing time, incident writeups, red-team reviews, paired product discovery, or apprenticeship projects that cannot be justified by immediate output alone. It may mean fewer entry-level hires but better designed entry-level work. It may mean paying senior employees for mentorship rather than treating it as unpaid overflow.
This is where BCG’s 2026 AI at Work survey is useful. BCG found that 74% of frontline employees are regular AI users, and 42% of regular frontline users report saving eight hours a week. But 66% receive limited or no guidance on what to do with the time they save. Close to three-quarters of respondents say skill expectations have shifted, while only 36% feel adequately upskilled.
Those are not only frontline problems. They describe the same failure mode in technical organizations: tools move faster than work design.
If companies want senior-heavy teams, they need a source of senior people. If they want AI-fluent workers, they need places where workers can build judgment with supervision. If they want smaller teams, they need clearer decisions about which work belongs to tools, which work belongs to engineers, and which work still needs a person whose title may not look technical.
The July 11 chart is useful because it makes the compression visible. It does not prove that every support cut was wrong. It proves that the next hiring plan needs a better accounting system.
The engineer is taking a larger slice of a smaller pie. A hiring plan still has to say who handles the customer, the screen, the candidate and the junior worker when the missing support role no longer appears on the spreadsheet.
Published July 12, 2026.