12 May 20254 min

Growth Is On The Other Side Of Courage

Aishat Yusuff
Written by

Aishat YusuffFull Stack Engineer

Growth Is On The Other Side of Courage

One warm spring morning in May 2024, I made my way to the METRO building in Düsseldorf, to start a new role as Full Stack Engineer in one of the most important engineering teams at METRO.digital. After getting lost and missing train stops, due to a road closing near the office, I arrived near lunchtime – quite apologetic for being late on my first day. But my new teammates were most welcoming, assuring me that all was well. Now, a year later, as I recall this first memory of working at METRO.digital fondly, it is only fitting that I reflect on all the gems I have picked up on my journey thus far.

Great teams are not myths

Before resuming at METRO.digital, I carried out a lot of research on what a Junior Fullstack Engineer should do in their first few months – to bring the most value to their new team but also try to draw the maximum benefit as someone who’s just starting out in their career. All the materials I found in my research rightfully focused on individual actions that engineers can take. But I have learnt that, without a supportive and empowering team, there is only so much individual actions can produce. My teammates have supported me since our first encounter. They have provided (and continue to provide) an enabling environment for my engineering skills to grow far beyond my expectations. Their support did not stop there. Moving to a new city to take up a new role is a daunting experience, but with my team’s support, I was able to not only settle into a new job but also settled in Dusseldorf a lot more smoothly.

Asking the right questions is a lot harder than providing the right answers

I enjoy asking questions, and this attitude also follows me to work. However, as a Junior Engineer, I would often worry about whether my questions were too much or annoying for my senior colleagues. This worry made me swallow my questions at times, but nature is a strong thing, so I mostly ended up asking them anyway. Until my Team lead gave me feedback one time, saying “Aisha, I really like your questions”. I realised that I may be using up my energy worrying about whether my questions were too much, instead of building my inquisitiveness (to ask better, more effective questions). There are many instances that my questions have made it easier for me to tackle tasks and understand an unfamiliar service better. My inquisitive nature has also proven useful with pull request reviews, because I made sure to ask questions that enabled me to get at least a rough overview of what the pull request is intended for. This has helped us spot errors (minor and major) on time. I cannot recommend asking the right questions enough!

Growth is on the other side of courage

Volunteering to work on tickets has been a great way for me to better understand the microservices that my team is responsible for. During refinement meetings, I was able to get some understanding of tickets that we would work on in the following sprint. So, when sprint planning meetings came, I could volunteer to work on specific tickets, even when the little voice that loves its comfort zone, begged me not to. However, I have noticed that at the end of every such ticket or task, lies a different type of growth, and increased confidence in my skills as an engineer.

You have to overcome the fear of being seen

This is certainly easier said than done, but it is a skill I developed in my time at METRO.DIGITAL (and will continue to pursue). Overcoming the fear of being seen has made practicing reflection #3 much easier for me. Without being held back by concerns about how others perceive me, I find myself more capable of taking on new and seemingly daunting challenges. Indeed, growth lies just beyond overcoming this fear.

A vivid example of practicing this reflection was during my first month in my role. At an All-Hands meeting for my solution, my engineering manager raised a question about an architectural decision my team had made earlier that month. Being the only team member available on the call—and with my camera turned on—I stepped forward and addressed his query. Successfully providing a clear answer on behalf of my team in such a setting remains a powerful demonstration of this reflection in action.

Always ask for feedback

Feedback can only ever go one of two ways, but I find that either outcome contributes positively to my growth. Naturally, constructive feedback is the most valuable, and as my initial reflection suggests, I’m fortunate to work in a team that excels at giving it. Every time I’ve received suggestions for improvement—and acted on them—the quality of my work has increased. Likewise, positive feedback always motivates me to do even better.

In my first month after resuming, I requested a 1:1 with my Team Lead and noted all his feedback, which I still keep as a physical reminder. At the three-month mark and again at the end of my probation, I had similar 1:1s with my Engineering Manager. Regular feedback from my teammates has also helped me build a healthy relationship with asking for, receiving, and even giving feedback. I believe this is one of the most crucial skills to develop for long-term success in any field.

Big wins are crafted from celebrating the small wins

Last—but certainly not least—I make it a point to celebrate my wins, no matter how small they may seem in hindsight. Every bug I fix, every task I complete in a sprint, every kudos from a teammate, every new and exciting technology I learn—I celebrate them all. These celebrations aren’t always elaborate. Sometimes I take note of my win in my work journal; other times, I highlight it during sprint retros or in my 1:1s with my Engineering Manager.

What matters is that I remind myself to acknowledge my progress and not wait for a “big win” before I celebrate myself. The most rewarding result of building this habit has been a noticeable boost in my confidence—and honestly, isn’t that the best first workiversary gift I could give myself?


Topics
ChangeSelf-organizationEngineeringFeedback