How engineers grow
The hardest step in an engineering career is not technical. It is the move from being handed a task to being handed a problem, and mentorship is the part of my work that exists to shorten it.
The ladder
Five stages, described by what someone can be handed rather than what their title says. Nobody moves through these cleanly, and most people sit across two of them at once.
Writes code
“How do I build this?”
Correctness and fluency. The work is bounded, the requirements arrive written down, and success is code that does what was asked.
Understands systems
“How does this fit together?”
The unit of thought grows past the file. You start reading other people's modules, following a request end to end, and noticing that the bug is rarely where the stack trace points.
Designs solutions
“What should we build?”
You are handed a problem instead of a ticket. That means talking to the people who have it, choosing what not to build, and being wrong in public occasionally.
Makes technical decisions
“What are we giving up?”
Every option becomes a trade-off with a cost attached. The skill is holding two defensible answers at once and choosing between them for a reason you can state out loud.
Leads engineering
“How do we all get better at this?”
Your output becomes other people's output. Standards, review, sequencing, hiring and the unglamorous work of removing whatever is quietly blocking someone.
What we work on
Chosen by what you are actually stuck on rather than worked through as a syllabus.
- System design
- Practised on real problems rather than interview puzzles.
- Software architecture
- Boundaries, coupling, and when to split.
- Backend engineering
- APIs, data modelling, queues, transactions.
- Frontend architecture
- Component boundaries, state, rendering strategy.
- Mobile development
- React Native work: structure, delivery, and shipping releases.
- Performance
- Measure first. The bottleneck is rarely the suspect.
- Scalability
- Sizing for real growth without over-engineering.
- Clean code
- Readability as a team property, not a personal style.
- Code review
- Reviewing to teach, and receiving review without flinching.
- Problem solving
- Decomposing a problem until it stops being scary.
- Technical interviews
- Both sides of the table: preparing and running them.
- Engineering leadership
- The first year of leading people who write code.
How it works
Usually a recurring session on work you are actually doing, with review between. I keep the number of people I mentor small, because the useful version of this is specific to your system and your team.
If that sounds useful, tell me what you are working on and where you are getting stuck. Open to technical leadership, product delivery and senior engineering roles, and available for architecture consulting, technical reviews and mentorship.