My Management README

Creating the conditions for designers and product teams to make better decisions. Not providing the answers. Not signing off on screens. Setting the frame, giving the context, and letting people do the work they are here to do.

Context always comes first. Before talking about the solution, we talk about the problem. Before talking about the problem, we talk about how you're doing. That's not a formality. Someone under stress doesn't really think, and it's with people who can think that we build what lasts.

The default posture is coaching, not directives. That means I ask questions rather than give answers. It also means that when you need a clear decision, I make it. Coaching isn't dodging. It's a choice of timing.

Zooming out is my natural move. A local observation becomes a collective issue, which becomes a reusable principle. That's my way of making sure we act at the right scale. It can be useful. It can also be irritating when you need a concrete, immediate answer. Tell me, I know how to come back down.

What doesn't work gets named clearly. But within a frame that lets you grow, not defend yourself. Feedback is frequent, direct, and always contextualized. Never in front of others except to celebrate.

Conversations end with personal attention. 'Take care of yourself.' 'Are you managing to disconnect?' These aren't formulas. It's a statement of value: the person in front of me matters beyond what they produce.

Giving you the full context, even when it takes time. You should never have to guess why we're doing something.

Protecting your creation time. Useless meetings, poorly framed requests, manufactured urgencies: filtering them before they reach you is my job.

Giving you regular feedback, not just at review time. If something is off, you'll know quickly. If something is going well, you'll know that too.

Looking for growth opportunities with you. Not imposing them, identifying them together and making them accessible.

Documenting what needs to be documented so your work survives and evolves without me. What I build with you has to be something someone else can pick up.

That you ask the questions you have. Even if they feel basic. Especially if they feel basic.

That you take a position on the design topics that concern you. I'm here to challenge and refine, not to decide for you.

That you give me feedback on how I work with you. What helps you, what blocks you, what's missing. The more concrete, the more useful. And I'd rather receive it directly than through a third party.

That you take care of your balance. Work done well takes energy. Energy takes rest. That part isn't negotiable.

Every week, one hour, protected. That time is yours.

Every person I have a 1:1 with has a personal space shared with me. A living document where you prepare your topics before we talk. I read it beforehand. That lets us go deep rather than spend the time catching up.

The space is structured around five points:

• Top of mind: the key topics to keep in mind for this 1:1.

• Updates: what you've moved forward since our last conversation.

• Roadblocks: your current obstacles or points to clarify.

• Highlights: your recent wins, small or big.

• Feedback: your ideas, feelings or suggestions to share.

My comments and feedback go in there too. The document grows over time and becomes a useful trace of your progression, your recurring topics, and the decisions we've made together.

What I'm looking for there: understanding where you really are. Not a status update, not a task list. How you feel about your projects, what slows you down, what energizes you, what you need.

Questions I will probably ask:

• How are you doing, for real?

• What took most of your energy this week?

• What would you have done differently?

• What do you need from me?

The work doesn't stop at the borders of the direct team. Several rituals structure how I collaborate with the other product leaders.

• With leadership above me.

  A weekly 1:1 where I carry the voice of design into strategic discussions. What I build with the team, I make visible and defensible at that level.

• With my peers.

  Regular 1:1s with the other product leads, especially the Heads of Product Management. These conversations serve to align visions, share context, and build a common reading of priorities before they reach the squads.

• The 2:2s.

  A format I started: twice-monthly meetings of four, where the design lead and the PM lead of the same squad sit down with me and their counterpart on the product side. The goal is simple, syncing at squad level without going through message chains or debrief meetings. Four people, one shared context, faster decisions.

These dynamics aren't peripheral. They are the fabric that keeps design from working in a silo. A design conviction that stays inside the design team is a conviction that changes nothing.

The written message first, the meeting second. A well-written Slack message solves 80% of topics faster than a call. When the topic is complex, ambiguous, or emotionally charged, we switch to synchronous.

To tell me something is wrong: directly. In writing or in a 1:1, whichever you prefer. What I can't handle is what I don't know. The earlier, the better.

For feedback on my management: same thing. My reaction isn't always immediate. I absorb, I reflect, and I act. If you feel your feedback fell into a void, nudge me again. It's probably working in silence.

A few things I know about myself that you should know too.

• Feedback gets absorbed in silence.

  My first reaction to important feedback is rarely visible. That's not indifference, it's processing. But it can give the impression the message didn't land. If you have a doubt, ask.

• Zooming out too fast, sometimes.

  A concrete question can trigger in me a systemic reflection that isn't what you needed at that moment. Don't hesitate to bring me back to the point.

• My natural energy goes toward building rather than making visible.

  Building a conviction, a framework or a system comes more easily to me than making sure everyone reads and adopts them. It's a builder's bias I'm actively working on. In practice, that means putting more and more attention on communicating what the team produces, not just on the production itself.

• Documenting a lot, maybe too much.

  The reflex to put everything in writing is a strength when it creates clarity. It can become a brake when action would have been enough. That balance is something I keep working on.

This README describes a practice in motion. AI is transforming how product teams work, and with it, the very nature of design management.

A growing share of leadership no longer flows through classic rituals. It flows through the systems we build and share: context files that let a PM carry design without waiting for a review, documented frameworks that guide a squad without me in the room, workflows with agents that absorb part of the work a junior profile did two years ago.

That doesn't mean less management. It means management that is shifting. Less time transmitting information in meetings, more time designing the conditions for information to circulate without me. Less production management, more architecture of shared systems. The 1:1 stays. The human attention stays. But the ground leadership stands on is moving.

This README will move with it.