# Oren Keinan's Manager Readme

**VP R&D at Solitics**

# Motivation for this document

I wrote this document to share my expectations on what would make it most effective to work together, and so that you can hold me accountable for it. Use this document as an intro into my mind and how I like to operate: my mental and operational frameworks. I believe that these topics would help you become more effective and reduce managerial overhead on my side.

We’ll spend our 1:1s to get to know each other a bit better, of course.

# My role

TL;DR: I am here to ensure our team is successful, happy, and working on the things that are most important to help our users, improve our product and our business.

As the VP R&D at Solitics, I’m measured by:

- Enabling hyper-growth with a “default to yes” mindset (i.e. we can do anything the business needs us to), while providing clear tradeoffs to relevant stakeholders.

- Our ability to retain and attract talent over time by deeply taking care of who we have, and building an Engineering Brand in the relevant market(s). We will lose some people over time, but I’ll measure myself by asking you this question: “Do you feel that the team’s EQ, IQ, hunger and speed are getting better over time?” -- if the answer is “HELL YES” then we’re on the right path.
- Setting a clear context so people can be successful, connecting the dots between what the company needs and what the individual needs (career growth).
- Iterating on our processes and technology to build a scalable organization (first) and scalable business (second).
- Mentor individual contributors and managers to increase our leadership capacity.  
  

**I serve you, not the other way around**. I’m always available to assist. Ask me.

You work for Solitics, not for me nor for your direct manager. Optimize for Solitics.

I’m making mistakes, and I want to improve just like you. Hold me accountable. Tell me.

If I do something that negatively impacts my ability to retain you, you would be doing me a huge favor if you let me know about it as soon as possible

### 

### My personal values

- **Generosity**  - everyone is important, everyone can make a difference, so I always prioritize people first. Being generous to people with time and kindness allows me to support everyone effectively.
- **Honesty**  - let’s always do what is right even in the harder moments. Always evaluate the pros and cons but decide for the good of all. Always strive to be honest, and have the courage to uphold honesty even in challenging situations.  
- **Empathy**  - be kind and care for others no matter who, where and when!
- **Positive Mindset**  - this helps me and all of the people I work with in being motivated even when the situation seems endless. I strive to stay strong, healthy, and positive.
- **Teamwork**  -  the only way to become successful and a champion is to do it as a team. Be a great leader, inspire and motivate when uncertainty is in place and together we will succeed! Aiming to have as diverse a team as possible and that we respect each other's opinions.    

# What do I value most?

