Let me be clear about the shape of my role before I say anything else: I'm an IC tech lead on a 13+ person engineering team at Simplilearn. No direct reports. No performance reviews to write. No org chart authority over anyone.
That's a real constraint. It's also taught me more about what technical mentorship actually is than any management framework I've ever read.
What Mentorship Looks Like Without the Title
Classic mentorship models assume hierarchy: a senior person sets goals, tracks progress, holds someone accountable. That's a coherent model. It's just not the one available to me.
What I have instead is proximity, credibility, and the ability to make things visible. When I validate a workflow and share it clearly, engineers see it and decide whether to use it. When I leave a thorough code review comment that explains the why not just the what, that comment might shift how an engineer thinks about a class of problems — permanently, not just for the PR. That's mentorship. It's just distributed and asynchronous and doesn't look like a 1-on-1 calendar block.
The most useful reframe I've found: technical mentorship at the IC lead level is about changing defaults. Not changing what someone does today — changing the baseline pattern they reach for on every similar problem in the future.
Demonstrated Workflows as the Medium
The Agentic Coding Company Playbook I put together for our AI tooling rollout is probably the clearest example of what mentorship looks like in practice for me.
I didn't run workshops or assign reading. I validated specific workflows — the Figma MCP integration, the merge conflict resolution pattern, the cherry-pick branch split workflow for clean history management — in real work first. Each one was a genuine problem I solved, and I documented what I found. The playbook was the record of things that already worked, not things I thought might work.
The team adopted them. Not because I asked, but because engineers could look at the documentation, try it on a real task, and see the difference. The adoption was pull, not push. That's what I was going for.
LLM Wiki and Graphify followed the same pattern — I demonstrated the approach in a context people could see, explained what it unlocked, and made it easy for engineers to try it themselves. A few did. Some of those engineers are now the ones introducing it to others.
That propagation effect is the real metric. When someone who adopted a pattern from you starts teaching it to someone else without involving you at all — that's when you know it actually landed.
Code Review as Teaching Infrastructure
Code review is probably my highest-volume mentorship channel. On a team without a formal tech lead-to-IC coaching structure, the PR review is often the most direct touchpoint where I can affect how someone thinks about a problem.
The difference between a useful review and an unhelpful one isn't the number of comments — it's whether the engineer leaves with a new mental model or just a list of changes to make. I try to leave comments that explain the reasoning behind the pattern, reference the failure mode that the current approach risks, or point to a concrete example from the codebase. The goal is that the next time they write something similar, they don't need me.
Code review culture is also something the team adopted collectively. AI-assisted reviews became a standard part of the workflow — engineers started using it for pre-review checks, catching surface issues before the review, and focusing the review itself on architectural and behavioral concerns. That shift happened because a few people tried it, found it useful, and it spread. I was one of the people who made it visible early. That's the extent of my role in it.
The Turborepo Pattern: Winning by Demonstration
The Turborepo monorepo pattern becoming an org-wide standard is the example I come back to most when I think about what technical influence actually requires.
I didn't propose it in a design doc and wait for approval. I built it, made it visible, demonstrated the build time improvements and DX benefits concretely, and let engineers experience it directly. The adoption happened because the evidence was real and accessible, not because I had the authority to mandate it.
What I learned from that: engineers don't resist good ideas. They resist ideas they can't yet evaluate. The job of the IC lead is to make the idea evaluable — to get it out of the realm of "trust me, this is better" and into the realm of "here's a working example, judge it for yourself."
That's different from traditional mentorship, which often relies on the authority gradient to accelerate adoption. Without that gradient, you have to do the work of making the evidence clear.
The Honest Constraint
There are real limits to mentorship without authority. I can't create growth opportunities through promotion cycles or performance conversations. I can't shape someone's goals in a formal way. I can't hold anyone accountable in a structural sense.
What I can do is be the person who has already tried the hard things, who shares what worked honestly, who leaves code review comments that treat engineers as peers capable of understanding the full reasoning. I can make the work visible and the patterns accessible.
My manager's feedback points to stakeholder management and scaling influence to larger audiences as my growth edge — taking this demonstrated-pattern approach and making it work beyond the immediate team. That's the next problem. It probably requires a different set of tools than the ones that work well in a 13-person team context. I don't have a clean answer yet.
But I'm confident about the foundation: the mentorship that actually changes how engineers work doesn't require a title. It requires credibility built through demonstrated results, and the patience to let adoption happen by pull rather than directive.