Manager README

Written by: Oren Ellenbogen, VP Engineering @ Forter. Maker of SoftwareLeadWeekly and Author of Leading Snowflakes. Last update: January, 2018.

Motivation behind 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.


This document applies only to me, and in no way should be considered to apply to any other team or manager at Forter. There, now let’s go.

My role

As the VP Engineering at Forter, 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 is getting better over time?” -- if the answer is “HELL YES” then we’re on the right path.
  • Setting clear context so people could 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 Forter, not for me nor for your direct manager. Optimize for Forter.

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

What do I value most?

  1. I’m a big believer in hiring people with one-wo(man) startups mindset. In our current size (~25-30 engineers), we do have people who are experts in some domains but we cannot operate without many generalist that can help us quickly(!) shift focus and constantly align with the business.

        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 new tech stack or new methodologies. I’ll try to tell you when I can, but hold me accountable.
  • Ask for relevant training (books, workshops etc.), I’ll always default to yes here.
  • If you prefer to focus in a few narrow fields and become an expert just say so. We will find the relevant opportunities together, and talk about the tradeoffs.
  • People can move between domains (e.g. Growth, Precision, Data Engineering, Product) as needed, and you'll see people moving between rooms as needed. We encourage people to seek for opportunities inside our organization to level up on different skills.
  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 are busy operating on the tasks level, without optimizing for the project (“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 hanged in your room, or even better - in your mind (and then read this):

What you should take from this:

  • Measure everything you deliver in terms of how the customer will benefit from it (internal or external). This is as important as writing tests and have proper monitoring/alerts.
  • Spend more time with Product, Marketing and Sales teams. They meet more customers than you. Take any opportunity with them over lunch, or before starting a new project. Try to understand how they would measure the impact on the customer. Ask them for metrics and understand why they chose them.
  • I believe that engineers should drive momentum, bringing your hard work to production so it could serve the customers. Reduce business/tech risk, chase down dependencies and push for decisions.
  1. Conflicts are crucial for our growth as an organization:
  • Without it we will spend most of our time optimizing for local maxima. People will be afraid to call BS when we need them to.
  • I love when Senior Engineers hold each other accountable. If you see things that don’t make sense, call it. It may be optimizing for the wrong thing (e.g. losing focus on the project), challenging the user experience or the proposed architecture. Be kind, be constructive, but never hold back.

        What you should take from this:

  • In every situation, ask yourself “what is my role here? Owner? Consultant? Preacher?” -- I covered it here (3 minutes, until 12:18).
  • Before you challenge anyone else, agree beforehand who is the owner that can decide (most of the time it’s obvious), and who you can escalate to if there is a need (e.g. it may have an impact on the organization).
  • “Disagree & Commit” where needed.
  • Write your thoughts down first, share it with them, and then have a discussion. Reading, unlike face-2-face discussion, is an easier way to consume a different mindset and opinion. You don’t need to think about a clever reply, just focus on reading and thinking about deeper intent. Write more.

What will disappoint me?

I mean, I’m not your parents. You should now know what is “exceptional work” (i.e. you’ll be promoted) for me means, it’s only logical that you’ll know what will get you fired without drastic improvement:

  1. People who focus on their own personal brand at the expense of the company or team’s needs. Ego is important, self-confidence is important. Don’t confuse it with being right or doing the right thing.
  2. Doing work without understanding the “Why are we doing it & Why now?”
  • Being busy is not a 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. Check and check again your assumptions with multiple people.
  1. IQ over Time spikes
  • When requirements are clear: I prefer that you’ll have a good attempt at planning a complete project. My rule of thumb is: feature < 2-3d, with tasks in it where each task < 2h. Only then, start writing code. We too often run into writing code just to understand that we could have saved a lot of time by doing early research around the requirements and our definition for “done”.

    Below are the graphs I always use to demonstrate this:

  1. Not building momentum to deliver value (setting the tone)
  • I expect engineers to push hard in order to take 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.
  1. Not investing time to improve your communication skills.
  • Why: makes it hard for us to scale the team. We cannot allow it in our size.
  • Feature Owner should “trim down” conversation and strive for clear decisions. It’s not a democracy. Owners decide, consultants can provide options & tradeoffs.
  • 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.

Personal quirks

  • I argue with “passion” - I may raise my voice a little or get a bit red. I don’t like it about myself, and I try to improve. I tell myself that “I’m all-in, all the time” but it’s just me losing my temper. When you feel I crossed the line, tell me. It’s not my intent.
  • I have very little patience to indifference - I’ll call it out. I know that I might be mistaken, e.g. you didn’t sleep for a week due to some personal issue at home, so do tell me if there is a reason behind it.
  • I tend to repeat myself - It can be annoying (I guess). 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, DR, all hands etc.). I will always tell you what I think. The upside is that I’m usually clear :)
  • When you ask “do you have 5 minutes?” in Slack or email, please add the topic you’d like to discuss, otherwise I’ll think “do you have 5 minutes for me to tell you I’m thinking of quitting.” -- we’re biased for bad news and I’m not different.
  • From leaders in the org (e.g. Senior IC, Managers) I expect to create the reality they’d like to see - tell me what you plan to do, instead of waiting for me to offer a way or shape reality for you. If you’re stuck, tell me and I’ll help. You’re the driver.
  • There are very few things that make me happier than to see a heated debate, as long as later on that day or that week people still enjoy their time together. I will acknowledge it often out loud at the end of such session: “That was a very much needed discussion. Thank you for going all-in, offering your point of view and different tradeoffs, now it’s up to [owner] to make a decision that we will all support.”
  • 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 deadline. Applying “Design to Cost” reduces a lot of risk from the business. I will never hold missing deadlines against you, and I will help with it as much as you need. I do expect to see improvement over time, but never perfection.
  • I am a big believer in “no broken windows” when building products: I like clean logs, clean exceptions, clean PagerDuty. Once things go south here it’s very hard to truly understand the health of the system. People want to be able to deploy, test and monitor their code without having to remember “legitimate”/sporadic failures.
  • I write a lot, and I’ll expect you to write more than you’re used to. It is web scale :)