1. When it comes to how engineering should help the business: I always optimize for the customer first, product second, project third and last - the task level. While it seems intuitive and obvious, it’s rarely the case: Most people operate at the task level without optimizing for the project. The attitude often becomes 'It will be done when it will be done'. Some people optimize for the project level without understanding how the product will be impacted by it (or challenge it). Almost no one invests time in questioning how the product can truly improve the life of the customer. We’re here to make our customers great. Have this photo hung in your room, or even better - in your mind (and then read [this](https://www.useronboard.com/features-vs-benefits/)):  

![](https://lh4.googleusercontent.com/-HJ0KLZDj91QpisimyRVc_btd8itqBGaFeJ5eLzO3RSohtHYaLaxJYNQncDi485bYq5AIeRSphFUCqa2SqbHlwyN08PVlf_D-do9iSTPp-u457iR_qH2_MeRDycBHj5xlMjYJT3s)

**What you should take from this:**

- Ask where the company is heading and understand the skills required to help us get there. It may involve a new tech stack or new methodologies. I’ll try to tell you when I can.  
- Ask for relevant training (books, workshops etc.), I’ll always default to yes here.
- If you prefer to focus on a few narrow fields and become an expert just say so. We will find the relevant opportunities together, and talk about the tradeoffs.
- Measure everything you deliver in terms of how the user will benefit from it (internal or external). This is as important as writing tests and have proper monitoring/alerts.
- I will often ask you "Why are you building that?" -- I do expect you to connect the effort you're working on (bug fix, better monitoring/alerts, new feature etc.) to how it helps the product and the company to achieve our quarterly or yearly goals

# What will disappoint me? 

1. People who focus on their own personal brand at the expense of the company's or team’s needs.  
Self-confidence is important. Don’t confuse it with being right or doing the right thing.   
  
2. Doing work without understanding “Why are we doing it & Why now?”
  - Being busy is not the desired outcome. We want to do the right things, so constantly ask why are we doing what we’re doing. Try to map it into:
    - Does it help us to scale? (do more with less)
    - Does it help us to increase margins?
    - Does it help us to win current Proof of Concept with customers?
    - Does it help us win the market in the long run?

  - Don’t assume that people who talk with confidence are necessarily right.  
Double-check your assumptions with multiple people.  
  - If requirements are clear, please invest time in creating a thorough plan for the project, including potential obstacles and how to overcome them. We too often run into writing code only to realize that we could have saved a lot of time by doing early research around the requirements and our definition of “done”.  
  

3. Not building momentum to deliver value 
  - I expect engineers to push hard to get code into production. Code that doesn’t reach production and provide value to our customers is waste.
  - Make sure you get everything you need in order to execute: help with figuring out requirements, design, and getting it all the way to production. Set time in advance with people (calendar), ask for clarifications and decisions etc.
  - Don’t expect others to do this work for you. You should be the driver.  
  

4. Not investing time to improve your communication skills.  

  - Why: makes it difficult for us to scale the team. We cannot allow it in our size.
  - Align others around the solution, and reach either agreement or escalate as needed for “disagree & commit”.  
  - I always want push \> pull of information.
    - Red flag: “what’s going on with X?” -- that means you should have communicated it clearly before.  

5. I have very little patience for “it will be done when it will be done” - I cannot work without some estimation of work and guesstimate for a deadline. I will not hold missing deadlines against you, and I will help you improve your cost estimation, but I do expect to see improvement over time.

# 

# How do I do my job?

I do not want to micromanage anyone - it's not a wise use of my time or yours. 

Your success is ultimately my success. I am always busy with meetings most of the time. If you need to chat - check my public calendar - no need to ask. If you can't find time, just let me know - I will make time because your concerns are important. 

In short, the following 4 points sum up a large part of my management approach:

1. Our relationship is an alliance. Transparency first.
2. Balance independence and coaching.
3. Improvement is a priority.
4. Feedback is Critical - for everyone.  
  

# How do I expect you to do your job?

- I am here to provide you with guidance and mentorship. When you need help, I expect you to not hesitate and ask for it.
- **If you feel you made a mistake, just say it. ** I value this the most.
- Under Promise AND Over Deliver. Leave yourself room for error.   
"I think the answer is this, but I'm only 25% sure."  
- When asking for help, propose a solution and share what you’ve already tried.  
- Anticipate. failing to prepare is preparing to fail. But don't get into analysis paralysis. Document your decision making process so future-you knows what information past-you used for making the decision.

# 

## Providing feedback

Feedback is at the core of building trust and respect in a team. We need to regularly hold each other accountable - if you see things that don’t make sense, call it out.   
Be kind, be constructive, but never hold back.  
  
Disagreement is a form of feedback, and learning to disagree effectively helps us grow faster. Ideas don’t get better with agreement alone; challenge drives progress.

## Career Development

“No one hands you personal growth here, but it's there for the taking. It's being able to try hard things; that you might not succeed at every time. It's seeing the practices of the talented people around you; practices that you're free to steal. Or it's the advice that others will give to you; advice that you didn't always ask for but is usually a good idea to take.”  
  - Steven Noble

Your career is yours. You know best how you’d like to grow and in what areas. I can provide feedback and an outside perspective.

I’ll do my best to provide growth and learning opportunities, it’ll be up to you to seize them. Let’s work together on this.

# Personality quirks

- I am a huge fan of Generative AI (GenAI) for code generation and productivity, both at work and in my personal life. You'll often hear me ask questions like, 'What does ChatGPT say?' or 'How did you leverage AI to accomplish this task?'. To me, using AI is like working in 'god mode'. In today's world, coding without heavily utilizing AI doesn't make sense. I encourage you to embrace it to its fullest potential.  
- I love to brainstorm and often ask for feedback on ideas on my “drawing board”. I may forget to explain this, so always assume I’m brainstorming with you. 

- I expect leaders in organizations to create the reality they want to see - tell me what you intend to do instead of waiting for me to propose a solution or shape reality for you. If you’re stuck, tell me and I’ll help. You’re the driver.  

- I am a big believer in “[no broken windows](https://en.wikipedia.org/wiki/Broken_windows_theory)” when building products: I like clean logs, clean exceptions. Once things go south here it’s very hard to truly understand the health of the system. 
- I tend to repeat myself—it can be a bit annoying, I admit. I want to make sure you can apply my feedback, so I’ll often try a few ways to bring constructive feedback to the table. I will also share context I believe you need in multiple forums (1:1, group, etc.). I will always tell you what I think. The upside is that I’m usually clear :)
- Names are important to me: variable names, class names, code names, project names, repository names, column names, field names, etc. If you come up with a name, show you've put some thought into it to make it self explanatory.