The Engineer of 2026
The Team Shape That Actually Captures the AI Opportunity
Most companies think their biggest AI challenge is technology. It’s not. It’s people; specifically, how they’re organizing, hiring, and thinking about the engineering teams that are supposed to deliver on all those AI investments.
I’ve watched this play out across organizations of all sizes, from Fortune 500 to growing mid-market companies, and the pattern is consistent: the tools are getting adopted, but the team structures haven’t changed. That gap is where transformations stall.
This is my first post on Substack, and I’m excited to finally have a place to share what I’ve been seeing in the field. I have a software engineering degree and spent eight years at Bank of America, moving from engineer to lead to senior, building data and analytics systems at a scale most people don’t get to touch early in their career. Then five years at Slalom, consulting across banking, energy, fintech, logistics, and travel. Data pipelines, software platforms, AI systems. Rooms full of smart people trying to solve hard problems with technology.
For the last three years, I’ve been living inside the GenAI wave: building RAG systems, agentic workflows, running AI enablement workshops, and helping engineering teams actually absorb these tools into the way they work. Not in theory. In production. These are the patterns I keep seeing, and what I think you should do about them.
The New Shape of the Engineer
The engineer who thrives in this era doesn’t just write code; they scope problems. They build working prototypes in days, not sprints. They put on a product hat, ask “what are we actually solving for,” and then reach for the right tool from an increasingly massive toolbox: the right model, the right orchestration layer, the right retrieval strategy, the right evaluation framework.
The best engineers I’ve worked with recently remind me less of the 10x coder archetype and more of a technical product owner, someone who can move from problem definition to working demo to architectural recommendation without needing six layers of handoffs.
That’s a different profile. And most job descriptions, whether at a 50-person company or a 5,000-person one, still haven’t caught up to it.
You Don’t Need a Large Team. You Need the Right One.
This is where things get genuinely exciting, especially if you’re running a small or mid-sized business.
The old model was simple: big projects required big teams, long timelines, and large budgets. That kept a lot of ambitious ideas on the shelf for companies that couldn’t compete with enterprise-level headcount.
That model is breaking down.
I’ve seen teams of three or four engineers ship what used to take fifteen, when they’re properly equipped and AI-augmented. More importantly, I’m seeing a new engagement model emerge: small, focused teams assembled for a specific problem, for a defined period of time, that come in, build, and deliver. No bloated retainers. No year-long projects that lose momentum halfway through. Just sharp execution against a clear outcome.
For small and mid-sized businesses, this is a massive unlock. You don’t need to hire a full engineering department to build something meaningful. You need the right three people, the right tools, and a clear problem to solve.
The right frame isn’t headcount. It’s leverage. What gets built when your best people are no longer blocked by the tedious 70%? What becomes possible when you can spin up a capable team for twelve weeks instead of twelve months?
That’s the conversation worth having.
Flatten the Hierarchy, But Keep the Adults in the Room
Something interesting is happening at the senior technical leadership level. Workday’s CTO left the role to join Anthropic, not as an executive, but as a member of technical staff doing hands-on reinforcement learning engineering. Instagram’s co-founder and CTO made a similar move, stepping away from a CPO title to get back into building. These aren’t people who got pushed out. They’re choosing proximity to the work over the title.
That’s a signal worth paying attention to at any company size. The leaders who understand what’s being built right now, because they’re building it, are the ones making good decisions. The ones who are purely in PowerPoint mode are flying blind.
At the same time, flatten doesn’t mean flatten everything.
You still need the grown-ups. Senior engineers and architects who have seen systems fail at scale, who understand what “this will become a compliance problem in six months” looks like, who can tell a junior engineer why the clever solution is actually the dangerous one. That pattern recognition doesn’t come from a model. It comes from scar tissue.
For smaller companies especially, this person is often the difference between a project that ships and one that quietly becomes technical debt.
The Unsung Hero: The Platform Engineer
If there’s one role I’d bet on being consistently in-demand for the next decade, at every company size, it’s the platform engineer.
DevOps, Cloud, SecOps: the people who build the rails that everyone else runs on. As AI-generated code increases in volume and velocity, the need for guardrails, observability, cost controls, and security policies doesn’t decrease; it multiplies.
Who governs what models the org can use? Who sets the infrastructure guardrails for agentic systems that are spinning up compute dynamically? Who owns the audit trail when a GenAI system touches sensitive data?
Platform engineers. And right now, there aren’t enough of them. For smaller businesses without a dedicated platform function, this is often the hidden risk in their AI ambitions. Building fast without guardrails is how you end up with systems nobody trusts.
What This Means for You
Whether you’re running a ten-person startup, a mid-sized company trying to move faster, or a larger org feeling the pressure to modernize, the question is the same: are you building the team shape that actually captures the AI opportunity?
That means investing in engineers who can think across the full problem stack. It means embracing the model of small, focused teams with clear mandates and short timelines. It means making sure someone senior is in the room to catch what the tools can’t. And it means protecting your platform and security function even as you accelerate everything else.
The org chart designed for 2015 won’t get you to where you need to go in 2026.
I’ve been in the trenches of this transformation, and now working on helping companies of all sizes navigate exactly this. The teams that move well aren’t the ones with the most AI tools. They’re the ones who’ve thought clearly about the humans around the tools.
That’s still the hard part. And it’s still worth getting right.
This is the first of many posts where I’ll be sharing what I’m seeing at the intersection of AI, engineering, and business transformation. If you’re thinking through what your engineering org needs to look like in the AI era, whether that’s team structure, tooling strategy, or enablement, I’d love to compare notes. Subscribe, reach out, or leave a comment below.