Photo by Pierre Goiffon on Unsplash

On Design Management, Part 1: Learning by Doing

In this article, I’ll share some lessons I learned leading a design team and working with product managers, engineers, and executives.

Leading a team was a shift in mindset, responsibility, and impact. As an individual contributor, I focused on solving design problems, creating smooth user experiences, and owning the quality of craft. But as a leader, the canvas broadened to designing for teams, processes, and environments where great design could thrive.

I’ve reported to some fantastic managers. They always had the team’s back, were good listeners, kept promises, critiqued with compassion, and were generally frank and upfront people. They were quintessential “Servant Leaders”. If your manager is anything like this, consider yourself fortunate! I absorbed some good habits from them, and I strive to pay it forward to my team.

I’ve condensed my learnings into these themes:

1. Know your team
2. Know yourself
3. Overcommunicate
4. Assume good faith…
5. … but maintain boundaries
6. Seize opportunities
7. See the totality

Know your team

Musicians play instruments, and the conductor plays the orchestra. While every musician is obliged to perform their role, they’d be more passionate about some kinds of music. Because that’s what they personally connect with, it gives them joy and makes them shine.

Photo by Vin Jack on Unsplash

I put in a deliberate effort to get to know my team. I learned what they’re excited about, where they want to grow, and what doesn’t energise them as much. I was genuinely interested in knowing them and invested in their growth. I know how great I felt when my manager did it for me.

One-on-ones

There was a time I realised I wasn’t as connected with my direct reports as I’d like to have been. I was running into surprises — their workload imbalance, their progress on a project, their morale, etc. I wasn’t aware of little tasks quietly rolling in from others, and they didn’t think to tell me either. Sharing feedback was affected too. While I’d give specific work-related feedback in review meetings, it was hard to know when to give general feedback, or to check in on how they were doing.

Many of these got resolved with fortnightly 1:1s.

Photo by airfocus on Unsplash

I usually kept the agenda open and let the designer lead the conversation. It was an open space for them to discuss anything on their mind, and I was there to listen. Feeling heard, they began to reach out more frequently, and shared their thoughts more candidly.

Sometimes I’d go in with something to say — like thoughts on how they’re handling a project, giving them a heads-up about an upcoming project, prepping for goal-setting, among others. Prior to the 1:1, I’d make a note of this somewhere so I wouldn’t forget to bring it up.

Taking bets

Knowing the designer better, I’d keep an eye out for growth opportunities. Some examples:

In a 1:1, a junior designer let me know that they’d like to break into product design someday. For a period of time after that conversation, I observed their product thinking, initiative, and energy. I identified a project that needed a small proof-of-concept to be designed, and decided to take a bet by letting them design for it. Because this proof-of-concept could exist separately from other projects, it would limit any damage done in case they messed up. Thankfully, they exceeded expectations. Through their own talent and hard work, they’re now working as a product designer full-time.

One other product designer was keen to come out of their shell and exert more influence. In a 1:1 meant for quarterly goal-setting, we dedicated one goal to increasing visibility and exerting influence. I’d encourage them to step up and present more often. With the confidence that I was always in their corner, they expressed more freely in meetings with stakeholders, and started presenting to larger groups. At the end of the quarter, they felt more comfortable speaking their mind.

Know yourself

We interact with all of the outside world through our mind. And if we observe carefully, we’ll realise that our mind often adds its own “colour” to everything that we see, hear, touch, and feel.

For example — when someone gives me new information, shares a new idea, gives critical feedback, deviates from a plan, or breaks an expectation, I check in with how I feel internally. Do I feel tense? On edge? Do I have urgent thoughts that reject the idea? Do I feel like responding aggressively? Before giving time and presence, it’s hard to tell apart a good idea from a bad one, useful feedback from harsh criticism, and a lesson learned or time wasted.

I learned that I’d sometimes jump to make judgements. The ability to pause and make space before making any judgement is precious. A consistent meditation practice helped me. Find out what helps you know yourself better.

Learning to think first rather than react quick is a life long pursuit. It’s tough. I still get hot sometimes when I shouldn’t. But I’m really enjoying all the benefits of getting better.

— Jason Fried, in “Give it five minutes”

Over-communicate

The point is simple once understood: identify who cares about what, and communicate so frequently that nothing surprises them.

All problems are messaging problems — fully, largely, or partly.

— Shreyas Doshi, on X

An example:

