Yesterday evening, I headed to spARK Labs to attend the CTO School Tampa Bay meetup to catch their session, Lessons in Scaling Engineering Teams with Leon Kuperman of CAST AI, where organizer Marvin Scaff conducted a “fireside chat” with CAST AI’s CTO.
Leon Kuperman has over 20 years of experience, having been Vice President of Security Products for Oracle Cloud Infrastructure (OCI). This role followed Oracle’s 2018 acquisition of Zenedge, a cybersecurity and Web Application Firewall (WAF) company where Kuperman was Co-Founder and CTO. Prior to that, he had leadership roles at IBM and Truition. He’s widely recognized for his expertise in cloud computing, web application security, and engineering leadership.
CAST AI is a Miami-based cloud automation platform that optimizes Kubernetes clusters using AI, founded back in the pre-GPT (and pre-COVID) era, in 2019. They recently launched OMNI Compute, a unified control plane that allows organizations to access compute resources (specifically GPUs for AI workloads) across different cloud providers and regions seamlessly. Just this month, they joined the “three comma club” and hit a valuation of over $1 billion.
My original plan was to arrive early, but a combination of last-minute calls and making the cross-bay journey led to my missing the first half hour of the talk.
Still, I took some notes, and I’m sharing them here. I hope you find them useful!
The fireside chat with Leon Kuperman
Marvin and Leon’s chat was a compressed master class in managing a software engineering organization. They walked through what it takes to scale engineering without losing velocity, drawing on lessons from building CAST AI (now at around 160 engineers) and Leon’s earlier BigCo experience, including at IBM and Oracle.
I caught three-quarters of the talk, which included:
- Engineering leadership and team structure
- Unifying product and engineering
- Hiring, culture, and performance management
- DevX and DevOps
- AI tools and the future of coding
- Advice for founders and startups: moats, funding, and being lean
I also have a quick summary at the end.
Engineering leadership and team structure
Scaling needs structure, especially especially distributed teams. Leon framed “scale” as a move from informal coordination to explicit systems. Rather than adding bureaucracy for its own sake, his approach is to add just enough structure to prevent chaos when the team is remote and distributed.
The “two-pizza team” model: Amazon popularized the “two-pizza rule,” a general guideline that teams work best when they’re small enough that two pizzas will feed them. This typically means a team size of 10 people or fewer. CAST AI teams are “two-pizza” teams, and most teams are dedicated to a specific scope.
A deliberately flat hierarchy: Leon described a simple reporting chain leading up to him: directors → VP Engineering → Leon. Despite scale, he aims to stay close to reality by interacting with every team at least every two weeks, and often weekly.
Peter Principle was (the younger ones in the room didn’t, probably because it’s an idea that was popular in the 1970s-80s). He talked about how people get promoted into roles they’re not suited for, and then get stuck because nobody ever goes back to IC.
CAST AI’s answer is a “manager candidate” program, where a prospective manager is assigned a small pod, where they get the chance to “do the job before you get the job” for about six months. If the candidate is a fit, they retain the manager role, otherwise, they return to an IC role with “zero repercussions” and no stigma.
Common leadership failure modes: Leon highlighted the usual suspects, including micromanaging, weak delegation, and not building motivation through mentoring. He also stressed that trust is built through honesty and vulnerability, as people won’t fully commit to a leader who presents as a “robotic individual.”
Unifying product and engineering
“If I fail, I fail.”
CTOs must be both “product people” and “customer people.” Even for introverts, he argued this is non-negotiable: a CTO needs the customer context to make good product/engineering tradeoffs.
Planning: vision is long-term; execution is short-loop. He rejected long-range roadmaps as fantasy (“estimates are always wrong”) and described a system of:
- Quarterly OKRs
- Frequent priority reviews (about every two weeks) to stay aligned with customer needs
- An overall bias toward time-to-market as the top validation lever
Hiring, culture, and performance management
Dunbar’s Number), you need explicit performance management to avoid letting mediocrity hide in the system.
don’t want, while also being willing to move on from sustained underperformance.
Hiring rigor; culture “deep dive.” CAST AI’s hiring loop includes:
- Five interviewers
- A technical exercise (preferably collaborative/live)
- A culture check where each interviewer probes one value deeply
He gave a concrete example using “customer obsession” as a trait: asking for times someone pushed back internally to fight for the customer, and treating “not really” as a signal of poor fit.
Foundational CS > language trivia. In the Q&A session, Leon emphasized hiring for fundamentals, such as distributed systems and concurrency, because those are hard to fake (and languages can be learned fairly quickly).
DevX and DevOps
DevEx is a scaling strategy, not a perk. Leon explicitly dismissed vanity metrics and refocused on developer experience quantities that matter: friction in onboarding, docs, local dev, and pipelines is what slows teams down. CAST AI has a dedicated DevEx team of four focused on removing that friction.
Measure friction with DevEx + DORA-style signals. (by the way, DORA is short for “DevOps Research and Assessment”). He described using GetDX to produce quarterly “heat maps” of where developers are least happy, then prioritizing platform work to make those pain points “not suck.”
“The antidote to change risk is more change.” A highlight of the evening: Leon pushed back hard on enterprise “change approval board” thinking. Enterprises lock down change because change causes incidents; his view is that the remedy is smaller changes released faster, backed by automation so that rollback is quick and boring.
Automated quality, modern delivery, and canaries. At their release cadence, manual QA doesn’t scale. Leon said they do zero manual testing (no QA team), rely on automated checks (including AI “first-pass” checks), and called out Argo CD for Kubernetes delivery plus canary testing as the next level of release management.
Blameless root cause analysis and “5 Whys”: When things break, Leon described a blameless postmortem discipline, where they enforce psychological safety, run an honest “5 Whys,” produce near-term action items, and ensure everyone is heard. No finger-pointing!
He reinforced the mindset later: “It’s the process that broke, not the guy.”
AI tools and the future of coding
Tool adoption is becoming a performance separator. Leon’s framing: engineers who don’t adopt strong tools and absorb best practices will get outpaced, even by “average” engineers who do.
Claude Code, expense, and velocity: In the founder funding discussion, Marvin referenced that tools like “Claude code” are “expensive… a couple hundred bucks per person per month,” but enable teams to ship quickly.
GSD (short for “Get Shit Done”) as a workflow aid and “context manager” style approach—breaking work into phases to reduce context-window pain and keep momentum.
Writing skill as a proxy for critical thinking. One of the spiciest takes: Leon said he “over-indexes” on writing. Bullet points aren’t enough; if you’re writing something for him, he wants narrative because it reveals whether someone can truly reason and communicate. He also suggested using LLMs to critique your own documents (first-principles critique, “strawman” the argument) to find logic holes before presenting.
Advice for founders and startups: moats, funding, and being lean
Competing isn’t about coding faster; it’s about differentiation. Leon argued that competitors are a symptom; the real challenge is building differentiation that holds even if someone else has more resources.
Peter Thiel’s (ugh, ugh, ugh) book, Zero to One (still worth a read, with some caveats), and described three defensibility paths:
- Network effects
- Economies of scale
- Data moat
He then explained CAST AI’s “data moat” concretely: a read-only agent collects cluster state/events continuously, creating a unique multi-cloud vantage point used to train algorithms. It’s something that individual hyperscalers can’t replicate as easily.
Raise funds to scale a working flywheel, not to “find it.” Leon advocated staying lean and bootstrapping where possible, warning against raising money “to compete.” Instead, raise when you’ve hit an inflection point and want to scale what’s already working.
first customer signal and getting validation before building for scale.
Summary: The “scaling engineering teams” playbook Leon kept returning to
As I said at the beginning, this talk was a compressed master class in managing a software engineering organization. Here’s the evening’s “tl;dr” that condenses Leon’s approach:
- Small, service-owned teams, with a deliberately flat hierarchy
- Safe leadership experimentation, with manager trials and no stigma for returning to IC
- Product/engineering alignment by design, whereone escalation path, one accountability point)
- Performance management as culture, not an HR afterthought
- DevEx investment (measure friction, fix pipelines, improve onboarding/docs)
- Ship faster to reduce risk (automation + small changes + rollback discipline; avoid CABs)
- Modern delivery mechanics (Argo CD, canaries, automated checks, no manual QA bottleneck)
- Tooling + writing discipline as force multipliers (LLMs + narrative thinking)
CTO School Tampa Bay
This was my first experience with CTO School Tampa Bay, which bills itself as “a group of CTOs, VP of Engineering, Tech Leads, and technologists who would like to become leaders.” It’s organized by Marvin Scaff, Cassandra Bernard, and Daniel James Scott.
This meetup group is a little more exclusive, with membership is by approval and organizer referral, and it’s limited to technical people only. If you’re a senior tech leader or on the path to becoming one (say, a tech lead or senior developer), you’re eligible.
Their goal? To provide a forum where tech leaders can exchange ideas and have discussions about tech, process, management, or whatever issues affect them during this highly accelerated period in the industry.