Ben Ede shares practical lessons from leading engineering teams at scale. AI should enhance engineers, not replace them. True CI/CD is about confidence and reliability, not just speed. Smaller tickets improve delivery, quality, and team morale. Tech debt should be managed intentionally using risk-based decisions. Strong communication, well-structured processes, and the willingness to ask basic questions are what keep engineering, product, and business aligned.
This conversation is grounded in real experience: scaling teams, inheriting existing systems, navigating tech debt, improving delivery quality, and figuring out how AI fits into modern software development without losing engineering rigor.
Below is a detailed breakdown of the most important lessons, frameworks, and practical insights straight from the episode.
Ben Ede’s Career Shift: Why Bigger Was the Right Move
Ben opened by sharing a pivotal career realization. For most of his career, he gravitated toward early-stage startups – typically seed to Series A – where teams needed structure, leadership, and culture-building. But after turning down a role that was a “perfect fit on paper,” he realized something was missing.
The last time he was truly energized was at Seven Bridges, a logistics startup he helped found. Over seven years, the company grew to a point where Ben had engineering managers under him and constant new challenges landing on his desk. That pace – and that sense of impact – was what he loved.
That realization led him to consider larger companies for the first time. Through a recruiting consultant and an honest conversation about his experience, Envoy ultimately created a role specifically suited to his background.
Key takeaway: Career progression isn’t always about going smaller or more senior. Sometimes it’s about finding the scale where your impact and enjoyment peak.
What Envoy Does – and Why In-Person Matters
Most people know Envoy for visitor management – signing in at kiosks and printing badges. But the platform goes much further, including workplace management tools, screens, and emergency notification services.
Envoy operates with a four-days-in-office model across its global locations. For Ben, this isn’t just a policy – it’s a strategic advantage.
He shared that being in person enables:
- Faster problem-solving
- Spontaneous collaboration
- Fewer formal meetings to solve small issues
Drawing from his experience as a remote CTO at Seven Bridges, Ben explained how a single week in-office could generate a month’s worth of progress simply because engineers could overhear problems, connect dots, and solve issues on the spot.
Key takeaway: Remote work can function, but in-person environments dramatically reduce friction – especially for complex engineering collaboration.
Engineering Team Structure at Envoy
Ben currently oversees:
- 18 engineers
- 3 teams
- Multiple engineering managers who run their own teams
The teams follow standard sprint-based development with established rituals. While the structure itself isn’t unusual, Ben’s leadership philosophy is clear: empower managers, focus on process clarity, and remove unnecessary stress from engineers.
AI in Engineering: Enablement, Not Replacement
Ben laid out a practical, realistic view of AI in software development – one that avoids hype without dismissing progress.
He described an evolution:
- AI-assisted thinking – Using tools like ChatGPT or Claude to break down problems
- AI-enabled coding – AI writing meaningful portions of code
- AI orchestration – Engineers coordinating multiple AI agents like a conductor
While the vision is compelling, Ben emphasized that we’re not there yet. Quality issues and hallucinations remain real risks. He’s also skeptical of claims that general AI will replace engineers in the near term.
Instead, he believes:
- Engineers will get significantly more productive
- Prompting skills will continue to improve
- Strong engineering fundamentals will matter even more
AI doesn’t eliminate the need for engineers – it raises the bar.
Key takeaway: AI amplifies good engineers; it doesn’t replace them.
Redefining CI/CD: Confidence Over Speed
One of the most practical segments of the episode focused on CI/CD – and how misunderstood it often is.
When Ben joined Envoy, each team had its own interpretation of CI/CD. His first step wasn’t tooling – it was alignment.
For Ben, CI/CD means:
- Code is merged into trunk only after tests pass
- Trunk is always deployable
- Deployment confidence replaces deployment fear
The real goal isn’t faster releases – it’s confidence. When teams trust their process, deployment becomes a business decision rather than an engineering fire drill.
Progress has been gradual. A principal engineer was brought in to help guide teams through the transformation, and while it’s still early, the signals are positive – especially around reliability and predictability.
Key takeaway: True CI/CD removes stress from engineers and gives the business flexibility.
Smaller Tickets, Better Outcomes
One of Ben’s strongest philosophies centers on aggressively reducing ticket size.
In a previous role, he inherited a system where tickets were routinely estimated at 8-13 points – and then dragged across multiple sprints. The issue wasn’t technical skill; it was lack of shared understanding.
Ben introduced structured communication points:
- Product spec presentation – Engineers hear the “why” and ask questions early
- Technical design phase – Small group designs the solution
- Design review with the full team – Engineers critique, clarify, and align
By the time sprint grooming happened, everyone understood the system deeply enough to break work into meaningful, bite-sized pieces.
The result:
- Ticket sizes dropped to 2-3 points
- Large tickets became a clear signal to split work
- PRs became smaller
- Quality improved
- Engineers felt more productive and motivated
Ben even shared that productivity doubled – before AI entered the picture.
Key takeaway: Small tickets aren’t about control; they’re about clarity and momentum.
Engineering Metrics: Use Signals, Not Scorecards
When it comes to metrics, Ben takes a cautious approach.
While DORA metrics are a common default, he doesn’t rely on them blindly – especially for smaller teams where noise can outweigh insight.
Instead, he looks at metrics as signals, not judgments:
- PR cycle time
- Mean time to resolution
- Patterns that indicate bottlenecks or oversized work
But above all, he still prioritizes direct communication over dashboards.
Key takeaway: Metrics should guide conversations, not replace them.
The Run-Grow-Transform Framework
For quarterly planning, Ben uses a simple but powerful model:
- Run (≈45%) – Keep the lights on, fix issues, maintain reliability
- Grow (≈45%) – Expand and enhance existing features
- Transform (≤10%) – Foundational bets that shift the future
Transform work is intentionally limited. Too much of it signals imbalance and usually leads to overengineering.
Ben also warned against engineering teams re-architecting too early – something he admitted he did himself earlier in his career.
Key takeaway: Discipline in planning prevents premature complexity.
A Mature Take on Tech Debt
Ben’s relationship with tech debt has evolved – from avoidance, to frustration, to acceptance.
His current philosophy:
- Tech debt isn’t inherently bad
- What matters is when and how you address it
Two strategies stood out:
- Opportunistic cleanup – Address low-risk tech debt while building new features
- Risk-based acceptance – Leave tech debt in place if it poses no security, scaling, or reliability risk
At Envoy, this mindset even extends to vulnerability management. Not all CVEs deserve the same urgency – context matters.
Key takeaway: Tech debt is a tool. Use it intentionally.
Alignment Without Endless Meetings
Ben doesn’t avoid meetings – he optimizes them.
High-quality meetings:
- Have a clear purpose
- Include the right people
- Enable two-way communication
Poor meetings, he argued, are usually a symptom of broken processes elsewhere.
For Ben, communication is the single most important skill in engineering leadership.
Final Advice: Ask the “Stupid” Questions
Ben closed the episode with simple but powerful advice:
Ask stupid questions.
Too many people stay silent to avoid looking uninformed – slowing teams down in the process. Confidently asking basic questions often unlocks clarity for everyone in the room.
Steve echoed this sentiment, sharing his own habit of openly asking to be educated.
