How I structure and lead engineering organizations — the operating model behind the results.
01
Squads organized around missions, not technologies: each team owns a slice of product outcome with clear interfaces to the rest. I have led organizations from 3 teams (27 people) to cross-functional squads of 80+, always balancing autonomy with alignment. Staffing follows the architecture — Conway’s law is a tool, not a trap.
02
A single prioritized roadmap connecting business goals to engineering capacity, reviewed biweekly with stakeholders. Technical debt, platform work and product features compete transparently in the same backlog — which forces honest conversations about trade-offs instead of invisible erosion.
03
Architecture Review Boards with teeth but no bureaucracy: decisions documented as ADRs, significant changes proposed as RFCs, reusable solution templates that cut delivery time across teams. At Crefisa this model reduced both delivery time and infrastructure cost for financial-services squads.
04
Delivery cadence, lead time, incident trends, cost per workload and quality indicators — visible to the team and to the business. Metrics exist to drive conversations, not rankings. What gets measured honestly gets improved sustainably.
05
Ownership, written communication and blameless learning. Documentation as a first-class deliverable: design.md before building, ADRs when deciding, postmortems when failing. AI-assisted development with human review and quality gates — productivity with governance.
06
Translating between engineering and business is the core of the job. Executives get risk, cost and time in their language; engineers get context and stable priorities in theirs. Bad news travels fast, with options attached.
The result of this operating model: predictable delivery, auditable decisions, costs under control and teams that grow with the product. The case studies show it applied to real platforms.
Explore Case Studies →