Throughout my work as a Technical Lead and later as an Engineering Manager in Offensive Security and Security Engineering teams, technical mentorship stopped being an occasional practice and became central to how I understand leadership. Not as a set of formal techniques, but as a continuous process of development, contextual awareness, and long-term impact.

This perspective starts from a simple premise: technical leadership does not begin with titles. It begins when seniority turns individual contribution into a collective reference. At some point in a career, technical decisions stop affecting only one’s own work and start consistently influencing how others think, decide, and execute. What changes over time is not the nature of this leadership, but the scale and depth at which it operates.

In engineering and security environments, this transition happens almost inevitably. More experienced engineers begin to define standards, guide approaches, and sustain decisions in ambiguous contexts. Even without explicit intent to lead, seniority creates direction. How someone solves problems, chooses trade-offs, or justifies technical decisions becomes a reference. This creates an implicit responsibility: what is done, how it is done, and why it is done starts shaping the surrounding environment.

At this point, technical mentorship emerges as a natural extension of seniority. Not as formal teaching or simple knowledge transfer, but as a continuous exercise in building judgment. Mentoring, in this sense, is about helping others develop technical reasoning, expand their decision-making repertoire, and navigate technical and organizational uncertainty with greater autonomy and consistency.

One-on-one conversations play a central role in this process when they are treated as a shared space rather than a bureaucratic ritual. They work best when they do not follow fixed templates and when both leader and engineer actively own the conversation. Development gains depth when discussions are grounded in real engineering work and in the decisions the person has been making day to day.

In this context, fixed lists of questions tend to weaken technical mentorship. They create an illusion of consistency while ignoring that people are at different stages of their careers and dealing with different levels of technical complexity. When the same questions are repeated for everyone, conversations become generic and disconnected from systems, code, and real trade-offs.

Effective questions are grounded in technical context. For someone consolidating their skills, a question like “What was the hardest trade-off you had to make in this code recently, and why?” helps surface criteria that are still being formed. For someone already influencing the team, “Which recent architectural decisions would you revisit if this system had to scale over the next year?” shifts the conversation toward systems thinking and anticipation of consequences.

These conversations become more powerful when there is continuity. Recording decisions, agreements, and hypotheses is not just about memory, but about creating a living contract between both sides. Documentation provides clarity, rhythm, and a sense of progress, and it also supports leadership transitions when others later take part in that development process. Course corrections are a natural part of professional growth; what undermines development is not change itself, but the absence of explicit intent over time.

In this setting, individual development plans stop being lists of competencies and start reflecting the kinds of problems a person wants to learn how to solve. Questions about which systems someone wants to own, which decisions they want to sustain with greater autonomy, or what kind of technical impact they want to amplify help make development concrete. Leadership contributes by offering perspective, challenging assumptions, and removing barriers, while responsibility for the path remains with the individual.

Over time, this process makes growth visible. Development stops being abstract and starts showing up in more consistent decisions, increased autonomy, and clearer impact on the team and the business. Promotions, in this context, emerge as a natural consequence of accumulated practice, reinforcing the relationship between real development and formal recognition.

Technical mentorship, therefore, is neither an event nor an exclusive attribute of formal roles. It is born from seniority and strengthened through everyday practice: in conversations, in difficult decisions, and in the willingness to help others think more clearly about complex systems. Titles expand this influence, but they do not create it.

In complex technical environments, sustainable development depends less on rigid structures and more on clear intent, continuous reflection, and openness to revisiting agreements over time. Systems evolve, contexts change, and people mature. What ultimately sustains technical leadership is enough clarity for growth to happen with autonomy, responsibility, and recognition.

-

References

• [1] How to be effectively managed?
• [2] An effective manager is like a good software
• [3] The manager’s path: a guide for tech leaders navigating growth and change

This publication is also available in: Portuguese and Spanish.