June 30, 2026 by Uzochukwu Winnie (@wineshuga)
I joined the LFX mentorship expecting to spend three months writing documentation. A few weeks later, I was deploying OpenTelemetry Collectors across AWS EC2 instances, debugging networking problems between machines, and trying to understand why a pipeline that looked healthy wasn't sending metrics.
I went from having zero knowledge about observability to building and troubleshooting systems. This made the LFX Mentorship one of the most effective and exciting learning experiences I've had in engineering. I was exposed to how systems behave in reality. That difference is what makes it one of the most effective ways to grow into cloud-native engineering.
No expertise needed
A few months before joining the LFX mentorship, I was a Frontend Developer exploring backend engineering. My first encounter with observability was curiosity leading me to articles about traces and metrics. For years, I looked forward to contributing and joining an active Open Source community. So when I came across this mentorship with Prometheus on improving the documentation for Prometheus and OpenTelemetry Interoperability, I thought this was a perfect opportunity to contribute.
I expected my contributions to focus solely on improving or creating documentation for both tools. Documentation was part of the experience. I contributed to OpenTelemetry documentation, and my pull requests were merged. That gave me direct exposure to how large CNCF projects review, refine, and maintain technical documentation at scale, but that was only the surface. Before long, my work had expanded beyond documentation. To properly document real systems, I first had to understand them. This led me to deploy and troubleshoot the systems I was writing about.
The system deployed
The deployment I made during the mentorship looked like this:
- Django applications running on multiple EC2 instances.
- OpenTelemetry Collectors deployed alongside each application.
- A dedicated EC2 instance running Prometheus as a metrics backend.
- Metrics exported in Prometheus format from all instances into Prometheus. Every component introduced another opportunity for failure. Most failures were silent: missing metrics, broken pipelines, or unreachable services that still appeared “healthy.”
The big challenge
The hardest debugging experiences were not tied to a single tool like OpenTelemetry or Prometheus. They came from interactions between components. Problems ranged from:
- EC2 instances unable to communicate due to networking constraints.
- Collectors running but not exporting data.
- Pipelines silently dropping telemetry.
- Local setups behaving correctly, while AWS deployments failed At some point, debugging stopped being about individual services and became about understanding system behavior. I wrote about one of those debugging experiences in more detail [here] . At this point, I knew I wasn’t going back to be a Frontend Engineer.
Learning without a playbook
A defining aspect of the LFX Mentorship model is autonomy. Mentors provide direction and feedback, but they do not solve problems for you. In my case, feedback and guidance from Tiffany Hrabusa, Arthur Sens, and Victoria Nduka were just as valuable as the technical work because they shared the reasoning behind engineering decisions, not just the decisions themselves. Understanding why a solution was preferred often mattered more than the solution itself.
At first, the lack of detailed guidance felt uncomfortable and scary. Over time, I came to appreciate how much it contributed to my technical growth and confidence.
My mentors and I would discuss problems and explore different approaches to achieve our goal. We worked as a team, and that gave me the space to grow while still taking ownership of my work. During the development of the blueprint, for example, one of my mentors generously gave me access to a platform where I could test an idea we had. While it allowed me to validate the approach, it also came with a major limitation: I couldn't automate deployment, and the environment had a time limit. During our next meeting, we discussed this challenge together and came up with an alternative approach that ultimately proved successful.
This kind of guidance is all I could ever wish for. I was challenged to think independently while being reassured that I wasn't solving problems alone.
What changed through this experience
By the end of the mentorship, the most important shift was not tool-specific knowledge. It was how systems are perceived. Looking back, that change was far more valuable than learning any single technology because it fundamentally changed how I approach engineering problems. It made the experience far more impactful than I had expected when I first joined the program. I also gained a more realistic understanding of observability itself as pipelines that must be designed to survive failure.
Outcomes
Beyond learning, the mentorship produced tangible outcomes.
The improvements I made to the OpenTelemetry documentation were merged. I also completed documentation on Prometheus and OpenTelemetry interoperability using the Prometheus metrics format , and developed a blueprint proposal for deploying observability systems in non-Kubernetes environments.
Another outcome is that I now understand how open source communities organize themselves. If I wanted to join a Prometheus Working Group or an OpenTelemetry SIG, I know how to get involved and contribute effectively.
Perhaps the most valuable outcome is the network I’m beginning to build. Through this mentorship, I’ve started forming relationships with experienced engineers, and I’ve come to realize that building genuine connections is one of the best ways to grow in this industry.
Why programs like LFX matter
The value of structured open-source mentorship is not just exposure to tools. It is exposure to reality. Specifically, it provides:
- production-style environments instead of controlled labs
- real system failures instead of isolated examples
- architectural thinking instead of tool usage
- autonomy instead of guided execution This combination is difficult to replicate through self-learning alone. Most importantly, it forces engineers to deal with the parts of systems that are usually abstracted away in early learning stages.
Final thoughts
The LFX Mentorship gave me more than exposure to cloud-native tools. It changed how I think about building, debugging, and operating distributed systems. Contributing to open source, learning from experienced maintainers and mentors, and working through real production-style challenges made it one of the most valuable learning experiences in my career.
If you're looking to grow beyond tutorials and learn in a real engineering environment, I highly recommend applying for the LFX Mentorship Program . You can also check out the other mentorship programs supported by CNCF .
If you're working in cloud-native systems or exploring similar challenges, I'm always happy to connect on LinkedIn: [link] .
Facts Only
* Participant joined LFX mentorship expecting to write documentation for three months.
* Activities included deploying OpenTelemetry Collectors on AWS EC2 instances and debugging networking issues.
* The participant moved from frontend development to exploring backend engineering and observability.
* A deployment involved Django applications on multiple EC2 instances with OpenTelemetry Collectors, a Prometheus metrics backend, and metrics exported in Prometheus format.
* Debugging challenges involved interactions between components, such as EC2 networking constraints, collector failures, and pipeline telemetry drops.
* Mentors provided direction and feedback without solving problems directly.
* Outcomes included merging documentation contributions, documenting Prometheus/OpenTelemetry interoperability, and developing an observability deployment blueprint.
* The experience led to understanding system behavior under failure conditions.
Executive Summary
A mentorship experience focused on cloud-native engineering involved transitioning from frontend development to understanding backend systems, specifically observability. The participant joined the LFX mentorship expecting documentation work but engaged in deploying and troubleshooting OpenTelemetry Collectors and setting up Prometheus metrics across AWS EC2 instances. The primary learning derived from this was understanding system behavior under real-world failure conditions rather than just tool usage.
The debugging process revealed complex interactions between components, such as networking constraints between EC2 instances and telemetry pipelines that silently dropped data, demonstrating that failures often arise from system interactions rather than isolated component malfunctions. A key aspect of the mentorship structure involved autonomy; mentors provided guidance and reasoning behind decisions, fostering independent problem-solving while ensuring growth.
Tangible outcomes included merging documentation improvements for OpenTelemetry, developing documentation for Prometheus interoperability, creating a blueprint proposal for non-Kubernetes observability deployments, and building professional networks within the open-source community. The experience resulted in a fundamental shift in perspective toward system architecture and failure resilience.
Full Take
The narrative illustrates a significant transition from theoretical knowledge acquisition to embodied systems thinking, where the true learning occurred in confronting the realities of distributed system failures. The value proposition of the mentorship appears rooted in providing exposure to production-style environments and systemic complexity rather than isolated tool mastery. The pattern observed is that genuine engineering growth emerges not from consuming tutorials or tool documentation, but from grappling with emergent, interacting failure modes.
The emphasis on autonomy—receiving guidance focused on *why* decisions were made rather than simply *what* they were—suggests a sophisticated understanding of how knowledge transfer can foster cognitive sovereignty. The mentorship successfully shifted the focus from managing individual services to architecting resilient systems capable of surviving inevitable failures across interdependent layers. This echoes a pattern where structured, hands-on exposure to systemic constraints yields higher-order insight than prescriptive instruction.
The implication is that the most valuable engineering skill in complex environments is the ability to perceive and manage abstract system behavior when components interact unpredictably. The narrative suggests that programs focused on production-style failure states are superior for developing resilient engineers because they force an engagement with the abstracted layers of reality usually hidden during introductory learning. What questions remain about whether this shift in perception translates into habitual, scalable engineering instincts beyond the scope of the mentorship?