Gaz Franklin

Every pull request is reviewed by an agent before a person sees it: logic errors, test coverage, security smells, readability, and conformance to the language's current published style. It also does the thing a linter can't – it reads the original Jira ticket and checks the change actually satisfies the acceptance criteria.

It sees the work item and the diff, and nothing else. Keeping it blind to the pipeline that wrote the code stops it inheriting the author's assumptions. Every PR still gets a human review – what changed is how little of it is rubber-stamping, because the agent has usually started the argument.

Authoring is a separate in-house framework, built on BMAD and Claude Code: it takes a Jira item and a Figma design through a developer interview, writes the code, hands off to an adversarial reviewer, checks the result against the design, and raises the PR.

• QA saw a dramatic fall in defects, and time to first review came down
• Two approaches dropped before this one: Copilot, weak on our Ruby on Rails, and an Azure service behind GitHub Actions, on runaway token and runner cost
• Specified it, managed the engineer who built it, learned it well enough to keep up, and drove adoption into other teams
• The company's only AI Engineer sits in my team

Siloed thinking is one of the most common blockers I encounter – and one of the most solvable. I've consistently broken down walls between Engineering, Product, Design, and Support, replacing territorial working patterns with shared ownership and genuine collaboration.

Trust is built through consistency, transparency, and follow-through. I invest in relationships across the organisation, creating the conditions where teams feel safe to raise problems early and work together on solutions.

• Breaking down cross-functional silos and us-vs-them dynamics
• Creating shared goals and a common language across disciplines
• Building psychological safety at team and organisational level

Good engineering strategy is more than a roadmap. It's walking the line between technical decisions and business value.

I work with Senior Leadership, Product Managers, Developers, QA Engineers and Support Agents alike to define what "good" looks like, manage technical debt deliberately, and make the case for the right investments at the right time.

• Technical roadmapping and prioritisation
• Architectural decision-making and governance
• Managing and reducing technical debt

Agile done well isn't about ceremonies. It's about shortening feedback loops and making it safe to change course.

I've led delivery across Scrum, Kanban, and hybrid approaches, always with an eye on reducing waste and keeping teams focused on value.

• Sprint planning, retrospectives, and continuous improvement
• Cross-functional coordination and dependency management
• Delivery metrics, forecasting, and risk management

The best engineering teams understand the "why" behind the work. I bridge the gap between Product and Engineering, ensuring technical decisions are grounded in user value, not just technical elegance.

I collaborate closely with Product Managers and Designers to shape roadmaps, challenge assumptions, and keep teams focused on outcomes rather than output.

• Product discovery, shaping, and backlog ownership
• Outcome-driven planning over feature delivery
• Engineering input to design, research, and strategy; no more siloed thinking

Engineering teams don't operate in isolation. I focus on building trust with stakeholders through transparency, proactive communication, and a shared language between technical and non-technical audiences so that expectations are set correctly and surprises are rare.

Expectation management is key; I offer clear communication skills in every situation and aim to provide clarity in every discussion. Trade-offs are clearly defined and conflict resolution is based on shared goals.

• Executive reporting and board-level communication
• Cross-departmental alignment and negotiation
• Translating complexity into clear, actionable updates