# Caleb Huitt's Manager Readme **Development Lead at Ag Leader Technology** # What's all this then? This is a manager README, which is, well, a shortcut with helpful knowledge about the project, as it were.  In this case, the project is working with me.   Yes, it's a bit weird, but... if only all humans were well-documented, amirite?  We'll learn a lot more about each other as we work together.  This is a shortcut and organized overview to bootstrap the learning process somewhat. Like many most nearly every project, things change faster than the documentation gets updated.  So good news, not only is this document biased, but it's probably out of date even as you read it!  The proof is in the execution, as it were, and I understand I'm operating under the same conditions.  If my behavior and this document differ, you'll be doing me a huge favor by pointing it out, so I can reconcile them.  Feedback on the document itself -- things like organization and clarity -- are also greatly appreciated.  Not only will you be improving things for me, but also making things better for your future coworkers. # # My Job I'm almost certainly busy at a number of things, but my job boils down to three priorities: - Help people reporting to me be awesome at their jobs - Help them grow to be even more awesome - Find great people and get them in the right place in the company Anything else is priority 4 (or lower). ## Help People Reporting to Me Be Awesome That's you, I hope. In fact, in the rest of the document, instead of saying "people", I'm going to say "you".  It sounds better, and hopefully makes clear that these things apply to me and you, specifically. It's my belief that some of the best outcomes result in people given room to excel at what they're good at.  It's my job to help make that happen.  In fact, this is probably what I spend most of my work time on. I do that in two ways: - **Remove stumbling blocks and obstacles** This includes things like making sure you can have the equipment you need to do your job, as well as helping make sure our infrastructure is in place and occasionally even poking the code into a better, more maintainable shape. - **Finding and giving you information** I want to make sure you have the relevant information to make the best decisions you can as you're doing development.  Sometimes there will be a lot I think may be relevant.  See the communication section below. ## Help You Grow We'll talk, probably many times, over what your medium-term work goals are -- that is, in the next 6 months to two years.  Then I try to find ways to help you get there -- whether that's training, work experience, time to experiment, or something else. ## Find Great People Unfortunately, I can't always find the great people without getting out and looking for them, so some of my time will inevitably be taken away from working with you (and the rest of our teams) in order to find new great people.  This is important, because these are the people you may be working with in the future as well. Fortunately, our turnover in software engineering at Ag Leader is relatively low, so this isn't usually consuming a lot of my time.  Just be aware that the time required can intermittently spike. ## Get You In the Right Place At first, this will almost certainly be with other developers as you learn our systems and we both learn more about where you might fit.  If we discover you'd be an even better fit for another team or role at Ag Leader, we should talk about how to get you there. ## How You Can Help There are some ways I ask people reporting to me to help me accomplish my job.  These mostly involve awareness and communication, though that isn't all: - **Tell me what's keeping you from awesome.** I try to watch for opportunities to improve things, but if you notice something, let me know about it!  I may have you take the lead on resolving it, but many small annoyances can be fairly simple to resolve. - **Think about what you like, and how you'd like to grow.**  This helps me both find places to let you shine better, as well as chances to allow growth where you're looking for some. - **Ask questions.**  If you want information you don't have, ask someone.  If you don't know who to ask, I'm a good place to start.  Hopefully over time, this means I can anticipate and provide the information you'll be looking for. - **Give me feedback.**  See the feedback sections above and below, but I can't improve if nobody lets me know when I'm missing the mark. - **Recommend People.**  If you know great people who you think would like to work at Ag Leader, tell them about me and our openings. - **Interviewing.**  I don't interview people just by myself (or with other managers) and then spring them on the teams; instead, I like to have one or more team members participate in the interview process also.  I may ask you if you can help out in one or more of those. Important:  **If you need time to talk, let me know.**  My schedule fills up sometimes, but I've always been able to find a way to talk to someone who asks for some time. # # Process These are some cliff-notes about different process-related items. ## Effective, not (just) efficient Too many parts of Ag Leader talk primarily about what is efficient   **I want you to be effective, not just efficient.**  Not just you, but your team as well.  Efficiency is part of effectiveness, but it is not the overall goal. ## Work Hours I trust you to figure out what working hours are best for you, within the constraints of Ag Leader's core hours and the team's expected meeting times.  If the team's recurring meeting times are causing problems, I expect you and the team to work together to find times that will work. I try not to send many emails/messages outside of usual working hours.  If you get an email/IM from me after hours, feel free to wait until the next business day to respond. I dislike calling people. **If I call you, it's probably some sort of emergency.** ## DRI See [these](http://originalfuzz.com/blogs/fuzz/83782148-the-directly-responsible-individual) [articles](http://www.quora.com/How-well-does-Apples-Directly-Responsible-Individual-DRI-model-work-in-practice) for background.  The gist is for each decision, to be clear who ultimately makes that decision. This means that I try to be clear which decisions are mine to make, and which are yours to make.  I also have a modification of this, in which there are some decisions I expect a team to make, but I don't care _who_ in the team makes the decision or (usually) the process used to come to that decision. If I say that a decision is mine to make, I should reasonably expect to make all decisions for similar issues in the future.  If you think I should delegate the decision, you may certainly ask why I think I should be the one making the decision. If you are the DRI for a given decision, I can still try to persuade you -- after all, providing context for your decisions is part of my job (but see known failure modes below). It's fair game to **ask me to clarify who the decision maker is** , if there is doubt about such. # # Communication ## Explicit beats implied You know the old saying about assumptions.  When it comes to expectations for work and performance, explicit beats implied.  Ideally this means you should never be uncertain what the expectations are, both for your personal actions and for the outcomes of the work you do.  Realistically, you may sometimes need to ask for clarification. Much of what I write (including, of course, this README) is designed to make expectations more explicit. **If you wonder whether something is a thought, an opinion, a request, or an order, please ask.** I hope for the same in return.   **If you need something from me, please ask me explicitly** , and don't assume I know by implication. ## Radical Candor See [this article/video](http://firstround.com/review/radical-candor-the-surprising-secret-to-being-a-good-boss/) for background. I aim for the intersection of caring and candid.  I may struggle at both.  In particular, I'm midwest-nice, which means I'm not always as candid as I should be.  As expressed in the article, caring about someone may mean telling them something that may hurt them at the time. If you don’t understand something I’m saying, you can always ask me to be more blunt — if there’s feedback to be given, part of my job to make sure you understand the feedback. If I’m doing things properly, **you should never be surprised**. Especially not negatively surprised. Rarely, I’ll be asked to keep certain things secret. I’ll still try to convey what I can, if anything. I’ll try harder if it affects you.  If something absolutely must be secret, I’ll just refuse to answer. I won’t knowingly lie. There are some (very few) things I must refuse to answer on principle, or open myself to answering by sometimes refusing to answer. Most of these are around interactions with other employees. ## Red-Orange-Green This is an explicit method for quickly assessing how you stand on performance: - **Green**  There may be places to improve, but if nothing changed (on either side) you could work here for as long as you wanted. - **Orange**  There’s something that, long-term, makes your current performance unsustainable. If it continues, things will eventually not end well. You’ll need to change something, but we have some time to figure out improvements. Examples of this might be a skills deficiency, or being too careless with code changes. - **Red**  Your performance is short-term unsustainable, _and_ there’s a specific, concrete time box we’ll put around changing it, _and_ we’ve had an explicit conversation around what is wrong and what the timeline is. This is a mental check I'll occasionally perform, but I don't usually make a habit of going around and telling people what their color is today.  (If you want to know, you may certainly ask me how you stand.)  Note that transitioning from green-\>orange can happen as I recognize a pattern or a shortfall, and with the benefit of hindsight I might realize that what I thought was green was actually orange (or vice-versa). **Red is never a hindsight realization.**  The qualifications for being red mean you'll know about it at the time if that designation ever applies.  If I've done my job, nobody will be surprised at being red status (see the Radical Candor section above). This means if you want to ask “am I red right now?”, the answer should be no. **Going orange is completely recoverable****.** Even red does not have to end in firing/leaving. ## Feedback [Background here](http://medium.com/@royrapoport/why-wont-you-talk-to-me-f30a01a1994c). The gist: I realize feedback needs to: - Be safe to deliver - Be easy to deliver (not received defensively) - Result in change or the feedback stops coming to me.  I strive to keep these three points true when feedback is given to me.  If any of these things stop being true for feedback you give me, please give me _very pointed_ feedback directly stating so. ## 1-1s I'll plan on having regular meetings between just the two of us.  These meetings are intended to be valuable for both of us. **Timing** I tried to find a time that works reasonably well for our schedules. If another time could be better, let me know and let's see about changing it.  Odds are we'll be able to work out sometime. We can change the frequency or length also, within some parameters, though I tend to gravitate toward frequent, smaller check-ins. If one of us is out for whatever reason, we'll probably skip that meeting and catch up on the next regular time.  If I had to miss, I may offer to find another time if you'd like.  If we would end up missing too many in a row, I'll actively work to schedule a make-up time that week. **Content** These meetings aren't for status updates, unless that's what you'd like to talk about. I'll usually start by asking if you have anything to talk about.  I'll frequently come prepared with my own topics.  Nearly always, your topics will take priority in our discussion. **Disclosure** I try to keep what we discuss between us, and if I do talk about things I've learned in the 1-1s, it's usually in generic terms (i.e., "$NAME mentioned they were interested in learning about $NEWTECH"). I may ask to convey some information from the discussions to specific people.  This is usually good things that I learn (or am reminded of) in these meetings.  I may also encourage you to offer direct feedback to other people on topics that come up in our meetings. As a manager, I do have some legal requirements for disclosure.  When I hear actionable things discussed in a 1-1, these are the general categories I use to file the information: - I have no need to disclose this and it stays between us. - I'd like to do something about this, if you want help. - I feel part of my job is to do something about this, and I'm going to do so unless you give me a (time-limited) good reason not to. - I'm obligated, either morally or ethically, to report and respond to this.  We can talk about the steps of disclosure if you'd like. So far, most topics fall into the first category, some into the second, very few into the third, and I've been fortunate to not yet need to deal with the fourth.  It should be obvious from our discussion which category applies (i.e., I'll ask how I can help), but you may certainly ask if unclear. **Tech** I (and others at Ag Leader) have been using getlighthouse.com for 1-1s and goals.  You'll get an email from them to set up an account if you'd like, and periodic emails asking if you have topics you want to add to the agenda for our next meeting.  With an account, you can also go on at any time to add things to the agenda or update other information. # More About Me This is a hodge-podge of other notes you may find useful. - I'm an INTP or INTJ, though close to center on N/S.  I have more details, including a comprehensive report, if you'd really like to see it. - My top strengths via Strengthsfinder are all in the Strategic Thinking category. - That is, I like  **learning and thinking** quite a bit. - I'm a big fan of board games, especially some of the relatively recent variations. ## What (I think) I’m good at - Understanding what software development requires - Translating dev-speak to manager-speak and vice-versa - Leaving space for developers to do their work — avoiding micromanaging. - Different psychological approaches to thinking through problems - Writing voluminous tomes of information ## Known failure modes - I take not-micromanaging too far sometimes: - I don’t always provide enough feedback (good or bad).  I will provide facts that lead to my opinions without providing my opinion ➡ This is less of a problem once I know you can resist my opinion ➡ I try to be explicit about what is my opinion vs a command. You can always ask. - I procrastinate on things I know I need to do - I’m not as blunt as I should be at times ➡ Feel free to ask me to get more blunt in a conversation (scale from 1-5?) - The lure of the code can be strong - I may over-apply psychological models - I frequently write more than others read -- if you read everything thus far, congratulations!