I was managing three different projects with completely different teams, and each team was pursuing a different goal. The catch was that the team working on one project was responsible for making design system components which the others would need to soon reuse. Once the other teams had made enough progress in their work, they’d be restricted by the pace set by that project. To move fast, we needed to make decisions without complete information. The risk needed to be factored in.

If not handled well, Design could become a potential point of friction. Designers could be pressured to deliver faster and with compromised quality. Work could come out late and poorly finished, reflecting badly on a talented team. In truth, there were too many projects green-lit by an upper management that was perceived as eager to prove themselves. But in that moment, expressing this without tact would be seen as uncooperative. We had to roll with the punches.

Just acknowledging this was half the battle won, I realised. Because the teams had nearly no overlap in members, but work was interdependent, communicating frequently allowed them empathy for all the moving parts.

Managing across

1. Frequent alignment checks: After every meeting, I’d send a Slack message or email clearly highlighting what we agreed on, and what the team would do next. This acted as an alignment check.
2. Account for extra work: After this, if any extra work came our way, I’d immediately flag this to all stakeholders. Sometimes it isn’t anybody’s fault, but a result of making decisions with limited information. I’d negotiate to extend the timeline or trim the scope. Unfortunately, I’ve seen teams silently accepting their fate and doing extra work without extra time. It doesn’t need to be this way.
3. Involve Engineering early: Instead of waiting till all the design work was complete, I’d schedule conversations with engineers early on. Here, they’d learn the “why” behind the project, how the design team was approaching a solution, and maybe even offer their own solutions. It mentally prepared them several weeks in advance and made them feel more invested in the final outcome. It resulted in smooth sailing later on.
4. Identify conflicts of interest: Being experimental in nature, one project needed us to take on design debt to ship and learn fast. We had to temporarily bypass the design system review process. To the team responsible for these reviews, it could seem like asking them to abandon their duties! Naturally, there would be resistance. Sensing the approaching conflict, I informed the senior stakeholders and procured their written approval to temporarily bypass the review process (promising to pay off the debt soon after). This written approval allowed me to assure the designs systems team that this was a unique situation and they wouldn’t be held accountable by their managers. With the complete understanding of the situation, they were happy to co-operate.

Photo by Brooke Cagle on Unsplash

Managing down

1. Set clear expectations: After review meetings, I’d send the designer a list of feedback points and actionable items. It would set clear expectations on the work to be done, guided them to focus on high return areas first, and clarified what we would review in our next meeting.
2. Create focus time: While staying on top of information is good for a manager, no designer enjoys responding to unpredictable status requests. After checking in with a designer, I’d let them know (or ask) when we could check in next. This would allow them uninterrupted focus time in between.
3. Keeping my own records: I’d keep a document updated with all the areas covered by my direct reports. Having this information on hand allowed me to negotiate scope with stakeholders. Since the designer didn’t need to be pulled in, they could work with uninterrupted focus.

Managing up

1. Frequent updates: I’d keep my manager posted with frequent and regular updates. It prepared them in advance for any discussions with peers, empowering them to make informed decisions without depending on me to fill them in at short notice.
2. Ask for help: In my 1:1s with them, I’d seek their advice on handling situations. Sounds simple, but sometimes we forget to ask for help!
3. Ask for them to step in: If I needed to influence a stakeholder above my level, I’d ask my manager to step in and speak with them instead.

Result

In the absence of complete information, stress causes some people to assume the worst. Frequent communication fills in these gaps and nips misalignment in the bud. It creates a shared model of reality and increases empathy among all stakeholders. Conflicts become less charged and could be handled peacefully.

Keeping promises

It dawned on me that I was making promises to a lot of people. Here’s what promises look like:

• Agreeing to schedule a design review with the product manager once a milestone was reached
• Reading a concept note and reverting to the author
• Sharing an asset with a team by end-of-day
• Making sure a rescheduled team sync actually happens
• Responding to a Slack message
• Approving a direct report’s leaves

It’s usually too much keep in mind, especially when missing a few of these doesn’t immediately result in repercussions. But there are two advantages that play out long-term:

1. Trust is built brick-by-brick: Fulfilling small promises reinforces trust and signals reliability. It reduces anxiety in the working relationship.
2. Unblocking people early allows me to focus better: If I’d wait for people to reach out when they couldn’t stay blocked for long, I’d be reacting to their circumstances instead of responding at my own pace. Proactively reaching out allowed me to stay in my natural flow, and people got their work done on time — everyone’s happy.

