How to Work with Sandeep Baskaran

Why This Document Exists

I've created this user guide to help you understand how I work and how we can collaborate most effectively. Instead of spending months figuring each other out through trial and error, I hope this accelerates our working relationship.

This isn't a rulebook you must follow perfectly—it's guidance to help us work better together. I'm always growing and open to feedback about how I can be a better colleague. I encourage you to share how you work best too. I'd love to adapt to your preferences as well.

TL;DR - The Quick Summary

If you only read one section, make it this one.

The Three Most Important Things to Know:

1. I define success before designing. I always start with defining success, documenting process, and understanding why it matters. I need to know the business outcome we're driving toward.
2. I value radical openness. I believe in being radically open to feedback. I prefer direct communication over diplomatic ambiguity.
3. I cherish the PM partnership. I care deeply about the product's soul, which means I view PMs as my closest allies. We might "fight with each other" on ideas, but never against each other.

My Working Style in Brief:

• Personality Type: <updating this soon>
• Decision-Making Style: First-principles thinking and second-order consequences.
• Communication Style: Direct, documented, and conversational.
• Philosophy on Credit: Credit is not a zero-sum game—there's always enough to go around.
• Organization: I really like lists. Like, a lot. It's how I keep the chaos at bay.
• Collaboration Preference: Collaborative and iterative.

How I View Success

What Being Good at My Job Means to Me:

• Designing tools that make complex legacy systems usable for modern teams.
• Removing friction and repetition through automation or better workflows.
• Balancing the 'creative itch' with the absolute necessity of getting things done.
• Contributing to a "larger picture" where technology empowers users.

Values That Guide My Work:

• First-Principles Thinking: Breaking problems down to their fundamental truths before building up.
• Iteration Velocity: Speed is a feature. I believe moving fast and iterating is the most reliable way to solve almost any software problem.
• Second-Order Consequences: Considering the long-term effects of immediate decisions.
• Killing Sunk Costs: Sunk cost fallacy is the root of all evil. I'm never afraid to throw away work if it means taking a better path forward.
• Decision Quality: My #1 leadership metric. It's about the process and anticipating the downstream effects.
• User Empathy as a Means: Empathy is critical, but solving the actual problem is the goal.

What I'm Optimizing For:

I design better when I know why it matters. I'm optimizing for clarity, efficiency, and meaningful impact on the user's workflow.

Working Hours and Availability

My Typical Schedule:

Time Zone: India Standard Time (IST)

My Availability:

• Deep Work Blocks: <updating this soon>
• Open for Meetings: <updating this soon>
• Responsive Windows: <updating this soon>
• Outside Work Hours: <updating this soon>

Calendar Guidance:

<updating this soon>

Communication Preferences

Preferred Channels by Situation:

My Communication Style:

Direct, documented, and focused on clarity. I avoid corporate jargon. I like to "vibe code with my stack" which means I appreciate technical context even if I'm designing.

What Works Well When Communicating With Me:

<updating this soon>

What Doesn't Work:

<updating this soon>

Email Specifics:

<updating this soon>

Chat/Slack Specifics:

<updating this soon>

When I Don't Respond Quickly:

<updating this soon>

Meetings

My Philosophy on Meetings:

I generally prefer to avoid meetings unless there's a clear purpose. I value deep work blocks for design and thinking.

What Makes a Meeting Worthwhile for Me:

<updating this soon>

My Meeting Preferences:

• Format: <updating this soon>
• Preparation: <updating this soon>
• Duration: <updating this soon>
• Time of Day: <updating this soon>

For Meetings with Me, Please:

<updating this soon>

1:1 Meetings:

<updating this soon>

Collaboration Style

I Work Best When:

• I know the "why" behind the project.
• I have freedom to explore the system's logic (first-principles).
• We can iterate rapidly.

I Struggle When:

• Tasks are repetitive and manual (I prefer to automate).
• Success metrics are undefined.

My Decision-Making Approach:

I use first-principles thinking to understand the core problem and second-order consequences to anticipate downstream effects.

How I Like to Give Input:

<updating this soon>

Working Through Disagreements:

<updating this soon>

Feedback Preferences

How I Prefer to Receive Feedback:

I am radically open to feedback. I prefer directness.

What Helps Feedback Land with Me:

<updating this soon>

What Makes Feedback Harder to Receive:

<updating this soon>

How I Typically Give Feedback:

<updating this soon>

How I Like to Receive Recognition:

<updating this soon>

Things That May Annoy You (My Quirks)

Behaviors I'm Aware Of:

<updating this soon>

Things People Sometimes Misunderstand:

<updating this soon>

Please Call Me Out When:

<updating this soon>

What Gains and Loses My Trust

Actions That Build Trust With Me:

<updating this soon>

Actions That Erode Trust:

<updating this soon>

How to Earn a "Gold Star" With Me:

<updating this soon>

My Strengths

I'm Naturally Good At:

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

How I Can Help You:

<updating this soon>

People Often Come to Me For:

<updating this soon>

My Growth Areas

Known Blind Spots:

<updating this soon>

What I'm Actively Working On:

Going outside my comfort zone until that discomfort becomes the new normal.

How You Can Support My Growth:

<updating this soon>

Where You Might Need Patience With Me:

<updating this soon>

If I Manage You

*Skip this section if not applicable.*

My Management Philosophy:

<updating this soon>

What I Expect from People I Manage:

<updating this soon>

What You Can Expect from Me:

<updating this soon>

How I Approach 1:1s:

<updating this soon>

My Approach to Delegation:

<updating this soon>

My Approach to Career Development:

<updating this soon>

When You Should Escalate to Me:

<updating this soon>

When You Should Handle It Yourself:

<updating this soon>

If You Manage Me

*Skip this section if not applicable.*

What I Need from My Manager:

<updating this soon>

How to Get the Best Work from Me:

<updating this soon>

Signs I Might Need Support:

<updating this soon>

How I Prefer to Be Managed:

<updating this soon>

Context: My Current Role and Focus

My Role:

Design Engineer at IBM, building tools to modernize enterprise legacy systems.

My Current Priorities:

• <updating this soon>
• <updating this soon>
• <updating this soon>

Teams/People I Work Most Closely With:

<updating this soon>

Projects I'm Currently Focused On:

<updating this soon>

Fun Facts

• Outside of work, you'll find me: Watching backpack reviews, movies, or organizing things.
• Conversation topics I enjoy: Design, AI, productivity, and tech.
• Fun fact about me: I once broke a camera to see what was inside.
• My coffee/tea order: <updating this soon>

Quick Reference Card

Essential Summary:

When I Go Quiet, It Usually Means:

I'm processing a complex problem or deep in focus work.

If Something's Urgent:

<updating this soon>

Document Information

• Author: Sandeep Baskaran
• Role: Design Engineer
• Last Updated: January 2025
• Next Review: April 2025

Version History

Appendix: Working with Me - Scenarios

If You Need a Decision from Me:

<updating this soon>

If You Have Bad News to Share:

<updating this soon>

If We Disagree:

<updating this soon>

If You're Blocked and Need My Help:

<updating this soon>

If You Want to Give Me Feedback:

<updating this soon>