Based in San Francisco, Remote Branch is a blog by Todd Larsen. His posts suggest Management best practices for Hiring and Mentoring software engineers.

My User Manual

Todd's User Manual

Motivation for this document

This document is intended to introduce you to my management style, philosophy, and expectations. The intended audience is everyone who reports to me but anyone is welcome to read this and share feedback on it. Use this as a reference for what I expect from you and what you can expect from me. This is a living document and will change as I grow and learn how to be a better manager. This is heavily inspired by The Indispensable Document For Modern Managers.

My role

  • My primary job is to enable you to help make the team win.

    • Winning as a team means both achieving our quarterly OKR goals and maintaining a fun, safe and satisfying work environment.

  • My secondary job is recruiting and hiring more people to join our winning team.

What do I value most?

  • Clear, proactive communication and follow-ups on what we've previously talked about.

  • Thoughtful planning for technical implementation and production validation post-deployment.

  • Ownership of your domain of work.

  • Resolution. Few things are better than a fully completed project without any loose ends.

  • Simplicity.

My Expectations

  • Ad hoc 1:1s when something is important and can't wait until our next scheduled 1:1.

  • Punctuality. We have a lot of freedom of time but that means when we agree to meet at a certain time, be respectful of everyone's time and show up on time.

  • Meeting attendance, productivity and daily standup report with details. I don't care when or where you work as long as you're productive and loose ends don't linger.

  • Hierarchy of communication (most→ least urgent): Call (773-209-4313)→ Text→ Slack (@todd)→ Email (todd@digit.co)

  • I like quick acknowledgements even if you're not going to work on something right away. a quick “got it” or :thumbs_up: lets me know it's on your radar and I can trust you'll update whoever needs to know when the time is right.

  • It's impossible to over communicate. Don't assume I (or anyone else) know what you're working on.

  • I define “done” as: you've verified that your code is functionally working in production, you've notified the stakeholders in the project, and you've verified with data that it's having the impact you'd expect.

  • PTO is at your discretion and you just need to add the time you'll be taking off to the OOO shared calendar. Take time off when you need it and remind me (and your team) that you'll be gone ~1 week beforehand.

Your Expectations of Me

  • I’ll never get upset about over-communication. When in doubt about the value of communicating something to me, err on the side of letting me know.

  • Think of me as a volunteer firefighter to jump in when you can use some assistance. Or think of me as a lifeguard to throw you a life preserver if you feel you need some urgent help on anything.

  • I will provide context on why you are working on what you're working. If you feel you're missing some context or if it doesn't align with our goals, please let me know.

  • Gentle, honest and clear communication when we speak in person or in text.

  • No news is good news from me. I'll let you know when I have feedback but otherwise, I'll get out of your way and let you do your thing. Let me know as soon as there's something I can do to help you.

  • I won't micromanage you unless I feel that some of my expectations aren't being met. A micromanagement situation might feel a little awkward, but it's actually an opportunity for you to see what I expect in specific terms so you can step up to the expectations on your own as I step back.

  • I respond well to feedback and actually crave it. Please let me know if you really like, or really dislike something I do so I can either do more of it or stop doing it entirely.

1:1s

  • We'll have a scheduled 1:1 every week at a minimum, and we can have ad hoc 1:1s anytime you have something you'd like to discuss that shouldn't wait until our next meeting.

  • The goal of this meeting isn't to catch up on status updates on projects. I want to talk about your role and career aspirations, what's bugging you, or what would be helpful for me to clarify for you.

  • This is your meeting — you set the agenda. I'll ask you some questions to create some food for thought if you have nothing to discuss.

Personality quirks

  • I love hyperbole more than my own family.

  • I enjoy making jokes but can sometimes switch between jokes and seriousness rather abruptly.

  • I have strong opinions, but I'll drop them as soon as I'm convinced otherwise.

  • I love brainstorming. Invite me to your next one!

  • I tend to have a bias for action vs. simply listening to what's on your mind. I quickly move into solution mode so if this is not what you want, please let me know you're just thinking out loud and want an ear.

  • I love tools and processes but can sometimes go overboard or experiment unnecessarily. Let me know if my search for the next best tool is causing too much thrash.

Where to focus on your first 90 days?

  • Ownership of a small domain. You'll be given a small Area of Responsibility at first and I want you to become the go-to person on this AOR.

  • Reviewing other people's code. After 30 days, I expect you to start reviewing PRs and giving feedback on how code can be written more clearly or improved in some way.

  • Developing opinions. This could mean anything from how something should be implemented, to some new way our team could collaborate.

Week in Review