New company, new team: how to start the first month on the right foot
Things you should definitely do when leading a new team
Exactly one month ago, I embarked on a new adventure at Redokun as the leader of the product team. New company, new colleagues, new team. The approach was definitely different from my previous experience, where I already knew my coworkers and had built relationships with them.
In a new company, you start from scratch: you don’t have the trust capital you’ve built over time, you don’t know the team’s dynamics, and even simple things - like knowing who to ask for what - aren’t obvious. Instead of leveraging existing relationships, I had to focus on building them from the ground up, understanding team expectations, and figuring out how to contribute without disrupting existing workflows.
Over the past month, I’ve been keeping track of what I did each week to settle into the company and have gathered some reflections that I’d love to share. The original idea was to group those activities in this issue by week, but I eventually realized that things aren’t always that clear-cut, and it’s impossible to grasp everything in just a week. I decided to divide them into “areas” instead.
Weeks -2/-1: First interactions with the team
In the weeks leading up to my start at the company, I asked the team to jump on a call so we could get to know each other. I believe it was a great way to give the team a first impression of the person they’d soon be working with.
Understanding the business and the product
The first thing I did after a Welcome aboard meeting was talking about the business. This might sound odd since the very first thing you should do is get to know the people you’ll be working with. However, during my first days at the new company, most of the team was out, and operations were limited. This gave me the opportunity to focus on understanding the business and the product.
I started by looking into how the company makes money. Revenue streams shape priorities, and knowing what drives growth helps make better decisions. This was my very first question in the new company: Where does our revenue come from?
Beyond the product itself, I needed to grasp the industry dynamics and internal rituals: how priorities are set, how decisions are made, and how teams collaborate. These unwritten rules influence how work gets done.
I also spent time understanding our competitors and ideal customer profile (ICP): Who are we building for? What makes us different? What problems are we solving? To get hands-on experience, I used the product as a customer, testing core flows and identifying friction points alongside the Product Designer. Finally, I focused on understanding my team’s role in the bigger picture, ensuring I saw not just our scope but how we impact the company as a whole.
These dynamics was - and actually are - essential for me to get a sense of the context in which my team operates.
Getting to know the team and the company culture
The week when both the CTO and the rest of the team returned to work was the one in which I focused more on getting to know the team members better. I immediately started talking to each team member, explaining my way of working and my leadership style. I considered essential to learn some key information about them, such as each person's working hours, to better understand their daily routines. I already discussed in another issue how important it is for me to respect my team members' working hours.
Another important thing was to start scheduling weekly 1:1s with everyone right away and to discuss personal growth paths with each of them, providing them with a template I’d like to use to keep track of our 1:1 discussions and growth goals. I’ll probably go into more detail about this in a dedicated issue, as I’d also like to share the template I use.
Understanding the team process and first actions
At the same time as getting to know the team, it was important to gain a clear understanding of internal processes, priorities, and the challenges they were facing.
Another important thing at this stage is identifying the "hidden" work that isn’t represented on the team’s board. It’s common practice in teams for some people to do much more than what’s tracked on the workboard, and over time, I’ve learned that this is one of the first things that needs to be brought to light because it could hide potential pitfalls and, most importantly, frustration from those carrying out these tasks.
I’ve already shared my thoughts on how to introduce changes within a group of people:
In short: top-down decisions don’t work in my opinion. I believe more in choices that come with a push from the bottom up when possible, which is why I’ve focused more on listening to problems and facilitating discussions to find solutions together.
Having identified early on some areas where small but significant changes could be made, I organized an internal workshop focused on the pain points of the current process, prioritizing them and defining actionable items that could be implemented starting that very day.
At the same time, I also tried to help remove small obstacles to send a positive signal. I noticed that communication between teams was struggling to flow on a daily basis, so I proposed and introduced an #updates channel to keep the whole company informed about important updates. It’s a practice that was widely adopted in the organization I worked at previously, and I’ve always found it incredibly useful, so I decided to replicate it here as well. If you'd like to learn more, the CEO recently published a LinkedIn article that sums up the benefits of having that communication channel better than I could. You can read it from here.
The initiative was more successful than I could have imagined, and the feedback has been positive from the very start.
I haven’t mentioned it yet, but I’ve obviously started familiarizing myself with the code of the applications. Since I have a hands-on role, it’s important to have a solid understanding of the infrastructure and the product’s code.
Design as part of the team and the process
A special mention goes to my relationship with the Product Designer. From the very beginning, I’ve worked to build a trust-based relationship, fully aware of how central design and users are to the success of a product. We immediately started discussions on how to facilitate conversations between design and development, and how to merge the processes so they become one unified approach.
It’s still an ongoing process; we haven’t found a definitive solution yet. However, the approach remains the same: identify the problems and needs, and then work together with the entire team to find a solution that works for everyone.
TL;DR
I haven't talked about the roadmap, team goals, company culture, or hiring. I didn't mention these topics not because they aren’t important, but because this month has been so packed that it feels like I've worked through six months' worth. So, I’ve tried to focus only on the things that stood out the most to me; otherwise, I would have written three more issues on the topic.
To wrap it up: all the decisions and actions taken during this time have followed a set of principles I established from day one.
Bringing value without disrupting everything
Sharing observations and questions instead of immediately suggesting solutions
Demonstrating the ability to understand before wanting to make changes
Understanding the company's rhythm: where speed is needed and where patience is required
But the most important thing of all, especially in the early stages, is:
Listening, listening, and listening again.
Since this newsletter is focused on mistakes, only time will tell which of these things worked and which didn’t.
One more thing: if you want to know more about common paths toward becoming a leader and their challenges, you can read this issue by Anemari Fiser and the related ones:
Credits: Illustration 1
You truly resemble a person who l’d be more than happy to work with (and maybe it’s going to happen 😉)
Keep up the good work 👍
Loved It! Thanks you Simone!