an article by Gonzalo Maldonado
Introduction
At mobile.de we run a mentoring program where people can sign up as mentors or mentees. In my role as Engineering Manager, which I’ve been doing for several years at different companies and where I focus on supporting teams and individual growth, I volunteered as a mentor and was paired with a Senior Backend Developer — and I was excited to see what would come next.
My current mentorship relationship began, as many do: we created a calendar invite and then we introduced ourselves. I learned she was a Senior Backend Developer and that she was looking for some professional development guidance. Her CV looked solid to me and she came with a lot of questions, which I was more than happy to answer based on my past experience. I felt really excited, while I was really nervous. Would I be enough to meet her expectations? What are her expectations? Would I be able to help her grow in the way she needed? . She wasn’t sure whether Tech Lead or Principal Engineer was the right next step, and that uncertainty shaped our work: both paths demand technical excellence, yes, but also excellent communication, organisational influence, and the confidence to make tough decisions.
I would like to share with you my experience on this short but enriching journey, as I feel it didn’t only help my mentee to grow professionally and personally, but also it helped me a lot reflecting on how a good mentoring relationship and program should look like, how to adapt when the context differs from my previous mentoring experiences, how cultural background affects the way we mentor and how to communicate for getting the best outcomes.
My aim in this post is quite simple: to offer no more than an inspirational, practical guide for any mentor who wants to be part of such a journey and to show that you don’t need a specific role in the company to be an effective mentor.
Initial steps
At the beginning we met to get to know each other and validate whether our mentoring relationship would potentially be a good match or not. During that first conversation we agreed on the goals we wanted to achieve and discussed what each of us could contribute to the process. Spoiler alert: We turned out to be a great match.
We also wanted to give this a proper structure and for this reason we defined weekly 1:1 sessions of 30 minutes.
Her aims were twofold: explore the Tech Lead and Principal Engineer paths, and improve communication so she could build trust and influence, so in the future she could potentially take one of these two roles and just because it is nice to build trust. Now it was time to start doing.
Learning style was also part of the conversation, as I needed to know whether she preferred reading or watching videos. Since she was more of a reading person, I defined a weekly cadence for sharing written resources which we would later discuss in our 1:1s. Always in a timely manner, as she was going to need enough time to read and reflect about the topic.
Growth Areas
Once we recognised what we wanted to talk about, we created a brief roadmap of the topics we wanted to discuss in our weekly meetings:
Building confidence in your own abilities
Confidence is the foundation of day-to-day work, and because I’ve seen impostor syndrome become a major issue — I suffer from it myself — we addressed it first, although we returned to the topic several times.
Building trust across the team
Trust isn’t only self-confidence — it’s confidence from others: peers, managers, and cross-functional partners. How can you feel confident if you do not have a proper relationship with others? And how can you build such a relationship and trust? This is tough, but we talked about strategies on how to overcome this situation. At the end of the day it is all about talking and setting up the right expectations, as we’re here to have a good relationship and act as a team and not only like individuals. If there is no trust, your impact will be limited.
Organisational influence and communication
Once you trust yourself and your team, the next step is influencing the broader organisation. I’m not talking about being the rock-star in the spotlight all the time; I mean being an example to other engineers and an inspirational contributor, whether you’re a leader or not. For example, a senior engineer might lead cross-team architecture reviews, build a reusable internal library, or run recurring tech talks — small, tangible actions that set an example, spread best practices, and align technical work with product impact. By doing that, we can develop the best approaches together and generate ideas that help us make the most of our product and how we work.
How to keep yourself motivated when things are not going well?
We all know that being 100% motivated all the time is kind of impossible, because life happens and because we’re just human beings, this is where keeping the motivation on a good level when things are not going well is tough and a few things tend to help: celebrate small victories, reset yourself, zoom out to see the bigger picture and please please, don’t blame yourself.
How to handle conflicts
I’m still developing my skills in this area, and this experience taught me the most: by listening to my mentee’s perspective on conflict, I discovered concrete ways to improve my communication and decision-making. What I confirmed here is that communication and decision making are crucial here, but at the same time please always give yourself the time to hear both parties, to understand where they’re coming from and try to apply techniques for addressing these situations. You don’t have any techniques for it? Then I think it is crucial for you to start building your own conflict management toolset, it will just make your life easier.
Self development and self knowledge
From beginning to end, it was a process of self‑discovery. How do we give feedback to ourselves and to others? How do we receive feedback from others, and what do we do with it? These were some of the questions we discussed in our sessions. Too often you take feedback and don’t turn it into action, which can cause you to miss opportunities. Feedback from others is a key piece of the puzzle — and I don’t mean just from upper management; I mean the people you work with every day.
Engineering Ladders
People talk about “engineering ladders” a lot, but they rarely explain what it actually takes to move up. The higher you go, the fuzzier the criteria become — which makes promotions feel mysterious and unfair. This is where the Engineering Ladders framework comes into play and what I really like about it, is that it will give a bit more of a concrete vision on which are the dimensions considered for developers, tech leads and engineering managers — even PMs are part of this framework. Once you read it, you will understand that the dimensions are pretty well defined. We liked the most that they don’t only talk about technical skills, which is also important, but that there are more dimensions which are also relevant. Use this as one of many tools for building your career path.
Technical skills
Skipping this wasn’t an option, right? Definitely not. We focused on the topics mentioned above because that was the path my mentee wanted to follow — she was already confident in her technical skills. That said, technical ability is not something to ignore, and we worked to enhance her skills further to support the influence work I described earlier.
First, we discussed how well she knew the product, the architecture, testing approaches, resiliency, and so on. With that context, we created a plan to review the application’s big picture and identify improvements to make it more resilient.
Technical decisions and decision making
Once the technical solution is clear, some implementations seem “easy enough.” But what happens when they aren’t? When you must choose between “quick and dirty” and “perfect,” that trade-off is a daily reality for Tech Leads and Principal Engineers. Much of this is learned on the job — theory only goes so far — but having solid strategies for difficult conversations makes those on-the-fly decisions far easier.
We discussed real-life scenarios where a decision had to be made and which communication strategies fit best. Questions we explored included: should you be the first to speak, or let others voice their views? When is it useful to wait and let silence work for you? A ten-second pause often elicits valuable input. The more tools you have for framing decisions and guiding discussion, the better your outcomes will be.
Self evaluation and next steps
As a closing act we ran a self evaluation from start to finish of the process and what we learned from it. With this in mind and her interest, we decided to follow these steps
- Creation of a high-level architecture of the application she’s working on and share it with the team. Baby steps first!
- She’s becoming a mentor now, she will use the same structure, in order to expand her level of influence and communication skills.
- Given that she’s lacking in specific technical areas, she will dig deeper into certain topics and the knowledge will be shared with her team and also her area.
This mentoring relationship is not over, and I think it is far from over, but I wanted to give you a summary of what has happened so far. I have learned a lot and I realised how many things sounded great in theory but were harder in practice. Now I have run my own self reflection (as mentioned above for her) and this has been so fruitful!
I was really happy when I received positive feedback from my mentee — it meant the world to me, because something I was not sure I could do definitely paid off. So, if you are hesitating about mentoring somebody, I always recommend you go for it! Even in the worst case, mentoring produces learning for both parties. I speak from experience: some of my past mentorships failed, yet those failures taught me crucial lessons I still use today.
Special thanks to Philipp Mayer, Busayo Oyewole, Stefan Wilke for helping me review this document.
Resources I have used along the road and that might be useful for you
- Zhuo, J. (2019). The Making of a Manager.
- Larson, W. (2021). Staff Engineer.
- Meyer, E. (2014). The Culture Map.
- LinkedIn. (n.d.). Building Confidence as an Engineering Manager.
- Workfeed.ai. (n.d.). Building Trust in Cross-Cultural Teams.
- Gambill, T. (2022, July 26). 5 Characteristics Of High-Trust Teams. Forbes.
- LeadDev. (n.d.). Three strategies for building trust with your engineering teams.
- emdiary.substack.com. (n.d.). Staying Motivated When Things Go Wrong.
- LeadDev. (n.d.). Managing conflict in engineering teams.
- Wen, J. (n.d.). Tech Lead Handbook — Manage Conflicts. Medium.
- leadership.garden. (n.d.). The No-BS Guide to Engineering Team Conflicts.
- Engineering Ladders. (n.d.). Engineering Ladders.
- Highland Literacy. (n.d.). De Bono’s Six Hats.
Top comments (0)