How to Work with Sandeep Baskaran

TL;DR

If you only read one section, read this.

1. Give me the why and a definition of success before I design. I need the outcome, not just the screen.
2. Be direct. Straight talk beats diplomatic ambiguity. I would rather be told I am wrong early.
3. Treat product, design, and engineering as one loop. We fight hard on ideas, never against each other. Credit is not zero-sum.

Personality

I think before I speak. Logic-led, curiosity-driven, and a stoic over-planner: I map the possibilities and quietly brace for the worst, so I am rarely caught off guard and rarely too high when things go well.

When I love the work I go all in, a little intense. When it still needs doing but I do not love it, I just finish it. I keep lists. That is how I keep chaos at bay. I do not fill silence for the sake of it.

I do not use MBTI, Enneagram, or StrengthsFinder labels. If you need a shorthand: internal processor, logic-led, lists.

Values

• First principles. Break the problem down before building back up. Weigh second-order consequences.
• Speed is a feature. Ship, learn, iterate. I will throw work away if a better path appears.
• Do, then talk. Empathy is required. Solving the actual problem is the goal.
• Assume good intent. Still be honest about the work.
• Disagree and commit. I will argue the idea. Once the call is made, I commit to the role I signed up for, even if I would have gone another way.
• What I value in others: ownership, clear thinking, high agency, and disagreement without drama.
• Motto: Know the why. Ship. Kill the rest.

How I add value

I make complex legacy systems usable, design for scale and automation, and keep design and engineering in the same loop so the idea and the shipped thing stay close. I would rather ship a rough artifact we can poke at than polish in private.

The brief I work best from

A real problem, a why, constraints, what you have already tried, and room to explore. Anything without a clear answer already. Not a pixel-spec with no outcome attached.

Strengths, friction, and energy

• Strongest at: messy systems, removing repeated friction, bridging design and code.
• Weakest at: undefined success, repetitive manual work, surfacing progress while I am still inside the problem.
• Gives energy: a clear why, exploring how the system works, shipping, teaching, making other people faster.
• Drains energy: process for its own sake, copy-paste work, back-to-back meetings, undefined metrics.

Conditions I work in

Uninterrupted maker time and a written problem beat an open-office vibe. I do my best work async, with artifacts, not in a chain of pings. Home for deep work; in person when the problem is messy or we are actually deciding. Quiet. After a talk or community event I need to recharge.

How I decide

First principles, then second-order effects. Show the options. I would rather decide on a rough prototype than a hypothetical. If the path is wrong, I kill the sunk cost. I get frustrated when we cannot say what done looks like, or when we polish before the decision. Once we have decided, I commit — even if I argued the other way.

How to work with me

• Bring context once. Problem, goal, constraints, what you tried, the decision, and when.
• Show the artifact. A flow, prototype, clip, or PR beats a long explanation.
• Pull me in early. Messy work I can still change beats polished work after the real decisions have set.
• Gold star: bring the why, or ship something that removes friction at scale.

You can rely on me for

Honest reads on the work, first-principles thinking, sharing credit, and throwing away my own work if a better path appears. I will go into the files and the code when that shortens the loop.

I need

The why, a definition of success, autonomy to explore, and directness. If a decision, deadline, or risk changed, loop me in. I can handle bad news. I dislike finding it late.

I do not care about

Praise over impact, corporate jargon, meetings without a job, or status theatre. Small talk is fine. It is not how I build trust.

Please do not

Leave success undefined, hide risk, hoard credit, wait until the work is “ready” before I see it, or dump repetitive manual work on me without talking about automating it.

Communication and hours

I am async-first and work roughly 10:30 AM–7:30 PM IST, weekdays. Same-day on chat in those hours. Slow during deep-work blocks. Rarely online late. If I go quiet, I am in a problem. Ask and I will surface a status.

I communicate best in writing with an artifact attached. Understanding how you got to the ask helps me answer it. I struggle when the goal is foggy, or when I have disappeared into the work and have not come up for air.

Meetings and calendar

A meeting should exist for a decision, alignment, or a genuinely messy topic. Otherwise it could have been a message. I protect focus blocks. I dislike back-to-back meetings with no time to actually do the work.

Put a concrete purpose in the invite that still makes sense in two weeks: what we are deciding, what to read first, and what done looks like. Cancel if that is missing. I would rather give the time back. If a deadline is going to slip, say so before the day after.

Keep 10:30–11:30 IST as maker time when you can — no meetings in that first hour. Overlap with US/EU is my afternoon and evening. Keep those short.

1:1s and cadence

I do not need a ritual status meeting. If we have a reporting line, weekly 30 minutes is enough: feedback, decisions, unblocking. A shared doc for agendas and actions. Skip the week when the doc is empty. Otherwise ad hoc. Nudge me any time you need a status.

Feedback and recognition

• Give me feedback while the context is fresh: specific, tied to the goal, written if it is heavy, then we can talk.
• I give feedback the same way: direct, kind, in private, about the work.
• If I messed up, say so. I will not take it personally if it is concrete.
• Recognition: I would rather see the impact than be praised for it. Share credit in public.

What I hope you tell me

What worked. What I should change. What you would do if you were me. I will take that as a gift, not an attack.

Trust

Trust grows when you own the outcome, show your thinking, raise risk early, follow through, and push back clearly.

It shrinks when success stays undefined, risk is hidden, credit is hoarded, or the work becomes process and optics.

How I can be misread

• Quiet is usually deep work or processing, not anger. It is rarely personal.
• Intensity when I love the work can feel overbearing. Say so.
• Directness can land blunt. It is about the work, not the person.
• If I am dissecting a point, I am trying to get to a better answer, not to win a debate.
• A delayed reply is not a no. Ping if you need one.

Quirks and blind spots

• I can disappear into a problem and under-communicate. Nudge me.
• I keep lists, and I would rather automate a boring loop than live in it.
• I used to over-systematise. Push back if we need a scrappier loop.

Boundaries

Protect my focus blocks. Do not treat late-night silence as a problem. Do not fill a calendar with meetings that could be a doc. Do not expect me to thrive in context-switching all day.

How I define success

We agreed what done looks like, we shipped, and we removed real friction. Consistent progress toward that beats looking busy. Transparency over politics.

If you manage me

Give me the why, a clear definition of success, and the autonomy to explore and iterate. Be direct. The two signs I need support: I have gone quiet while stuck, or repetitive manual work is piling up.

What I care about

Building things, teaching, and making other people faster at their craft. Community work (Friends of Figma, Notion, chennai.design) is part of that, not a side hobby.