# Ido Guterman's Manager Readme **Team Lead at Taboola** # Motivation for this document I wrote this document to share my expectations on what would make it most effective to work together.  I think I reached a point where I believe writing is more scalable and sustainable than speaking, and that we should do it more. I hope you might want to use some of those guidelines. I appreciate also diversity, so you don't need to connect to everything. I've written a lot here about my philosophies but a fair amount of my job is adapting to your needs and philosophies. Use this document as an intro to my mind and how I like to operate. I believe that these topics would help you become more efficient and reduce managerial overhead on my side. This is a living document which may change during the time. I didn't invent any of those lines - I believe I take something from everyone I interact with - whether It's the philosophy I should adopt or one I shouldn't.  A lot of what's written here has been written before by [other](https://managerreadme.com/community) manager readmes, and some by various colleagues through the years. Other Materials I read or listen to can be found in the onboarding document at the end. # My role As an Engineering Team lead, my role is : - General: - Responsible for team’s deliveries and timelines. - Communicate what’s important to the relevant stakeholders when it’s required the time. - Make sure we are working on the important tasks for the business, product, customers, and R&D. - Push forward the business, and product. - Recruit talent. - Fix broken processes. - For you: - Solve problems ( any problem ) that you have. - Listen. - Teach. - Give feedback - [https://www.youtube.com/watch?v=J2jofjLSepU](https://www.youtube.com/watch?v=J2jofjLSepU) - Challenge. - Help you make an impact on the business, product, and R&D. - Remove blockers / obstacles to empower you to accomplish what you need to do. - Set the context to understand the ‘why’ you are working on specific tasks. - Being flexible or strict when required. # What do I value most? Know the business - Understanding the business, customer needs and the ad-tech ecosystem can give the foundation for R&D and Product innovation. - Ask for business context if you don’t know it. - Read blogs, newsletters, and follow industry leaders. - It’s better that you will suggest “bad ideas” rather than not suggest ideas at all. I believe that at some point, you will understand how to find “good ideas”. **Product approach** [We’re here to make our customers great](https://www.useronboard.com/features-vs-benefits/) ![](https://lh5.googleusercontent.com/gHH9LRhUDs4H7Vmz6r2dmcSNS-CYWyf5HI_N_6vH10KUl7ng6Ej1trUozN7X2QUz7NmVzsGsJh_RQn9WFD5P-aE4w2Ipb6ZiKqopXvYwyZun28JAb99ZRqhYmNYLIMVcON1wlN_2) - Start planning a feature from reporting - 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. - It’s important to get feedback from the “field” - Product, Account Management and Sales teams meet more customers than you.  Try to understand how they would measure the impact on the customer. Ask them for metrics and understand why they chose them. - MVPs are important to get feedback quickly, once MVP is live -  iterate quickly in order to reach product market fit - Nobody wants well-engineered features which are not being used. **Development philosophy** - I appreciate[fail fast](https://dzone.com/articles/fail-fast-principle-in-software-development)approach when it’s possible.. It doesn’t mean that quality should be neglected - it just depends on which point on the dev cycle, and what is the feature, and the feature scope.  - If I would have to choose between great monitoring (using CI/CD) vs great Unit Testing (using CI/CD) , I will choose great monitoring because there are some behaviors in production that unit tests can’t cover. **Estimations & Planning** - I think software engineers are not prophets when referring to time lines , but I can’t also work without some estimation of work and guesstimate for a deadline. Applying [“Design to Cost”](https://en.wikipedia.org/wiki/Design-to-cost) reduces a lot of risk from the business. When giving an estimation try to give DEV ETA and time-to-market ETA. - I like to give a few days for estimation for large projects - I will let you start to work in order to “feel” the mission , break it down to submission and give proper ETA. However, sometimes forget to ask for a proper design review - it’s your responsibility to write one and present it. 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”.  - For features which are estimated for longer than 5 days, you should break it to small subtasks so it will be easier to track their progress. **Documentation** - If someone asks you a question, and you think another person might ask the same question in the near future - it's better to document it rather than to respond on a chat. **Conflicts** - Conflict is a good thing which you shouldn't be afraid of. A diversity of opinions make us more certain about our opinion or help us find a better solution. - “Disagree & Commit” where needed. - Sometimes it’s better to build buy-ins in 1-on-1 conversations, before jumping to emails.  **Leadership** - We lead by example. - Leadership comes from everywhere - [Leadership Guide for the Reluctant Leader - David Neal](https://www.youtube.com/watch?v=0h5X5UKWao8&list=WL&index=32) **Ownership** - Be involved in the mission from the planning phase, ask for business context, share your technical design, goals, monitoring tools and think in advance how you will test your feature. - In some cases, in order to deliver your mission, I believe it's your job to be also QA, Analyst or Product Manager. Different people might have different priorities - you might also be able to learn something new, and get a different perspective on the way. When doing such a thing, It's important along the way to communicate with the relevant person what you are going to do and what you do. - Mistakes will happen. If you don't make a mistake it probably means you don’t do enough. You should consider them as learning opportunities. However, try not to make the same mistake twice. - I appreciate your participation in “money time” moments - when service is down and you’re the one noticed it or fixed it. - If something is delayed or goes wrong - raise a flag. - When you hand off the mission to someone else - you are making sure he understood what you did, and the business context. **Integrity** - Integrity means we are consistently open, honest, ethical and genuine.  - I start with an assumption of positive intent for all involved. **Communication** | - “Communicate fearlessly to build trust.” - "I'd rather have a hole in my organization than an asshole." ( [YouTube](https://www.youtube.com/watch?v=fJOSX-W0yHA&feature=youtu.be&t=10m53s), [Post](http://www.brendangregg.com/blog/2017-11-13/brilliant-jerks.html) )  - It's an art to communicate a clear message in a few sentences as possible - in two words, be concise!  - You think strategically, and can articulate what you are, and are not, trying to do. **Productivity** - I value mastery in developing tools - In the army I worked for 6 weeks without a mouse just to improve my keyboard and typing skills and be more familiar with IDE and OS shortcuts. - I think each developer should be familiar with one scripting language to create himself automation tools and save some time. - Try to think which automation you can do that will save your time ( build / ci-cd tools / debugging tools and others ). One saving one minute for you a day might save days in group time per month. - At most times, prefer that you will work 9 hours a day ( or in your free time), and in the rest of the time improve your tech skills and soft skills, rather than not invest in improving at all. If you need recommendations, time or budget for learning - let me know! | | | # My Expectations - From leaders in my team 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. - Craft / Tech: - You should find the balance between “well engineered” and “high standards” and “quick and dirty” solution according to the priorities. - When coding, you look one function below and above the code you are writing and check if something is broken.  - You leave the code better than it was before you've changed it - if a small refactor is required - go ahead ( just let another team member know, preferably the one who previously touched it). If a major refactor is required - let me know, and add it to the technical backlog. - You have a deep understanding of the team’s specific technical and business domain. - You are familiar with the common [design patterns](https://en.wikipedia.org/wiki/Software_design_pattern). - Impact - Your impact on the organization is getting bigger: - Tech & Architecture 1. You suggest performance improvements and architecture changes. 2. You identify technical debt, and suggest solutions to tackle it. - Product & Business 1. You suggest features and find and fix bugs which affect positively on the business and product. 2. You are the go-2-guy when a crisis happens. 3. You own missions end-to-end ( see “Ownership” section ) - People & Mentoring 1. You mentor and empower other team members. 2. You help other people in the team or group to achieve their goals. 3. You share your knowledge ( internal lectures, blogs, meetups, 1-on-1 feedback ) - Processes 1. You find processes which are broken and suggest ways to fix them. If you are at the beginning of your career, try to focus the following first ( if you are not at the beginning of the career - I expect you to do that as well ): - You have a positive attitude and you are eager to learn. - You are learning from your mistakes and responding well to feedback. - You ask for feedback ( from me and your peers ) - You ask questions if you don’t understand something. - You find the right balance between asking for guidance and dealing with problems on your own - even if you will be slower. - Once you get a basic understanding of the product and the business - It’s better that you will first focus on how to be a better developer. - You can use office perks, but I recommend that you will focus on work, and what matters and not on the perks around, especially on the first 90 days - You are measured by being able to deliver features on time.  **General ** - I can’t solve problems which I’m not aware of - so I do expect to let me know if you have something on your chest. - If I’m asking you “what’s going on with X?” - that probably means you should have communicated it clearly before.  - When you get a Pagerduty, I expect you to respond. - I prefer that when you are “stuck” on a mission and waiting for someone else, you will think several times what else you can do to push the current mission rather than starting a new one. - You should have number 1 priority and number 2 priority as a fallback. If you don’t know what they are, have too many or too less - let me know! **Further Reading** - Materials for Senior engineers : [Podcast ( Hebrew )](http://notarbut.co/ep47_seniors/) , [relevant blog](https://engineering.wework.com/so-you-are-a-senior-engineer-now-what-35ee2116f635) , [another one](https://www.tombartel.me/blog/exhibit-leadership-as-individual-contributor/). - Materials for Junior engineers :  [this podcast](http://notarbut.co/ep34_dreyfus/) ( you can skip the first 10 minutes ) , [Seven Tips For A Junior Developer](http://www.pearlleff.com/seven-tips-for-a-junior-developer) , [10 Principles for Growth](https://medium.com/@daniel.heller/ten-principles-for-growth-69015e08c35b) **What you shouldn’t do ?** **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 a 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. **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 our revenue? - Does it help us to win a current Proof of Concept with customers? - Does it help us win the market in the long run? # 1:1s - It’s your time - if you come prepared we can achieve much more. - I try to do 1-on-1 every week for 30 minutes. - The first few minutes will be used to record what did you spend time on last week in order to track the team progress towards the goals we’ve set at the beginning of the quarter, and me being able to raise flags and shift resources as soon as I can if I see a problem. It’s better that you will remember/write down what the things you did in the past week in a half day granularity if you don’t have a good memory. It’s also a good opportunity for you to ask for high level feedback on the results you’ve produced, what challenges did you have, what did you do well, what could you\the team\me do better. After that you can take the lead. - If you are not sure where you stand, 1-on-1 is a good place to ask for feedback. - Some Ideas what other issues can be raised - [101 questions to ask in 1-on-1](https://jasonevanish.com/2014/05/29/101-questions-to-ask-in-1-on-1s/) , [how 1-on-1s should be conducted](https://speakerdeck.com/player/e6a62a89e5af4bf681832d1612162001?title=false&skipResize=true) , [this podcast](http://notarbut.co/ep58_1x1/) (Hebrew) , [awkward 1-on-1s](https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c) , and [other resources](https://github.com/LappleApple/awesome-leading-and-managing/blob/master/One-on-Ones.md). # Personality quirks 1. I sometimes argue with “passion” - I may raise my voice a little - don’t take it personally. 2. I have a tendency to cut to the chase without the small talk before. So don’t be offended because of that. On the other hand - saying hi and then what you need is enough for me . 3. If I see behaviour which I don’t like, I will usually prefer to wait, think about it, consider if it’s a repeated pattern and give the feedback in a weekly meeting rather than giving instant feedback on the spot. 4. If I don’t ask you about your life, it’s not because I don’t care - It’s probably because I don’t want to be too intrusive. I will be happy to hear about it if you want to share. 5. I have a hard time to give and accept compliments because I think there is always room for improvement. 6. I think I should aim to know the product and the industry at least at the same level as the product manager. 7. I hate to answer the same question twice - it means me or you should have written proper documentation somewhere. It’s ok to ask the same question twice when I first explained to you my answer. # Where to focus on your first 90 days? 1. I like to throw people quickly to the deep water - try to swim. 2. Ask better questions over time - at first, people will expect 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. 1. 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. 2. Please read: [How to ask good questions](https://jvns.ca/blog/good-questions/) 3. Frustration awareness - make sure that nothing above brings you to a point where you're unhappy. Talk with your “onboarding buddy” if you feel that things aren't clear. If you see something that you think could have been done better ( onboarding, process, code quality) -  write it down, and we can discuss it on our 1-on-1s. Good luck!