The first week for a fractional CTO is not about making decisions — it is about earning the credibility to make decisions later. A CTO who walks into a company and immediately starts proposing architecture changes will spend the next three months fighting an uphill battle for trust. This checklist lives on the expert side: what a fractional CTO does in their first five days to build a complete technical picture of the company before making a single recommendation. Week-one technical access requirements: read-only access to all repositories (GitHub or equivalent), read access to CI/CD pipeline and deployment configuration, access to monitoring and alerting (Datadog, New Relic, or equivalent), read access to cloud infrastructure console (AWS, GCP, or Azure), and access to project management tool (Linear, Jira, or equivalent) to understand how the team works. Do not give production database write access until you have a written ops protocol — a mistake in prod during your second week is a bad start for the engagement. Do not give advertising or financial system access until week four — that requires trust and context about the business that takes time to build. The goal by end of week two is a written technical assessment: what is working, what is the biggest risk, and what one thing would have the highest impact to fix. Produce that assessment before trying to change anything. The worst thing a fractional CTO can do in week one is try to change things. Week one is listening: sit in sprint ceremonies, review the last 30 days of PRs and commits, read the architecture documentation if it exists.
The first week for a fractional CTO is not about making decisions — it's about earning the credibility to make decisions later. A CTO who walks into a company and immediately starts proposing architecture changes will spend the next three months fighting an uphill battle for trust. This checklist lives on the expert's side: what a fractional CTO does in their first five days to build a complete technical picture of the company before making a single recommendation. Week-one priorities include getting read access to all repositories, reviewing the last thirty days of pull requests and commits, reading any existing architecture documentation, sitting in sprint ceremonies to understand how the team works, and having individual conversations with senior engineers about the biggest technical risks they see. The goal by end of week two is a written technical assessment — what is working, what is the biggest risk, and what one thing would have the highest impact to fix. Produce that assessment before trying to change anything.
Week 1 — Access & Discovery
- Get GitHub / GitLab org access and clone main repos
- Review last 6 months of incident reports and postmortems
- Map the current infrastructure and hosting stack
- Interview each engineering team lead (30 min each)
- Review open engineering headcount and active job reqs
Week 1 — Key Questions
- What is the biggest technical risk to the business right now?
- Where does engineering consistently slow the product team down?
- What has been tried and abandoned in the last 12 months and why?
- What does the board / CEO think engineering should prioritize?
- What does the engineering team think leadership misunderstands?
Week 2 — First Deliverable
- Produce a 2-page technical health scorecard
- Flag the 3 highest-severity risks with remediation estimates
- Identify 2-3 quick wins executable in 30 days
- Propose a communication cadence with leadership
- Set explicit expectations around decision authority
Enter your email and we'll send you a formatted copy right now.