# Oren Raboy's Manager Readme

**VP Engineering at Totango**

# Motivation for this document

I wrote this document to help explain how I think and operate, so that those people working with  me can get the best results from our relationship. It may be useful for others, but it is mostly intended for people that work in my organization (report to me).   

If you know me, you know I strongly believe in the process of continuous improvement. In this spirit, I view this text as being in a perpetual Work In Progress state and would personally highly value comments to help me (re)think and improve any part of it.

Even more so, if as part of our work together, you feel I fail to deliver on parts of this, please hold me accountable and let me know - I’m not perfect and part of this text is to help me recognize where I can do better to align my actions and intents

# My role

I am the VP Engineering at Totango, and GM of Totango Labs (our site in Israel). My chief responsibilities are:

- To build a best-in-class product, that can deliver any technology our business needs to grow and scale in the market  
  
- Create a world class product development organization, with high levels of software engineering craftsmanship. Producing consistently high quality product releases on a predictable schedule  
  
- Create a modern r&d culture with a “can do” attitude. An environment where team members can contribute, collaborate, learn and grow. My role also includes mentoring and helping every team member develop and align their personal development goals with our company needs  
  
- Make sure we are properly staffed, trained and have the tools we need to succeed   
  
- Set context for everyone on the team and make sure our organization at Totango Labs is well coordinated with the rest of the Totango functions and highly aligned with the needs of our customer base (which we love very much!)

# What do I value most?

I believe that when we **understand context** , we always do better work. I also believe it’s the responsibility of each of us to seek to understand the context of what we are doing. So:

