Key Insights
Technical debt is visible, but structural debt is far more dangerous
Many organizations point to outdated technology stacks as the primary hurdle to transformation, but this focus is misplaced. In regulated environments like banking, where layers of compliance are necessary, complexity is a given. But even there, excessive processes and ambiguous ownership can compound inefficiency. Drawing from experiences in both startups and enterprise environments, Brian explains that process failures and poor organizational design often create far more friction than legacy systems. He recounts working with teams that had access to modern tools but couldn’t ship because they lacked clear structure, role clarity, or maturity in their delivery processes. Technical debt is visible, but structural debt is silent and far more dangerous.
Don’t build your org chart around individual talent
As organizations scale, it’s tempting to design teams around high-performing individuals who wear multiple hats, but Brian cautions against this approach. Companies often struggle when a key person is promoted, exits, or shifts roles, disrupting both strategy and delivery because their role was never part of a scalable structure. Instead, the org chart should be designed based on roles and responsibilities that are sustainable regardless of who fills them. This enables succession planning, onboarding, and operational consistency. Senior decision-makers facing team growth or transformation should view this as a structural safeguard: build for the role, not the resume.
To scale development, separate build from operate
Many mid-sized companies default to having their developers handle both feature delivery and production support. The cost of this setup? Constant context-switching that breaks developer focus and undermines both delivery speed and incident response. Brian explains that most production issues stem from operational breakdowns (expired certificates, deprecated APIs, or network failures) rather than code defects. Developers pulled into triage often end up chasing issues unrelated to their own work. By separating build and operate functions, and only escalating true bugs to developers, organizations can maintain flow and accountability in both domains.
Episode Highlights
Lessons from a Startup That Scaled
Brian reflects on his early days in startups, where his motivation was to build new technology and avoid becoming the kind of leader who didn’t understand the work. The segment outlines how that mindset shaped his approach to team-building and cross-functional leadership across roles like QA, project management, and application support.
“I had a lot of bad leaders, you know, and I didn’t want to be that guy. I wanted to be someone that actually knew what they were talking about, you know, when I finally got to the top of hill.”
The Best Idea Wins
Brian shares how creating a culture of idea-sharing can elevate good ideas into great ones, especially when junior team members are empowered and credited. It’s a simple but strategic approach to unlocking innovation across engineering teams.
“If it’s the co-op, have the humility that, you know what, the co-op, he’s got a great idea, let’s make it happen and give the guy some credit.”
Work Design Before People
As teams scale, Brian cautions against building around strong individuals instead of sustainable structures. Designing roles for people, rather than business needs, creates fragility and triggers unnecessary reorgs.
“Design the org structure that makes sense and then you can put people in it.”
Context Switching Kills Developer Flow
Brian describes how combining build and operate responsibilities in smaller companies may seem efficient but often derails developers. The constant interruptions—usually caused by operational issues, not bugs—make it nearly impossible to maintain focus.
“You’re a developer and you’re in the flow, man… and then, oh shoot, there’s an alert. Okay, forget that.”
Why Everyone Needs Time Off
Brian shares a vivid example of how perspective and rest improve performance. While engineers were burning out trying to fix a broken build, it was a returning teammate on vacation who solved it in 20 minutes—with fresh eyes.
“Some guy’s on vacation. Right? Comes back, has coffee, sits down within 20 minutes he’s like you missed a semicolon.”
