Framework: The CTO Manifesto
- Description: This is your set of core engineering and leadership principles. It serves as a North Star for the department, ensuring that when the team faces a fork in the road, they know which path aligns with your shared values without needing to ask for permission.
- Origin & Attribution: While many CTOs write their own, the concept is heavily influenced by the Agile Manifesto (2001) and The Twelve-Factor App.
- Context & Heritage: This evolved from the need to move away from rigid, top-down policy manuals toward culture-driven leadership. It draws on the idea of Commander’s Intent from military strategy, where the goal is clear, but the execution is left to the people on the ground.
The Framework
- Engineering Excellence: Define what quality looks like. This usually includes principles like "Automate everything that moves" or "Security is everyone's job, not a department."
- Business Alignment: Explicitly state that technology exists to serve the customer. A common principle is "Build for the user, not for the resume," which discourages over-engineering for the sake of using shiny new tech.
- People & Culture: Set the tone for how the team interacts. This might include "Blameless post-mortems" or "Default to transparency."
- Operational Discipline: Define the baseline for reliability. Principles like "You build it, you run it" (DevOps culture) or "Uptime is a feature" belong here.
Metrics & Success Indicators
- Quantitative Metrics:
- Decision Speed: The time it takes for a team to resolve a technical disagreement by referring to a manifesto principle.
- Cultural Pulse: Survey results showing how many engineers can actually name or apply the core principles in their daily work.
- Qualitative Success Indicators:
- Autonomy: You start seeing teams make "the right" technical calls independently because they are following the manifesto.
- Consistency: Even as the team doubles or triples in size, the codebases and cultural rituals still feel like they belong to the same organisation.
Prerequisites & Dependencies
- Authenticity: The manifesto must reflect reality or a visible goal. If you say you value "Work-Life Balance" but ping people on Slack at 11 PM, the document is useless.
- Broad Buy-in: Don't write this in a vacuum. Draft it, then workshop it with your lead engineers to ensure they actually believe in it.
Customisation (How to Fork)
- For Early-Stage Startups: Keep it to 3–5 high-impact bullet points. Focus on speed and agility.
- For Scale-ups: Focus on "Scalability" and "Communication." Add principles that address how teams interact as silos begin to form.
The Translation Layer (Communication)
- To the Board: I am codifying our engineering culture to ensure we maintain high output and quality as we scale.
- To the Engineers: I am giving you a clear framework for making decisions, so you have the autonomy to move fast without breaking our core standards.
Similar Frameworks & Tools
- Other Options: Amazon’s Leadership Principles; The Zen of Python (for a more code-centric version).
- Good Tools: Use a shared README in a "culture-repo" or a dedicated page in your internal documentation hub.
Recommended Reading
- The Agile Manifesto: The original blueprint for value-based technical leadership.
- Turn the Ship Around! (L. David Marquet): Essential for understanding how to give control to the team through clear principles.
Summary (TL;DR)
A manifesto isn't a rulebook; it is a values-book. Use it to align your team’s "gut feeling" so they make the same decisions you would make, even when you aren't in the room.
Action Plan
- Immediate Step: Write down the top 3 technical "hills you are willing to die on." These are your first three principles.
- Information Gathering: Ask your best engineers what they think the "secret sauce" of the team is right now.
- Core Focus: Keep it short. If the manifesto is longer than a single page, no one will remember it, let alone follow it.