# Robert Clark's Manager Readme **Senior Director of Engineering at Redwood Software** # Motivation for this document As I am often meeting more people for the first time, I've created this document to give everyone a head start on getting to know me and how I work to try and streamline the process. I'm also hoping that since we're all meeting remotely now, this document will give people a better sense of my management style than they could easily pick up in a video call or through email or instant messages. # What I work on I am a Senior Director Of Engineering with Redwood Software. I am primarily responsible for team coordination, resourcing (including hiring and planning), and managing the planning for major roadmap items. I also try and keep an eye out for any process improvements we need to tackle. I'm currently focussing on RunMyJobs's platform availability, resiliency, and extendability. # My role - I want to set the deliverables for you and your team, help you plan and schedule the work, let you know how much latitude you have, and then get out of your way while you figure out the best way to complete what you’ve committed to. - My main job is to remove barriers that are in your way, and make sure that you are aware of the larger picture. For example, other teams whose work may impact yours, or plans for the division or product. - The KPIs I'm interested in fall into two categories - Performance. For example: - How often does the team complete all they committed to in the sprint (with quality) - What percentage of issues are detected and fixed within the sprint versus ending up in the delivered product to be discovered by a customer. - Satisfaction. For example: - Employee turnover on the team - Engagement in the process. - 1:1 feedback - Ability for employees to advance their career and grow their skills # What do I value most? - If you can come to me with a problem _and_ tell me what you want to do about it, that's always preferred. If you don't know what to do, then I'm here to help you understand the problem and figure out a solution. - If you're a manager reporting to me, I want to see you as the champion and guardian for your team. I need to know that you're watching out for their interests when I cannot. - I want to add processes when they either streamline the work or prevent mistakes, and I want to remove processes that needlessly get in the way. - Automation for everything that is error prone when done manually, or which needs to be repeated often. This applies both to management and to code. - When planning work, I prefer delivering fewer high-quality items over completing and delivering more items with lower quality. When we finish a sprint, I want to know that the product is safe to ship. When we release a feature publicly, I want to know that all parts of it work well, and are easy to use. # What You Should Expect From Me - **Trust battery:**  I (try to) follow the [Trust Battery principle](https://sketchplanations.com/the-trust-battery "https://sketchplanations.com/the-trust-battery") (original New York Times [article](https://www.nytimes.com/2016/04/24/business/tobi-lutke-of-shopify-powering-a-team-with-a-trust-battery.html "https://www.nytimes.com/2016/04/24/business/tobi-lutke-of-shopify-powering-a-team-with-a-trust-battery.html")), so you can expect to start out with some level of trust with me, otherwise we would not be working together. This means, for example, that if you say that a feature you’re working on is not ready for customer’s then it’s not. - **No micromanagement:**  I avoid [micromanagement](https://en.wikipedia.org/wiki/Micromanagement "https://en.wikipedia.org/wiki/Micromanagement") as much as I can, but in some very rare cases I will need to pay closer attention. This could be for sensitive issues, issues I need to report on myself, issues that are not making enough progress, or if the Trust Battery becomes compromised. ## Personality quirks - I may send messages late at night, but that's to queue them up for tomorrow. I never expect a response after hours unless it's an emergency. - I prefer to make decisions as soon as the facts are in. My view is that it's better to move forward now and have to backtrack occasionally than to debate endlessly. - Uncertainly is my kryptonite. I also prefer working to remove uncertainly around technology, processes, and plans rather than trying to live with it. This is one of the reasons that I encourage Agile practices, and especially keeping stories small. There is always some progress that can be made, even if we don’t have the whole solution yet. - I love unwrapping presents. The first time we can take out a feature flag and make all the team's hard work public is like Christmas morning for me. - I sometimes fail to exercise enough patience. If I’m asking for something too often or want something done without allowing enough time, I urge people to speak up. I may not understand the scope of the request, or there may be external time pressures you’re not aware of. Either way, we need to discuss it and find a solution. # Getting in Touch ## How to Get In Touch With Me - I prefer instant messages (Slack or Teams for example) in _public channel if possible_, or a direct message if it's a private matter. Email is always a good alternative. I do not use a personal phone for work. Please use the ["No Hello"](https://nohello.net/ "https://nohello.net/") advice for starting an IM conversation. You don't need to say "Hello" and wait for me to respond, just post your question or comment immediately. - My calendar is always up to date. Set a meeting in it at any time without checking with me first, as long as the calendar shows I'm free. If you cannot find a good time, let me know and I will make time for you.  - For non-urgent items, I like to put them in as topic for the next 1:1 meeting (in whichever tool we're using to track this). You should feel free to add agenda items whenever you feel like it. ## When to Get In Touch With Me - After hours (I'm UTC-4) is after 6 pm until about 8 am the next day, weekends excluded. If it's not an emergency, I prefer that we both wait until tomorrow to talk. You're more than welcome to send me a message ahead of time (even after hours) so that it's there for tomorrow morning. - If you have or find a problem, I'd prefer you let me know about it as soon as possible, even if you don't yet know the fix. - If you need help or advice, you don't have to wait for the next 1:1 meeting, reach out at any time with any questions or concerns. We may end up discussing it later, but you should bring up anything you want to discuss as soon as possible. # 1:1s I prefer to schedule the following 1:1 meetings - Weekly with direct reports - Weekly with my own manager - Monthly for skip level meetings These meetings are always about what's on your mind first and foremost. Ideally you would be leading these meetings, and telling me your feedback about me, about the tools and processes, and about the team. This is also a great time to review goals and career progression and I like to review your goals once a month, and discuss your career 2 - 4 times a year. The guideline I prefer for 1:1 meetings is "[Effective 1:1s - Tips For One-on-One Meetings With Your Team](https://www.radicalcandor.com/effective-one-on-ones/)" from Radical Candor . # What to focus on your first 90 days? There are few concrete goals that I set for on-boarding, as each team and situation tends to be unique. I do ask that every person who goes through on-boarding try to improve and update the documents that are given, leaving them in better shape for the next person. There are some general goals I like to try and hit, however, and they fall into three general categories: "Know the Team", "Know the Product", and "Know the Process" I break this into 2 phases: the first 30 days are your introduction, and the in the first 90 days you’ll start become comfortable with these responsibilities. ## Managers - 30 days - _Know the team_: Have 1:1 meeting series set up for each of your direct reports, and have met with them at least twice each. - _Know the process_: Know all the team meetings and activities you need to be part of and make sure you're on the invite list. - _Know the product_: Have your own install or instance of the product and be able to intact with it the way an end-user would. - 90 days - _Know the team_: Complete goal setting and career planning discussions with each team member. Discuss with me any strengths or weaknesses you've observed in the team and and changes you are considering. - _Know the process_: Be able to lead/guide/facilitate any of the team meetings. Know how our product is build, tested, and delivered end to end. Know our policies for support and supporting old versions - _Know the product_: Be familiar with the major use cases of the product as a whole. Have reviewed all use cases for your specific area of responsibility. Have reviewed with me or the product owner the short/medium/long-term roadmap as it pertains to your area of responsibility. ## Individual Contributors - 30 Days - _Know the team_: met your direct manager at least twice. Met with me at least once for a 1:1 - _Know the process_: Be aware of all the team's regular meetings and have invites to them. Have your development environment set up and able to compile and unit test code from all major repositories. - _Know the product_: Have your own install or instance of the product and be able to intact with it the way an end-user would. Be able to check out and build a working majority of the code base you're responsible for. - 90 Days - _Know the team_: Met with (or at least identified) the subject matter experts that interact with your team most often. Understand the roles of everyone on your team. - _Know the process_: Be able to participate meaningfully in all sprint ceremonies. Be able to submit a code review, and participate in other's code reviews. - _Know the product_: Be able to fix smaller bugs and implement smaller features with guidance from your team. Have an understanding of the short/medium/long-term roadmap as it pertains to your area of responsibility from either me, your manager, or the product owner.