- Work to get answers to questions like: Who is the customer? What are we trying to achieve?
- When working on a task or project, make sure you understand its [definition of done](https://www.youtube.com/watch?v=pYOJyQoBT3U)
- Be curious, spend time with the Product Owners, spend time with customers and our front-office teams. Don’t take things for granted.

I value people that **take ownership** on work. Own the problem, the solution, the process and result of what you are working on. I also highly value people that take ownership of their craftsmanship as a software engineer and hold themselves and their teammates to **high standards** of coding, testing, documentation and design.

I value **cool-headed and reasonable colleagues**. It’s OK to get passionate, excited and hold people accountable. It’s not cool to be aggressive, unpleasant, demeaning or condescending. That’s not a good way to create positive change and is very counterproductive. **Don’t be an asshole**.  

I am a big believer in **writing things down**. Be it a design document, a summary of a meeting , a description of a new idea, or a blog post. Writing things down makes it specific and approachable. It helps clarify context for others. It’s time well spent.  

I am a big fan of **lean development**  **principles** , which i would summarize in: working in small batches, validating assumptions and iterations.   

I believe in taking **managed risks**. I believe in making big, bold and risky engineering decisions. We’re a startup, it’s our calling… At the same time, taking a risk means you have to double down and have a great plan to mitigate risks along the way. Otherwise, we’re just being reckless. **Be bold, and always have a plan.**

When it comes to optimizing our work, I would like you to optimize for the **customer first, product second, project third and then task**. Some people optimize for the task level and not the project level (“it will be finished when it will be finished”), Some will optimize for the delivery of the project without considering the long-term impact on the product. The hardest is considering what the customer needs and optimizing for their benefit. This sounds intuitive and obvious but in practice it’s hard.  

# What will disappoint me?

- Working outside of the  plan
  - Not being clear on why are we doing something, or where we are headed
  - Being unable to “disagree and commit”. Even if you disagree with a decision, you need to be able to understand it and commit to it

- Developing without focus
  - Starting to work without a clear implementation path. ‘It will be done when we finish’ is not a plan.
  - Being misaligned with priorities
  - Not understanding the definition of done
  - Not pushing to get your code to production

- Not engaging with our team or process
  - Being unprepared for standups or meetings
  - Not responding to team members in a timely manner
  - “It’s not my job”
  - Focusing on your own work rather than the team or company  
  

- Not being passionate about our customers
  - Being complacent about a customer issue (support tickets)
  - Not being available for production incidents (especially if it’s your rotation!)  
  

- Not being proactive about issues
  - Knowing of a problem and ignoring it
  - “It’s always been like that”   
  

- Not spending time to clearly communicate
  - Not writing things down
  - Not reading what others have written
  - Not taking the time (or make the effort) to be concise and clear
  - Being dismissive or rude

- Not making decisions
  - It’s generally not someone else’s job to “make the decision”. You own something, you decide. We are better off in an organization where everyone makes decisions (sometimes wrong) vs one where everyone waits for someone else to decide.
  - Just make sure you clearly communicate … Then it becomes other people’s  job to pay attention and overrule your decision if they need to

# How I work: my personal habits and quirks 

- I don’t pay much attention to organizational hierarchy - I expect to be able to work directly with everyone on my team (not just my direct reports) without going through “the right channel”. I expect that from everyone on the team. Work with anyone you need to get results.   
  
- I argue with passion. I sometimes can sound angry or raise my voice. It’s just my excitement and something I try to control.

- I tend to talk a lot and can occasionally [go off on a tangent](https://dictionary.cambridge.org/us/dictionary/english/go-off-on-a-tangent). It runs in my family. If I go too far and am slowing you down, Tell me, I’ll stop. The good thing is, you’ll always know my opinion…   
  
- I lose patience when people are unprepared or disengaged. I understand this can happen sometimes (didn’t have time, distracted at home, ), so let me know, especially if i can help in any way.  
  
- I love casual work related corridor conversations. I do a lot of brainstorming in the kitchen. Suggesting a coffee break  is a great way to get my attention (-:
- Part of my job is to help you. Feel free to drop my office or ping me on slack / email at all time. If I’m distracted or unavailable, i’ll get back to you. If you want to have a 1:1 conversation, you are most welcome to schedule one for us.

# For managers on the team

- I expect you to know what’s going on with your team at all times. I don’t mean this in the ‘micromanaging’ way (you should go as deep or high-level as you think is right), but always have a good idea of the following for each of your team members:
- 
  - What they are working on, how is it going, and what’s coming next
  - Main challenges and friction points  
  - Energy levels and morale   (individually and as a whole)

- I expect you to understand the key drivers of our business and mindfully think how your team fits into it. Have a clear picture in mind for:
  - What are the main company objectives for Totango  (reaching a sales target, product milestone, strategic initiative, closing a financing round).
  - How your team’s work is contributing to that
  - What can your team do more/better/different to help us reach our goals.

- I expect you to set an example for your team in ownership, craftsmanship, teamwork and communication  
- I expect you to be mature, be able to take and give criticism, be able to mentor and grow your team

- I expect you to make decisions and “shape reality”. I’m here to help you, but i expect you not only raise issues but also have an action plan to tackle them

# Work expectations

**Coding:**

- Work in small batches. Large batches increase complexity and slow development down. General rule of thumb: if you’re commit is larger than 2 days of work, or if your task is more than 2 days long, your batch is likely too large.  

- Get things to production early and often. Code that doesn’t make it to production is waste. Early code in production (with the right feature flags of course), reduces risk, and improves exposure and feedback.

- Invest in commit messages. Keep logs and code clean and clear (the [broken window principle](https://en.wikipedia.org/wiki/Broken_windows_theory)). Work in small batches and there will always be time for it.     
Your teammates (and future self) will thank you

**Office Etiquette :**

- The office is normally busy from 9am - 7pm. We have flexible working hours. You can work outside these hours or remotely if you wish or need to. Keep in mind it’s still your responsibility to get work done (including that which depends on others). Make sure you close the loop with your manager and team. Please also update #[team-il](https://totango.slack.com/messages/C09FLJF1S) when you’re not available and what you plan to work on. Here’s a good example:

> _WFH today. Available on all channels except between 11am - 2pm. Working on dectet-1234 and plan to get it to production today._

- We run a production system, and we may need YOU to help with production incidents, including in the middle of the night. Please make sure you’re aware of your rotations and are attentive. When you are called for at night, know that: (a) it’s very much appreciated (b) I understand it should be the exception, not the norm (c) if you need time to recuperate from a long night production issue, take it (don’t come to work without sleep). Just let people know.  

- We’re a fast paced environment - expect to get asked questions and interrupted by people that need your help. If you’re busy and need time, ask to talk about it later.    
  
- Respect people's need for quite (keep it down)... Understand we’re not a library (be tolerant to noise). Use headphones. Music in a room by consensus of all residents.

- You’re responsible for your equipment and your junk (even if it was purchased by Totango). Keep your area clean. If you need to dispose of stuff, let Karin know.

**Communication**

- Meetings are NOT a waste of time if they have a good agenda and takeaways. Please come on time, be engaged (no laptops) and focused on the meeting’s goal.

- We have a lot of collaboration  tools: Zoom, Slack & Email, Git, Jira . Use them. The general rule are below. Please follow them:
  - When you get an email, expectations are you read/answer within a day
  - When you get slacked (DM, mentioned), expectations are you read/answer within a few hours hours.
  - If you need someone urgently, call them or go talk to them in person

**Gear, Learning resources and other such**

- If you need gear (monitor, mouse, etc.), resources (books) or software - ask. The default is yes to anything that will keep you productive (within reason of course)

- Totango is happy to purchase  online courses (Coursera, Treehouse, LinkedIn) for professional learning you want or need. Only ask is that you post a Slack summary in #[eng](https://totango.slack.com/messages/C082Y830R) if you recommend it for others:

> Just completed the course on [fast.ai](https://fast.ai) for practical deep learning. Highly recommend it. Very hands-on and practical way to understand tensorflow and how to build basic classifiers. Overall time investment: ~10hours. Need some python experience.

🍶Kampai

/Oren