# Oren Ellenbogen's Manager Readme **SVP Engineering at Forter** # 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. # Disclaimer  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 a 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](http://venturehacks.com/articles/1-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 a 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. 2. 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](https://www.useronboard.com/features-vs-benefits/)): ![](https://lh4.googleusercontent.com/-HJ0KLZDj91QpisimyRVc_btd8itqBGaFeJ5eLzO3RSohtHYaLaxJYNQncDi485bYq5AIeRSphFUCqa2SqbHlwyN08PVlf_D-do9iSTPp-u457iR_qH2_MeRDycBHj5xlMjYJT3s) **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. 3. 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 optimized 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](https://www.youtube.com/watch?v=b8AD_LmERow&feature=youtu.be&t=9m18s) (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 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 the 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. 3. 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: ![](https://lh3.googleusercontent.com/sdA6HLqgdwoK3HHBNk-UpC0iZ9-D_OPFvcNaCekH4V2jLvYIyI0IGZd_GxbQl8nmLasM3yn6m6vTXySAG3SkaXe0yjMAgpIgwVSk7n-0apYgchaRpogHUBcjKXnVvC0TqCNgPJA8) 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. 2. 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. # Where to focus on your first 90 days? Your first 90 days should not be around how quick or productive you are. You'll have enough time to do amazing things, push out big efforts and help move the needle.  Instead, you need to create a solid ground to stand on first. These are my explicit expectations from new engineers on the team: - Make sure you know how to run & debug the system locally - without it, your ability to truly understand the system and follow a certain flow is weak. - Write stuff down - Heard a new term in the Daily, or maybe something during a Design Review or Architecture Topic? Write it down somewhere, and figure out more about it each day. Write your own dictionary, so you could slowly feel you're getting a good understanding of the system. It's easier to digest new things when you have to repeat it in your own voice. - Ask better questions over time - at first, people will expect for you to ask the simplest questions, as you're lacking context. With time, people would like to see that you've tried a few things before asking the question, that the quality of the question is getting better, and overall people feel that you're more independent. - 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. - Please read: [How to ask good questions](https://jvns.ca/blog/good-questions/) - Frustration awareness - make sure that nothing above brings you to a point where you're unhappy. Talk with your mentor if you feel that things aren't clear (e.g. maybe we should change the onboarding process?), or if you feel that you're left out of the discussion. Don't let it explode. People appreciate candid feedback and will do everything to assist. # 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 a 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](https://en.wikipedia.org/wiki/Broken_windows_theory)” 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 :) # 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 the 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 9 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's 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. # 1:1s 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”](https://speakerdeck.com/orenellenbogen/1-1-basics-for-the-introvert-engineering-manager) that covers my philosophy on it. # What's next? Read these docs. (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