I solve this by delegating promises to a to-do list app as soon as they are made. The mind is then clear to focus on more important matters. Later, I check in with the app and cross these off.

I use a highly customised Notion workspace, which I’ll talk about towards the end of this article.

My Notion workspace

Assume good faith…

It’s a fact of life that not everything goes according to plan. Reality plays out as-is, unbothered by our expectations and desires — our job is to find out and adjust our approach. After making a plan, it helps to approach deviations with curiosity, being less attached to our expectations and treating them as suggestions instead.

If a designer is missing deadlines, it helps to check if they’re overburdened with irrelevant tasks. They might think they can’t ask for more time for fear of appearing unprofessional. Or they might have a temporary personal situation they’re battling on the side. Or they might not understand what needs to be done. Or they could be struggling with a new skill needed for the project.

Photo by Ricky on Unsplash

If a product manager is being overbearing, it might be because they’re trying to prove themselves to their new manager or team. A product manager once candidly let me know that this was actually the case. They were anxious to make an impression, and didn’t mean to be overbearing (even though it initially appeared that way). It was a cathartic conversation and improved our working relationship.

If a project manager is following up way too often, they might fear being left out of the loop. Since they’re on the hook for timely delivery, they might panic at a lack of information. And instead of healthily expressing their concern, they might micromanage. Candidly speaking one-on-one let them share their concerns. Then we’d work out how they could stay informed in a way that designers aren’t frequently interrupted or feel constantly monitored.

Sometimes, engineers reject ideas too quickly or struggle to match the design vision. They might be scrambling to meet tight deadlines. Or the design documentation hasn’t been clear enough. Or they’ve had past experiences where they’ve been punished for experimenting. It helps to understand their obstacles so we can work with them and not against them. After all, we rely on them to execute the design vision.

There is a pattern here. Most situations can be arrived at a peaceful resolution through dialogue and listening. Most people do not intend to sabotage us (even though that might happen). Assuming good faith brings down defences and builds connection between humans trying to do the best they can with what they have.

… but maintain boundaries

Here are some boundaries that are important to me, and how I maintain them:

Working hours

Regularly working weekends or late nights can be a symptom of mismanagement, and that’s where I’d start my investigation.

For example, a stakeholder might demand an unreasonable turnaround time. It could be due to their own poor time management skill, or because they’re stressing out about an important task.

A frank conversation reveals a lot. Maybe they never did need the work urgently, but they panicked and decided to get the work done early and give themselves time to breathe (unknowingly, at my team’s expense). Once this was clear, we’d then agree on a more reasonable timeline.

But if the work really was urgent, I’d investigate if

1. they missed an opportunity to inform us early
2. they agreed to a delivery date without checking in with us

I’d urge them to take responsibility for their lapse, express how this negatively affects the team, and work out a solution with them. It’s been my experience that doing this reduces conflict in the future.

But there are times when working into the night or on a weekend is genuinely unavoidable. It helps to communicate this to the team with total honesty, understand if and how they’re positioned to work in their personal time, and assure compensatory time off. In my experience, the team has been happy to contribute to an important cause, even at the cost of the occasional extra effort.

Design scope and timelines

It’s on the manager to set up an environment where designers can output quality work. But there could be several “thousand cuts” which affect a design team’s quality of output.

• Some designers need help prioritising work. If their time and effort could yield better returns on other areas that they aren’t focusing on, it helps to give them a full view of the project, share a perspective on which tasks require more focus, and prioritise those instead.
• Some designers need help saying “no”. It’s a great sign if designers have an open line of communication with their peers in product management and engineering. But sometimes, tasks that come in laterally can shake their focus and affect the quality of their main tasks. It helps to let them know that saying “no” is perfectly alright, and if they’re unable to do so, bringing me in can help.
• But sometimes, a direct report can simply be unmotivated. To keep matters objective, I’d make a note of instances where they’ve not met expectations. Peer feedback (if it exists) also goes into that note. Then in a 1:1, I’d let them know where they need to do better, leading with curiosity and keeping my emotions grounded. It’s a difficult conversation but we need to do our jobs, and it’s the manager’s job to root out inefficiencies.

Output quality

I believe that Design should completely realise the design vision by also owning the final output. This means that we need to get Engineering to match the level of finesse that the design vision asks for.

