Managing a team that didn't choose you

6 months ago, after a 9-month career break, I started a new role as an Engineering Manager at HoneyBook. It’s my 4th management role, but the first time I took over an existing team and not promoted from within.

I was told many times that in the first 30 days I must ‘only listen and learn’. I tried, but felt it’s the completely wrong approach to take. Last week I wrote about how we must adapt ourselves to our team’s needs - so here’s my honest self-retro:

I had a VERY clear plan before I started.

I told everyone during the final interviews and after signing the contract that I'd like to spend the first 6-8 weeks quietly understanding the codebase, and even do a couple of weeks of technical support. I thought it would be a great way to onboard, as it would both give me better technical understanding, and let me observe from the sidelines how the team operates before I'm officially the manager.

Everyone agreed to the plan. I was explicitly told I'm not expected to manage anyone in the first month. The engineers will report to the director, and he'll also take the day-to-day job.

It took me just a couple of conversations to understand it's the completely wrong plan…

My first action when I got the laptop was to schedule 1:1s with all of my 7 engineers. I just wanted to make sure they were ok, and to see if there's anything urgent I need to tackle before I dive into the code.

What I learned: three days before I started, the team was moved to a new group, thrown into a completely new project, under a new PM. On top of that, all of them mentioned the last 6 months were quite challenging. They had no manager, no 1:1s (although officially reporting to the director), and the 7 of them were split between 4 completely unrelated projects. They barely felt like a team, and they missed that feeling.

So once I understood that the plan was for them to continue reporting to their old director (with whom they didn't have any contact), while the new director (who didn't have any context) will be the one managing the day-to-day of the brand new project...

It became very clear that disappearing into the code would be a very bad decision.

The team was much more senior than I was used to. I had a former EM (now staff engineer), 2 other staff engineers, 2 seniors, and 2 mid-level engineers. The technical side was in very good hands, my input was not needed there. Six chaotic months, and now a new project, a new PM, and a new director - what they needed from me is to focus on building the team itself.

So instead of coding quietly and being a shadow, I spent most of the first month talking to people and managing the day to day. 1:1s with any relevant person in the org, many discussions with the new PM. I'd say 90% of my day was in meetings.

It was naive to make concrete plans without understanding the reality first. All those 30-60-90 suggestions are nice, but every team has a different situation. I felt I talked way too much about my "self technical onboarding plan" before starting.

The good part is that I was able to adapt even though I knew not everyone would accept it well (my director would have preferred I get better technical foundations first). I had to push a bit to do it, but I felt it was the right decision.

The irony is that adapting so fast created its own problem. I went from planning to be invisible to being everywhere, which set me up for the next mistake:

We had our first team meeting at the end of my first month. I put every team process up for discussion: the length of cycles, cooldown, daily meetings, team meetings. It was a chance to reset and combine what worked for them in previous iterations with what I brought. We settled into 3-week cycles and 1-week cooldown, (inspired by Shape Up). A veteran engineer mentioned they used to name sprints after desserts and bring them in for the demo. We decided to restart from A but go with cocktails. Sprint A was Aperol Spritz, B was Bloody Mary, and so on.

In our first cycle, we planned to complete a basic version of one big project and multiple small ones. But we were working on a completely new area for the team, so of course we hit a lot of unexpected surprises and blockers.

I was clueless. I had zero understanding of the work itself. Most of it was backend Ruby on Rails, which I'd never worked with before. I understood maybe 30% of the technical conversations.

By the end of the sprint, it felt really close, so we (well, mainly I) decided that 3 engineers will continue working during the cooldown to wrap it up. It felt so close. The engineers were frustrated, as the whole point of the cooldown is to not rush it with finishing the previous cycle.

The second sprint went a bit better, but we again didn't finish the main parts. This time, our most senior engineer took me aside, and told me to stop rushing us. There are things we need to learn and improve on, he said, but I'm being unrealistic. I'm grateful he did that. I really wanted us to have some early successes, so I pushed hard to find the minimal scope we could release. But the result was everyone always feeling behind and pressured.

The constant pressure to finish on time was not healthy at that stage (too many unknowns). Having zero technical understanding made it worse. I feel the situation wouldn't have happened if I was an engineer promoted from within.

Our third cycle went much better. By the end of it, we prepared Caipirinha together for the demo. People were laughing, chatting about random stuff between the updates. I felt we were finally becoming a team.

After around 2 months, I finally had some time to breathe.

We had a weekly hotfixer responsible for all incoming tickets, and I had completely ignored that part until now. It was a bit against my instinct (I usually put support very high on the priority), but they'd been managing like that for 6 months, so I felt there was no rush. I prioritized the team and people first.

When I started to dive deeper, I saw to my horror there were 21 open tickets, with some of them open for more than a month. For 3 weeks in a row there were more tickets opened than closed, and the snowball kept increasing. The main problem was that we had some areas for keep-the-lights-on that nobody knew, and they were hell to debug, so people tended to do them last. With the volume, those were the ones that kept getting pushed.

This instantly became a high priority. Together with one of the engineers we organized a "hotfixing blitz." We closed a conference room for a day, and I ordered lunch for all of us. We also bought 20 $3 scratch tickets, so everyone who completed a ticket got to do something fun as a ‘reward’.

We ended the blitz completing 18 tickets, and solving multiple problems at the root, not just patches. (Someone won $20 on the scratch tickets)

I also chose for myself the 2 most painful areas to work on. In the weeks after, I took a full shift for myself, to experience the work.

Since then, I've been much more involved in the support area, covering for people, and getting to know our products that way. An EM should be able to solve tickets, and do so now and then, but shouldn't become the protection wall of the team.

Four months went by very quickly. I'd gone from people focus, to delivery focus, to support focus. Things got stable and we found our rhythm. People felt they had someone to talk to, and understood what was expected of them. We were a team again, with culture, rituals, and even cocktail names :)

And then, 2 things happened:

I came back a few weeks ago, and I'm recalibrating again. The plan I had 6 months ago before I started was useless. The plan I'd make now would probably be useless too in a few weeks. The only thing that actually worked was paying attention, overcorrecting, and then listening when someone told me I'd gone too far :)

This is becoming the reality for more and more EMs - constant changes. I was used to a very stable routine, working with the same engineers, on somewhat related areas. In 2026 and beyond, I’d bet that this will become rarer and rarer, with the pace of both tech change and org changes. We need to make sure we are constantly adapting to our team needs.

Also - don’t be afraid to break some rules. I was repeatedly told you should just learn in the first 30 days on a job. I tried, but felt it was not the right approach, and I’m happy I didn’t stick to it.