How to Work with Sandeep Baskaran

TL;DR

If you only read one section, read this.

1. I define success before I design. I need the business outcome we're driving toward—I design far better when I know why it matters.
2. I'm radically open and direct. I prefer straight talk over diplomatic ambiguity, and I'd rather be told I'm wrong early.
3. I treat PMs and engineers as my closest allies. We fight hard on ideas, never against each other.

• Decisions: first-principles thinking, weighing second-order consequences.
• Communication: direct, documented, conversational—no corporate jargon.
• Credit: not a zero-sum game; there's always enough to go around.
• Organization: I really like lists. It's how I keep the chaos at bay.

How I Work

A quick caricature: when I love the work, I'm Dwight Schrute—all in, relentless, a little intense. When it's a part of the job I don't love but it still needs doing, I'm Ron Swanson—I get it done, no theatrics. And I keep a Monica-Geller level of order over all of it (the lists aren't a bit).

What good looks like to me:

• Making complex legacy systems usable for modern teams.
• Removing friction and repetition through automation or a better workflow.
• Shipping and iterating rather than polishing in private.

Principles that guide me:

• First principles: break a problem down to fundamentals before building back up.
• Speed is a feature: moving fast and iterating is the most reliable way to solve almost any software problem.
• Kill sunk costs: I'll throw away work without flinching if a better path appears.
• Empathy is a means: user empathy is critical, but solving the actual problem is the goal.

I do my best work when:

• I know the why and success is clearly defined.
• I have room to explore the system's logic, and we can iterate fast.

I struggle when:

• Success metrics are undefined.
• The work is repetitive and manual—something I'd rather automate.

Communication & Availability

I'm async-first and work roughly 10:30 AM–7:30 PM IST. Expect same-day replies on chat during those hours; I'm deliberately slow during deep-work blocks and rarely online late.

On meetings:

Async-first here too. I default to docs and threads; a meeting should exist for a decision, alignment, or a genuinely messy topic—otherwise it could've been a message. I protect my focus blocks.

When I go quiet:

I'm usually deep in focus or chewing on a hard problem. It's rarely personal—if you need a status, just ask and I'll surface one.

Feedback & Recognition

I'm radically open to feedback and prefer directness over diplomacy. It lands best when it's specific and tied to the goal we're chasing—criticism is good feedback if you listen to it unemotionally.

I give feedback the same way: direct, kind, in private, and tied to outcomes. As for recognition—credit isn't zero-sum, and honestly I'd rather see the impact than be praised for it.

Strengths, Growth & Managing Me

I'm naturally good at:

• Making sense of complex legacy systems.
• Designing for scale and automation.
• Bridging the gap between design and engineering.

What I'm working on:

• Pushing past my comfort zone until the discomfort becomes the new normal.
• I can disappear into a problem and under-communicate progress—nudge me and I'll surface a status.

If you manage me:

Give me the why and a clear definition of success, then the autonomy to explore and iterate fast. Be direct with me. If I've gone quiet while stuck, or repetitive manual work is piling up, that's usually a sign I could use support.

Quick Reference