• If engineers push back on a certain design, I’d aim to change the conversation from “we can’t do this” to “here’s how much time we’d need”. This then becomes a conversation of whether that time is best spent perfectly implementing that design, or exploring a middle ground solution that also doesn’t compromise on our UX goals.
• If output quality isn’t meeting the bar, engineers might need a little help in the way of more precise instructions. Strong handoff documentation and motion specs go a long way. I’ve written more about this here: Craft Meets Code: Upgrading the JioCinema Carousel. You’ll be stunned at how quickly they implement the design once armed with thorough documentation.
• It’s been my experience that some engineers operate more in fear, which causes them to be closed off to trying new ideas. If a conversation with them doesn’t help, exploring solutions with the engineering lead might, since they’re also responsible for quality output from their team.

Seize opportunities

So far, I’ve written about how I manage people and work by responding appropriately. But I realised it’s important to also scout for opportunities that push the Design function to make things happen. This can be accomplished by listening and connecting the dots.

By listening, I mean

• paying close attention to what the company needs at that time and how leadership wants to move ahead
• knowing what product and business teams have identified as revenue opportunities
• understanding how a project will contribute to the company’s goals

At the start of a project, I’d have an in-depth discussion with the product/business partner about how the feature will play a role in the larger strategy. Would it…

• unlock a new market and potential revenue?
• plug a gap in the user flow and reduce drop offs?
• unlock more value that people would be willing to pay for?
• increase session duration per user, resulting in increased ad revenue?
• improve public perception, NPS scores, and app store ratings?

The goal is to not let Design slip in to a “service” role which takes orders without understanding impact, and to push towards a more active role that helps shape strategy.

And to connect the dots, we need to identify design tasks that move us towards these goals. We need to articulate this when given the opportunity.

Here’s an example:

1. It was early stages of design maturity for the company. UI fragmentation was rife. The same product behaved in different ways depending on where it was used. But getting the team to stop working on revenue-generating features and start rebuilding the foundations was a tough case to make. Designers and engineers were building components from scratch, resulting in redundant and fragmented work.
2. At a quarterly townhall, company leadership announced that the next quarter would see us moving slower and fixing things. This was an opportunity.
3. I huddled the team to make a list of areas that needed design love. It included everything from fragmented UIs across platforms and inconsistent typography, to excessive variation in colours. Given that we had only a quarter, we prioritised select items.
4. Every other Friday, there was an opportunity to engage with product leadership. People would present product documents, concept notes, and working prototypes. I signed up for a presentation.
5. The presentation focused on introducing a grid system, and consolidating highly-repeated design components. By tweaking a few components, we would see a huge impact on the product and also fix our foundations.
6. The presentation had something for everyone — engineers got a chance to pay off tech debt, product managers didn’t need to worry about metrics getting affected, designers could start building a design system, and everyone got a slicker product experience at the end of it.
7. It also articulated how the platform would look after these changes, emphasising the improved public perception along with the fixed foundations. It was presented as a necessary slowdown today to move fast tomorrow. The project was green-lit.

Seizing such opportunities allowed the team to work at its own pace, on areas it cares about, while demonstrating their value to the leadership, resulting in increased influence and recognition.

Seeing the totality

Earlier in my career, I’d be obstinate about the design outcomes of a project. While the intention was to deliver the best possible experience to the end customer, I faced resistance, which confused me. With time, some things became clear.

1. Many industries do not derive business value from giving their end customers a differentiated experience. Some company strategies do not need a superior product experience to be successful. Knowing this will explain any resistance you might face when you push for the best design possible.
2. Some companies naturally value design, understand the subjective nature of user experience, and appreciate the attention to detail and effort needed. Others need to be sold on it. See “Design-Driven Companies. Are We There Yet?”, by Mike Davidson.
3. Not everyone may share the same vision of what’s best for the customer. The design team can take initiative to define the persona, articulate the design vision, and spark a two-way dialogue between them and the rest of the company.

Stepping back and seeing the totality of the project, company or industry helps us know where design intervention is most effective, and how to push boundaries when opportunities present themselves.

Conclusion

Doing great design work requires a healthy support system, and I’ve realised that’s where a manager needs to shine. I’ve also realised that I didn’t need to abandon the skills I learned as an individual contributor. In fact, they told me what my direct reports needed to do their best work. It’s been a fulfilling transition and I look forward to doing more. Thanks for reading!

More in Part 2…

I designed a custom Notion workspace that helps me keep track of tasks, commitments, meetings, and everything else needed for people around me to function smoothly. In Part 2 of this series, I’ll dive deeper into the “how” and “why” behind the design of this workspace.

Read Part 2 here: On Design Management, Part 2: Designing a Cockpit for the Mind.