User manual for Slav


OK, so you want to know more about me. Here is a manual on how to work with me. Keep reading.

Random things about me

  • I answer to Stanislav; Slav preferred the occasional Slava, "Hey you," or any other nickname you see fit.
  • My family consists of my wife Simona and my girls Anika (born in 2018) and Monika (born in 2021).
  • If I had nothing to do, I would spend my time sailing with a boat, trailing mountains, or building children's tree houses.
  • I went to university to become a software engineer, but after 5-6 years into it, I saw that project management is way more exciting. I didn't have the nerve to sit and code all day long anymore. However, while working on my startup Rush, I eventually coded for 2 years, becoming the first product architect in the company. Life is funny!
  • I have worked remotely since 2005, significantly shaping how I work, how I structure, and how I measure success.
  • I'm focused on results; most of the time, it is a messy process, so I might not always seem a well-organized manager.
  • I'm more of a picture person - I like to draw and create mindmaps (Miro or paper) for myself to help me out, but I'm not a word person. Sometimes, when I'm in the heist, it is not easy to communicate with me. I'm aware, and I try to keep it in check.
  • I focus more on that 80% that gets done with 20% effort rather than always being 100% perfect. I found perfection is needed on rare occasions, and the results of achieving it are always diminishing.
  • I value the relationship with my team and the people I work with, and I always treat them as professionals they are.

My Schedule

  • Being located in Europe, I usually start work around 7:00 AM UTC (9:00 AM), and stop work around 3:00 PM UTC. I'm mostly unavailable from 3:00 PM to 6:30 PM as this is when I have dinner with my family and play with the kids.
  • I am also generally online, so I don't mind getting notifications and messages. I answer them as soon as I'm available. I also prefer to have Friday free of meetings, as I usually try to get more work done or wrap up/prepare for the next week.
  • I'm genuinely flexible and arrange my routine to align with the teams I work with, providing ample time for collaboration and communication.

My Rules

During my last years in multiple companies, I found the following principles to help me navigate and guide product development, especially focused on growth and early success. It shows in a nutshell how I operate:

  • Be the role model of the behavior you want to get.
  • Empowered team over Super Shiny Stars.
  • Releasing a feature is third of the actual product work.
  • You rarely get it the result from the first try.
  • Start small, iterate on it until you get it right.
  • We are both wrong until the data.
  • Success is measurable.
  • Done is better than perfect.
  • Why?Why?Why?Why?Why?


When there is a complex problem, I simplify it first - break it down into multiple sub-items. If the smaller problems can be clearly defined, are worth solving, and have enough data to back us up, I move forward with problem-solving and defining success.

I also understand that there are cases where data can't be collected, or data is biased. For those cases, I prefer to move forward with a quick decision that addresses the immediate problem while providing more light on the problem. A better fix can be applied in the next iteration armed with a deeper understanding of the problem.

I would in almost most cases prefer to launch a series of hypothesis tests, to validate it, before a asking development team to code a solid solution.



Handling conflicts


What I value

  • Good strategy - starting with the problem and having a logical, simple possible solution or test to validate it.
  • Responsibility - jumping in and owning a problem (whether or not it falls strictly in your area) and shepherding it through to the right people to solve it.
  • Reliability - being trustworthy when it comes to communicating and delivering what has been asked of you. I can toss you something and trust that you've got it and that you will tell me if you need help.
  • Efficiency - using the team's time wisely.
  • Collaboration - working with teams in a way that takes advantage of everyone's strengths to get to the best conclusion.
  • Growth mindset - learning from failure, being open to feedback, being introspective, and keeping an eye out for ways to improve versus waiting for feedback.
  • Proactiveness - don't sit around waiting for something to fail. Step forward and try to address the issue you see. If it is not actionable from you - escalate it. Don't let things fall through the cracks; as they get bigger, every time someone falls down.

What I don't have much patience for

  • Prioritizing individual goals (personal agenda) over business or team goals.
  • Ego (Manifested as the inability to consider the proposals, perspectives, or goals of others. Confidence is excellent).
  • Working with people that are all talk and no action. Work with those, h@te it.
  • Unnecessary churn, wasting the team's time, creating discomfort.
  • Having others represent me or my team without my approval or input.
  • Myself when I don't have a solid handle on what's happening.
  • Generally, I have a lot of patience, so this is not a section to focus on.



I'm always on Slack and am responsive in that format to anyone who needs me. I will send emails with Google Docs for complex topics or where more documentation (i.e. decision making over communication) is necessary.

For things that require response (as well as my expectations of response speed from others), correlate with the following: Call —› Text —› Slack —› Email —› Google/JIRA doc comment. If you need an answer and I haven't responded, ping me again.


I prefer to be pinged immediately in whatever way is convenient when I can speed something up, remove a roadblock, provide a tie-breaking vote, or share some knowledge from past research/features that might be helpful. I bounce back from interruptions quickly and provide the most value when removing obstacles for my team as efficiently as possible. My favorite type of 1:1s are those that let us bang out a set of decisions or topics in a short timeframe, whereas covering them in a group would be less efficient. I don't need to know the topics in advance unless you want me to think about them more deeply before the meeting, and I am fine with just a bulleted list without a ton of detail - the whole point is to move things along.

I also get value from periodic "check-in" meetings to find out what is going well and not so well for my team so that we can adjust our work styles to help everyone be happy and productive. I love to help people and will find a way to meet with anyone anytime that could be useful.

For group meetings, where some people co-located join from the same room while others only work remotely, it harms productivity and team dynamics. I prefer everyone to join remotely if key players are remote, but I recognize that that is generally impossible in the offices.

I am somewhat dismissive of the idea that we must meet in person frequently to be effective, and I will never say no to a request to be remote for pretty much any reason. I expect people will maximize the value of times when we can be together in person by using that time strategically. I consider periodic whole-remote-team meetups to be critical to the success of the company for retention and engagement, but also for alignment.

The larger the meeting, the more critical it is to have a set agenda, game plan, and expected outcomes. I am fine if that is not shared in advance as long as it exists and can be clearly communicated in the meeting and followed up on.