# Artyom's Manager Readme **Team Lead at AppsFlyer** # **Motivation for this document** As the hurricane of day-to-day tasks sucks the people in, there's not much time to pause and question the way that the team is going on. Working in this very team isn't new for me, allowing me to know the pains and try to 'heal' them. This team's daily work is unique. We use various technologies and make architecture decisions. You will be part of this very soon. Use your time here wisely to learn and then share what you learned with others. This team is AppsFlyer. You'll have a chance to affect the way this team works and performs directly. And if you think it's too much to learn - it's not. You will sort it out if you are truly willing to put some effort into this. And if you are not - probably you don't belong here. Some of the questions must be asked as early as possible, and expectations must be aligned. # **My role** The business is growing and transforms, it's already different now than it was a year ago, and it will make our system evolve into an even more complex product in the future. We must be agile, however, be careful and not create an uncontrolled monster. Keep things as simple as possible. On the other hand, there are business requirements that should be fulfilled. In order to do so, we ought to know the technology we choose and the business we're about to serve. First, my role is to provide you with the basic knowledge that will allow you to take ownership of the parts of the system and dive deeper. I will not teach you everything, simply because I don't know everything. Second, I will do my best to make your work as satisfying as possible and eliminate non-mandatory context-switches, knowing that a large portion of our work is under pressure.  We're measured by the quality of the product that we deliver. Quality means that features that we release must be ready for production. That means when the feature is released - it's tested for sanity, edge cases, passed through QA if needed. Getting back to the development of a feature that was already released is frustrating. We must have our internal tools that ease the process of debugging and testing our product. If you lack some of these tools, and it makes you spend much time on REPLing through your code - stop, define your needs, take it with other people, and I promise we'll try to find time and resources to create these tools. No-one likes dirty work, and while it's part of the deal - we're here to enjoy, so let's try and minimize it. # **What do I value most?** - Loyalty.  Each one should be loyal to the idea, and more important - to the team. It can be about working with a technology that was chosen, while not completely agreeing with the choice. We're here to share our knowledge and doubts. Speak up - someone will listen. But until things change - stick with what was chosen, and try to understand why the choice was done. Probably there is an explanation. - Curiosity. Whether it's about deepening your knowledge in a tech/business area of what you're working on or just noticing another open-source project/lib that may be helpful in the future - try to explore things. Ask questions. Do not assume anything. Google before you ask. And if you found what you were looking for - just read a bit more about how to use it, don't just copy and paste. Utilize API docs. Read readme's. Compare run times. Don't stick with what you already know. It will make your work easier, it will make you more experienced (= valuable) and it will make the team better. And who doesn't want to work in the best team? Production issue? Spend some time to understand what happened, how it was fixed and who was involved. We don't need just coders - we need problems solvers. It will benefit you eventually. - Willing to help. We built a SaaS system, which is live 24/7, with very high scale and very short failure tolerance. People have their lives, they aren't always available. But if you are - please help your mate, who is currently trying to fix a failing DB or a bottle-necked service. You will more than appreciate his help when you will be at his place. And you will. So please - help other. # **My Expectations** I've listed most of my expectations in 'What do I value most'.  Some more things worth to be mentioned: - **Be on time**. You're expected to be on time for 2 mandatory internal scrums that will be held each week in the morning. If you're sick - take a sick day. If you have something urgent to do outside of the office - tell me before. Don't just be late.  - **Slack**. Be responsive, especially to your manager/team members. Remember that not only you are working on something very important, and sometimes your quick answer will save someone a lot of time waiting or investigating. Be available for direct messages on slack as much as you can, during off-office hours. If someone approaches you directly - probably it's urgent enough. You don't have to react upon each message when you're at home, but checking your slack from time to time is a good habit. - **Email**. Read your emails periodically - jira requirements/comments and scheduled events usually get there. Don't call it a day if you have unhandled emails in your mailbox. - No-one will count your hours at the office as soon as the job is done. On the other hand - if you set an estimation for feature delivery - please stand behind it. Seeing people leaving at 3 pm (which is usually OK when they need it) while having a highly prioritized incomplete project that must have been finished  2 days ago - not nice. - **Know the basics** - internal build and deployment tools, basic docker commands etc. I do not want to hear questions like 'how do I revert to the previous build version with santa?' or  'how do I configure a load-balancer?'. If you lack info - Guru it. If there's no relevant Guru article - tell your manager. We'll have it created. - Broke production? Talk to you manager, or someone above him if he's unavailable, as soon as possible. Try to fix the issue (revert if doable - it's usually easier). Grab someone experienced to help you through the fix. It's hard to think clearly when you under stress.  Try to estimate the damage and provide this estimation to the relevant people. You must know key people in business/development. Don't blame yourself too much (unless you caused it by negligence) - you have more work to do. Evaluate your steps, schedule a lesson-learned so it won't repeat, and get over it. Bugs are part of the development process. Sometimes they are critical. The person who's writing this words is responsible for the longest partial downtime caused by a bug, that this company experienced since it started to care about downtimes, and still he got to managing you. It means something. # **1:1s** 1:1's will be held once per 2 weeks. Please be on time for them, take 10 mins prior to the meeting to write down things that you want to talk about. Raise concerns, provide management feedback, suggest changes - this is the quiet time where we can really address our needs.  Don't wait for your 1:1 if you have something urgent to discuss, just notify me and I'll find time for it. # **Personality quirks** I do not like micro-management. I do like tech, and I do like people that like tech, and not being managed. So be mature, responsible, try to make real time-estimations based on your skills and experience, and try to deliver on time. It's not always possible, but we need to improve constantly. I tend to be a freak control, taking too much on myself. If you see that you might be better for any of my tasks (and you might certainly be) and you think you're capable - don't hesitate to ask for more responsibility. I appreciate hard work, but not always able to praise one. Although I notice it and make notes to myself, it doesn't always appear outside. I am working on giving a better feedback. If you feel that you don't get enough of it (positive or negative as one) - use the 1:1 to tell me. # **Where to focus on your first 90 days?** - Become familiar with the environment - build/deployment systems, GIT commands, AWS, naming conventions. If you need help - ask your buddy or me to help you. If you feel that this knowledge isn't documented properly - talk to me, we'll improve the situation so a next team member will have a smoother landing. - Know event types that flow through the system. Where they're stored. Where they are processed. What's their business values, etc. - Get to knowing the system chart. It's somewhat complicated, but you'll understand it eventually.  - Most important - your fresh point of view is very valuable for spotting areas that should be improved - e.g. false alerts that people use to ignore, tech decisions that make little sense, and so on... Raise the flag immediately.