Loading…
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.
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.
“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.
“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.
“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.
“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.
“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.
Chosen by what you are actually stuck on rather than worked through as a syllabus.
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.