Expectations 101

How to set time with me

My calendar is open - This is by design. You can see who I meet, about what (agenda) and for how long. This allows you to capture time with me as needed. When needed, I will capture time I need for myself and call it “DO NOT DISTURB”.

If you need me - simply ask in Slack (if not urgent for the next few hours) or face-to-face (if urgent for now). I’m pretty good with a lot of context switches. This is my job. Please don’t assume I’m too busy.

Work hours

We work for 9.5 to 10 hours a day. Some people start early (7AM) some later (9:45AM), and go home accordingly.

You can work from home when you need quiet time (don’t abuse it), just write WFH in our #rnd room in Slack and keep the “daily format” of what you plan to achieve for when. We all have laptops, so you can work when needed (e.g. waiting for the cable guy to show up, or for a doctor appointment).

I will track every incident or urgent request to work outside of regular work hours and apply a “Better Next” to understand which kind of tools we need to reduce that.

Availability via Slack, email, whatsapp and phone calls

  • Email: People expect you to read and reply to emails at least once a day.
  • Slack: direct mention is usually expected to be replied within a few hours, everything else is according to your availability.
  • Whatsapp (personal): usually expected to be replied within 30 minutes. Useful to use when you want to call someone out of work hours but you’re unsure if they’re awake.
  • Phone call: urgent, expected to be answered or replied (if you cannot talk) ASAP.

You control your time


Make sure you lift your head up from the day-to-day craziness and look a week forward to what you should do next.

Reminder: you should own your time, not me. If you need help with it, let me know and we’ll work together on time management practices.

I want to know you are working on the right things (validate alignment between us). This is a simple way for me to read a high-level view of your plan and make sure there are no big conflicts with other priorities.


  • See below - Sending “Weekly planning” email.

Every 3 weeks:

  • Go over the quarterly presentation (under Plans 20xx in Google Drive) and see that it still makes sense. We might want to change things there.
  • Figure out who’s working with you on what. Talk with them, to make sure they’ll be ready. We usually prefer people to work at least in pairs, to increase likelihood of completion on time + knowledge sharing +better quality.

Before every quarter:

  • Figuring out which features are important, i.e. why are we doing any of it? Why now?
  • Which ones you’d like to be part of or lead, i.e. how would it fit your goals (often based on Performance Review plans)

Send me a weekly plan

Preparing for it

Set time in your calendar:

  • Weekly 30 minutes session. That should suffice.
  • Put it somewhere you'd feel won't take you out of context: Maybe first thing in the morning? After launch?

Writing an email will require you to:

  • Go over your tasks in Asana (team’s board & your own tasks) and make sure everything is well organized for you.
  • Mark things that were completed.
  • Set a due date on things you have a due date in mind.
  • Think about other things that bother you on the day-to-day and see if we want to handle them now. If so, add them to the relevant team’s board.

A template you can use

Last week:

  • Managed to complete X ...
  • Managed to complete Y ...

This week:

  • Feature X - plan to complete it by Y
  • Feature Z - plan to come up with design and time estimation by T

Lessons learned (if you had any, below are just ideas):

  • Is there something that surprised you? (took more/less than you thought)
  • Do you need some more context to make better decisions?
  • Do we have some pains in our infra that hold you back?
  • Did you set time for big/risky code-reviews with others, or to help with the design of a system/problem you're working on?
  • Reminder: usually due to the async nature of our PR and design process, it takes us more time (calendar time) to get something out.


Bi-weekly, 30-45 minutes every time. It’s your time, so please come prepared.

There is a talk I gave about it called “1:1 basics for the introvert Engineering Manager” that covers my philosophy on it.

Read these documents

(Note: internal google docs/slides at Forter)

  • Onboarding For New Engineers
  • Alerts & operations: on-call rotation
  • Test design principles
  • Handling Production Crisis: How to communicate effectively during a shitstorm