What I Learned in My First Ninety Days Leading Design

Stepping into a new leadership role at a fast-growing software company in Boston felt both exhilarating and terrifying. When I first accepted the position of Lead Product Designer, I thought I had everything figured out. I had a neat little ninety-day plan written in Notion, complete with milestones for team health, process improvements, and stakeholder alignment.

During my very first week, I scheduled a comprehensive listening tour. I sat down with every single product designer, content writer, and front-end engineer on the team. I asked them about their frustrations with our current-state assessment and where they thought our design system was failing. Everyone was polite, but I could sense underlying morale issues that nobody wanted to mention out loud.

By week three, I decided to implement a quick wins plan to prove my value. I targeted some low-hanging fruit in our Jira backlog and fixed a dozen annoying layout bugs in our main Figma component library. I thought my team would be thrilled with my proactive attitude and that I would earn their trust instantly. Instead, they looked slightly annoyed because I had bypassed their usual prioritization process.

That was when I realized my honeymoon period was officially over. I had underestimated how fragile team dynamics could be when a new manager arrives. My leadership style felt too interventionist to designers who were used to autonomy. I needed to course-correct before I alienated the entire department and ruined our chances of establishing a solid operating model.

I started taking stock of the situation by listening more and coding or designing a lot less. I focused on setting direction rather than executing tasks. We spent a few afternoons drafting a new design vision statement together, making sure every voice in the room was heard. I finally understood that leadership wasn't about making your mark through solo heroics.

The most important discovery of my entire first quarter, however, came from an unexpected source. It happened during an exit interview with Hannah, a talented senior designer who had handed in her resignation just before I started. Hannah told me something that completely changed my perspective on our management culture.

She explained that the previous leadership team had completely ignored designers' career growth in favor of shipping features quickly. She said, 'Allison, people don't leave bad Figma files; they leave bad alignment between executive expectations and daily reality.' That conversation hit me hard. I realized our team charter needed to address career progression above all else.

Looking back at those ninety days, I made plenty of mistakes and often doubted my decisions. But by mapping the landscape carefully and listening to painful truths, I managed to build real credibility with Jason and the rest of the crew. Leading design is never about having all the answers on day one; it is about asking the right questions.

Read again and choose the right answer

Where is the software company mentioned in the blog post located?

• Austin
• Boston
• Seattle

How did the designers react when Allison fixed layout bugs in Figma?

• They were thrilled and praised her proactive attitude.
• They looked slightly annoyed because she bypassed their process.
• They didn't notice the changes at all.

Where did Allison get her most important discovery of the first quarter?

• From an exit interview with a departing designer named Hannah.
• From a strategy meeting with the executive board.
• From an online survey about team health.

What did Hannah say was the real reason people leave their jobs?

• Bad Figma files and messy component libraries.
• Low salaries and long commuting hours.
• Bad alignment between executive expectations and daily reality.

Sources: photo by Startup Stock Photos on Pexels