Project Jam #3☕ - Simone D'Amico - Switching Companies Isn’t Enough
How To Avoid Making The Same Mistakes
Hey, fellow Leader 🚀,
Welcome to a very special edition of The Long Missing Sow. Today, we have an article by Simone D’Amico, a Technical Leader who is the author of
. Simone and I have exchanged some notes and, coincidentally, we changed jobs at the same time! His article below resonated with me, and we will both be collaborating on two articles, the first of which is now in your inbox. I am happy to welcome Simone and hope you enjoy his knowledge and insights!
Hey everyone,
here, and I’m thrilled to be sharing this space with you today! A huge thanks to Artur for the invite—it’s always great to connect with new communities.A little about me: I run
, where I share practical advice and personal stories about leadership mistakes—what I learned in my 15 years of career, how to recover, and how you can avoid making the same errors. If this topic resonates with you, you might enjoy my newsletter too!Let’s get into it.
Today's post comes from something that my career and Artur's have in common: we’ve both changed jobs recently.
When switching companies or teams, it's common to build an almost idealized vision of the role. These expectations are often fueled by the descriptions given during the interview and the first impressions. Our ambitions and imagination do the rest. We start envisioning how we want the team to work, which methodologies to use, processes and tools, communication style, and so on.
Every new professional beginning brings with it a mix of enthusiasm, expectations, and often an unconscious dose of presumption. We've all experienced that moment when, confident in our past experiences and best intentions, we think we can immediately transform things, believing we have the perfect "ready-to-use" solution.
I’ve been through several “new beginnings” – whether in growing teams, merging distinct groups, or changing tools and processes – and each time, I’ve learned that success depends not only on the quality of ideas but also on how they are introduced and embraced.
The pitfalls of the "One-Size-Fits-All" approach
Experience plays a fundamental role in our work: having firsthand knowledge of what works and what doesn’t, recognizing patterns in advance, and identifying potential red flags before they escalate into bigger problems are all crucial factors that make a difference. However, all of this is only effective when paired with another key element: the awareness that context is what truly matters.
Believing that the same "recipe" can be applied everywhere just because it has worked once before is an easy mistake to make. We have experience, we know what has worked and what hasn’t, and we even have a plan and a clear direction. What could go wrong? Quite a lot, actually. Or rather, not necessarily – but when dealing with a group of people, we must always remember that the same action won’t always trigger the same reaction we expect.
But enough with the abstract talk – let’s look at some concrete examples of changes I introduced in this new professional beginning in a completely different way than I had in the past.
Tools: understand before you implement
In my previous experiences, when introducing a new tool, I always acted autonomously, making decisions for the entire team, driven by the belief that the tool and process were the right ones because "I knew what the team needed". However, the reality was that I often found the team continuing to use the old tools or bypassing the new rules because they didn’t address the real problems or made a process more complicated than necessary.
Reflecting on my actions, I realized that there were at least two things wrong with this approach:
The team was not involved in the decision-making process and, as a result, was not aligned with the reasons and motivations that had led me to make that decision.
The real needs of individuals were not taken into consideration. Coming from a technical background, I focused on selecting tools that met the needs of developers, without realizing that a team consists of different roles, not just developers, and that each of them has very different requirements.
The team I joined this year faced another major change along with my arrival: it transitioned from being a team made up solely of backend developers to a cross-functional team consisting of backend and frontend developers, as well as designers. From the beginning, I realized that the team's internal process was no longer sufficient and that it was necessary to introduce a new process that took into account not only the new roles but also new phases that had previously been handled externally.
So, I decided to approach the problem in a completely different way this time.
I let actions speak before words: I observed what was happening within the team without any bias from past experiences, and I tried to understand the culture and specific dynamics of the new environment I had joined. I dedicated a lot of time to listening, gathering the individual needs and the problems they face daily. I let them realize for themselves what wasn’t working properly. This allows the team to gain a much deeper understanding of why certain changes are necessary, rather than simply having them imposed from above.
At that point, I led a couple of workshops to actively involve all team members in the decision-making processes. I created a space where the new process could emerge from them, so that they could tailor it to their needs and truly feel it as “theirs.”
It was only after many discussions, fully aware of the needs, that we explored some tools to help us map the process and visually represent the new workflow.
Management vs. Team: the bridge I had never built
Another common mistake I made in the past was trying to protect the team from management's requests by filtering information and limiting interference. This strategy stemmed from an apparently noble belief: shielding the team from stress and distractions to preserve their focus on work. But the reality was very different. What I perceived as protection actually turned into a subtle form of exclusion. The team wasn’t simply unaware of the company dynamics; they progressively felt marginalized. Decisions seemed to come down from above, with no connection to their daily work.
This time, I wanted to take a much more transparent approach in both directions, basing everything on an important principle: communication is not information filtering but translation.
Right from the start, I stopped just explaining WHAT was being requested by management and, most importantly, the WHY, making sure to connect the dots between company strategies and the team’s objectives. This helps the team become more aware and make decisions autonomously, in a more informed way.
On the other side, I kept open a two-way communication channel where both parties could provide constructive feedback, have an open dialogue space, and remove that "us vs. them" barrier.
Conclusions: true change lies in the method
I have learned, through these new beginnings, that it’s not enough to have the best intentions or choose the right solution on paper. The effectiveness of a decision depends on the involvement of the people, the ability to adapt to the context, and the willingness to truly listen to those who will be impacted.
Each new beginning is an opportunity to do better. But only if we are willing to learn from the mistakes of the past.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic.
Cheers,
Simone & Artur
 | A guest post by
|