Leading Without The Title
I didn’t ask to lead, but in moments of uncertainty, not leading felt worse.
In March 2025, I started a new chapter in my professional life.
Banco John Deere was going through a Joint Venture (JV) process with another bank, and before it officially happened, my manager asked me a simple but heavy question:
- Would I like to continue working at John Deere Global, or move into the new Joint Venture structure?
At the time, staying in the global team felt safe, but also limiting. My influence there wouldn’t be very high, and I would likely become just another person in a much larger structure.
Moving to the JV, on the other hand, felt uncertain, but full of opportunity.
I decided to join the Joint Venture, and very quickly I started to understand the scale of the challenges ahead. And, honestly, that excited me.
The project that really caught my attention was the creation of the Data Platform for Banco John Deere. I knew that building something from scratch, with real impact, would be a defining experience for my career.
At the time, I didn’t know that the Data Platform would be just the initial challenge, not the full story.
The Beginning
Over the following months, I went deep into understanding Databricks from an administrator’s perspective.
I designed the architecture, defined guardrails, and helped shape the roadmap, from infrastructure setup to the migration of our data pipelines.
Because I was responsible for the Data Platform, I also had to align expectations across both companies: John Deere and Banco John Deere. Leading those cross-company conversations was challenging, but also one of the most valuable experiences I’ve had so far.
At the same time, I became heavily involved in interviews, both for my team and, occasionally, for the global team as well. I didn’t want to close the doors to the relationships I had built there.
Throughout 2025, I participated in more than 20 technical interviews. In the end, we hired four engineers for my team. I had interviewed candidates before, but that year was especially intense.
For nearly five months, the work was mostly invisible. It was alignment, planning, and studying the Databricks platform in depth, everything ready, just waiting for the green light to start production.
When Responsibility Shows Up
At the beginning, my responsibility was clear: lead the Data Platform project.
That part was expected. I was responsible for the architecture, the infrastructure decisions, and the technical direction, and I was comfortable with that.
As we started delivering the first infrastructure pieces and moving the project forward, things slowly began to shift.
When my Product Manager started focusing on other teams and initiatives, I unintentionally began handling all the team’s projects team, not only the Data Platform, since I already had context on most of them.
Without really planning it, I found myself taking care of the Jira board.
I started writing tasks, organizing the backlog, understanding sprint priorities, gathering requirements, and connecting dots between different initiatives.
These weren’t responsibilities I asked for, they just made sense to take on. The team needed clarity, and I was already close to the work.
By the end of it, my role became something a bit different. I wasn’t acting as a Product Manager, but I was doing many of the things one would normally do. I kept my PM aligned with what was happening in the team, the status of each project, and the priorities we were moving forward with.
There was no formal transition, just a growing sense of ownership.
When the Chair Became Empty
At some point during all of this, my manager left the company.
By then, I was already carrying several responsibilities: the Data Platform, most of the team’s projects, and many of the Product-related activities. I was already acting as the technical leader for the team.
Before leaving, my manager started including me in meetings with the Staff Engineer and the Solutions Architect, positioning me as the main reference for Data at Banco John Deere. With that, even more responsibility naturally landed on my side.
But what really stayed with me wasn’t the increase in technical or architectural work, it was what happened inside the team.
I already had regular 1:1s with everyone, usually every two weeks. Those conversations became more important after my manager left. I could feel the uncertainty, the questions, and the need for direction.
I never intended to replace anyone.
But in some way, I found myself trying to “fill that chair”, being present, listening, and making sure the team didn’t feel abandoned.
There was no formal decision behind it. It just felt necessary.
Looking back, part of why all of this felt natural is simple: I had been part of the team since its foundation in 2022. I knew the people, the context, and the history. Stepping in didn’t feel like taking over, it felt like taking care of something I had helped build.
No one from leadership ever had to ask me to do it. Most of these responsibilities were taken almost unconsciously, just responding to what the moment required.
That experience changed the way I see teams and leadership. It taught me how fragile teams can feel during periods of change, and how much stability comes from presence, communication, and trust. My communication evolved a lot during that time, especially because I had to talk with my teammates on a level far beyond technical discussions.
It was an intense experience, but an incredibly valuable one. It reshaped my understanding of leadership and added more to my professional growth than I initially realized.
When It Started to Feel Heavy
With all of this happening, there was a moment when things started to feel heavy.
I realized that I wasn’t writing code anymore. My days were filled with email alignments, meetings, team guidance, backlog organization, and sprint prioritization.
None of those things were bad on their own, they were necessary.
But the shift was real, and it was happening quietly.
Throughout my career, I never aspired to take a manager’s chair. My focus was always on technical roles, building systems, solving problems, and staying close to the code. And suddenly, my energy was being spent elsewhere.
I wasn’t less productive.
I was just tired in a different way.
It took me some time to understand that this kind of tiredness wasn’t about workload, it was about carrying context, expectations, and people’s trust.
Leading without the title taught me more about myself than I expected. Not because I doubted my ability, but because it forced me to pay attention to what actually gives me energy, and what slowly drains it.
I didn’t feel imposter syndrome while taking on these responsibilities. I felt capable. I felt trusted. And I felt that stepping in was the right thing to do for the team.
At the same time, the experience helped me understand my boundaries more clearly. I learned that leadership doesn’t have to mean moving away from the technical work I enjoy. It can be situational, temporary, and deeply connected to care rather than hierarchy.
This period reshaped how I see teams, stability, and responsibility. It showed me that leadership isn’t always about ambition, sometimes it’s simply about presence. And knowing when to step in is just as important as knowing when to step back.
And that realization alone made the experience worth it.