Senior to Tech Lead
From an engineer who writes the code to a leader accountable for the team's technical direction.
This program is planned and not scheduled yet. No date, price or cohort has been announced. If you register interest, we contact you when it is scheduled or to discuss an individual format.
Objective
The program helps a senior engineer build the habits needed to own a team's technical direction: recording decisions, carrying quality standards to the team, planning work under uncertainty and leading calmly during an incident. The focus is the shift from your own code to the team's outcome.
Who it's for
- Senior backend engineers who already have technical influence and face a formal or informal lead role
- Newly appointed tech leads looking for a structured approach
- Engineers who want to systematise mentoring and the code review process
- People who struggle to explain technical decisions clearly to the business side
Who it's not for
- Those who have not yet consolidated backend fundamentals (Java, Spring Boot, SQL); senior-level programs fit better first
- Those who want the administrative side of people management (employment, compensation, hiring rules); this program focuses on technical leadership
- Those looking for a ready template to adopt a role; the program rests on practice and case analysis
Prerequisites
- Several years of backend experience on a real product
- Experience taking part in Pull Requests and code review
- Familiarity with core system design ideas (scaling, consistency, caching)
- Readiness to explain one technical decision from your own project
What you will be able to do
What you will be able to do
- Prepare a technical direction document and a justified roadmap for the next quarter
- Record a significant decision as an ADR with alternatives and consequences
- Turn review rules and a Definition of Done into standards agreed with the team
- Present estimates as ranges with assumptions rather than single dates
- Delegate work with context and ownership, and give concrete feedback
- Run an incident and write a blameless postmortem
No education program can guarantee employment or a promotion.
Curriculum
Curriculum
- 01
Role transition and boundaries of responsibility
The difference between a senior engineer and a tech lead, and how to split time between hands-on work and leadership.
- Common variants of the tech lead role
- Mismatch between responsibility and authority
- Share of hands-on work and what blocks it
- Agreeing expectations with your manager
- A 30-60-90 day plan
Hands-on lab: Write a role expectations and time allocation document for your own team's real situation.
- 02
Technical direction and roadmap
Tie technical debt, product priorities and team capacity into one plan.
- Technical vision and principles
- Classifying technical debt
- Prioritising by risk and value
- Aligning the roadmap with the product plan
- Showing context with a C4 diagram
Hands-on lab: A two-quarter technical roadmap for a fictional e-commerce backend, with the prioritisation rationale.
- 03
Decision making and ADRs
Make it traceable who decided what, with which information, and why.
- Reversible and irreversible decisions
- ADR structure: context, options, consequences
- Consensus versus advice process
- Revisiting and superseding decisions
- Separating facts from needs in a technical dispute
Hands-on lab: Write three alternatives and one ADR for a given monolith decomposition scenario and defend it in a simulated discussion.
- 04
Quality standards and review culture
Deliver code review, test strategy and standards as a shared language, not a burden.
- Purpose of review: finding defects, sharing knowledge, setting standards
- Review checklist versus automation versus human review
- Pull Request size and flow
- Test pyramid and acceptance criteria
- Backing standards with lint and CI
Hands-on lab: Review a series of Pull Requests and draft the review rules to propose to the team.
- 05
Estimation and planning under uncertainty
Work with risk, assumptions and ranges instead of promising exact dates.
- Presenting estimates as ranges and assumptions
- Spikes and early risk reduction
- Slicing work into releasable parts
- Mapping dependencies and bottlenecks
- Communicating when the plan changes
Hands-on lab: Decomposition, risk register and range estimate for a feature with unclear requirements.
- 06
Mentoring, delegation and feedback
Grow the team's capability: what to delegate, to whom, and with how much context.
- Delegation levels and passing context
- Development conversations and goals
- Concrete, behaviour-focused feedback
- Pair programming and knowledge sharing
- Reducing single points of knowledge
Hands-on lab: A delegation plan and a feedback conversation script (role play) for three engineers at different experience levels.
- 07
Incident leadership and postmortems
Role split under pressure, communication, and a blameless postmortem.
- Incident roles: coordinator, communications, technical
- Severity levels and status updates
- Timeline and root cause analysis
- Blameless postmortem and action items
- Preventing recurrence and follow-up
Hands-on lab: Build a timeline and postmortem document from simulated incident logs.
- 08
Stakeholder communication
Explain technical risk and trade-offs to product and business in their own language.
- Tailoring the message to the audience
- Explaining risk and compromise
- Saying no and offering an alternative
- Written status and decision memos
- Escalation criteria
Hands-on lab: A short memo and a five-minute spoken pitch asking a business stakeholder to allocate time for technical debt.
Practice assignments
- A role expectations document for a real or fictional project
- Write three ADRs and get feedback from a peer
- Write review comments on a Pull Request series and analyse them
- A postmortem draft for an incident scenario
Portfolio deliverables
- A draft technical direction and roadmap for a team
- An ADR set for a case study
- Draft review rules and a Definition of Done
- A postmortem template and a completed example
How learning is assessed
- Defense of the technical direction and roadmap in front of simulated stakeholders
- Written evaluation of the ADR set, with recommendations
- Feedback from a mock review and a mentoring conversation (recommendations, not a certificate)
Tools and technologies
- ADR (Markdown)
- C4 model
- Mermaid / PlantUML
- GitHub / GitLab Pull Requests
- Jira / Linear (as examples)
- Prometheus / Grafana (for the incident scenario)
- Miro / FigJam
- Postmortem templates
Level progression
- Before
- Senior backend engineer level: able to design and run a system independently.
- After
- The solution architecture program, or deeper practice in a tech lead role on your team.
- Length and format
- Length and format are not set yet; the program is planned and not scheduled.
Frequently asked questions
Frequently asked questions
Is this program available now?
No. It is planned and not scheduled. No dates or prices are announced. You can request a consultation.
Is it a people-manager program?
No. The focus is technical leadership: direction, decisions, quality and mentoring. Administrative people management is not a core topic.
Does it promise a role or title?
No. No program can guarantee a title, salary or outcome. It builds skills; the decision remains yours and your employer's.
How practical is it?
Each module has a scenario or case study: writing ADRs, running reviews, drafting postmortems. It is not planned as lectures only.
Articles related to this program
- ADRsWriting Architecture Decision Records that survive the team
- C4 modelThe C4 model: architecture diagrams that people actually read
- System designCaching strategies - cache-aside, write-through, TTLs and stampedes
- Technical leadershipCode review culture that helps teams
- System designA repeatable method for system design interviews and design reviews
- System designSystem design walkthrough: a URL shortener