🇷🇺
Pavel Samsonov
EM
Contact me

Manager README

Introduction (The “Why”)

“I wrote this document to shorten the time we spend ‘getting used to each other’. It describes my principles, communication style, and what I value in engineers. It’s not a set of strict rules, but an operating manual for your manager.”

1. My Principles (My Philosophy)

  • System > Heroics. I don’t value late-night fire-fighting. I value boring, predictable releases and well-tuned alerts. If we have to play heroes, the process is broken and must be fixed.
  • Trust by default (Trust Battery). I hire smart people not for micromanagement. You get 100% trust at the start; micromanagement kicks in only when transparency is lost.
  • Outcome > Process. I don’t care how many hours you sit in IDE. I care about the value we deliver and the impact on metrics (TTM, DAU, Stability).
  • Right to err. Making mistakes is normal; hiding them is not. I build a blameless culture where it’s safe to fail, learn in postmortems, and move on.

2. Communication Style

  • If it’s not written, it doesn’t exist. Every meeting ends with Summary / Action Items; agreements are captured in Jira/Confluence.
  • Radical transparency. I share context top-down as openly as possible and expect the same: if there’s a risk to miss the sprint — say it immediately, not at the demo.
  • Asynchronous first. I respect flow state. Message me without expecting an instant reply. If it’s urgent — call.

3. Meetings and 1:1s

  • 1:1 is your time. Not a status meeting, but time for growth, issues, mental health, and career. I prepare and expect you to do the same.
  • No agenda, no meeting. I avoid meetings without a clear goal and agenda.
  • Open Door Policy. My calendar is open: if you need to discuss something urgent, book any free slot.

4. How I give and receive feedback

  • Direct and tactful. I talk about growth areas plainly and with facts, always one-on-one. Praise — publicly.
  • Feedback is a Gift. I ask for feedback on myself. If I become a bottleneck (e.g., over-designing a feature) — tell me. I value it and won’t take it personally.

5. My “bugs” (Known Issues)

  • Can dive into details. Sometimes I slip into “engineer mode” and go too deep or take the Feature Lead role. If I block you — say, “Pavel, step aside, we’ll handle it.”
  • Process overengineering. I like tables/flows and might propose too complex a process for a simple problem. Challenge me: “Why do we need this? Can it be simpler?”