Below is a copy of the text I provide to everyone who works on one of my teams. It’s intended to be high-level overview of what I care about and, thus, ultimately how my style of running teams manifests itself. I’ll note that I consider it a living document and when bringing someone onto the team I ask them what they like/don’t like about it. That feedback process is actually really useful. I hope it helps someone out there.

There’s many approaches to how people build teams. Including not having an actual approach. In general I tend to focus on two main themes. Fun and execution.

Why fun? Because I spend 40+ hours of my week at work. I do not want a giant chunk of my life to be dedicated to something I do not enjoy. I do not want to foster a place to work that is not enjoyable for the people who a part of it. I believe teams who are enjoying themselves are more creative and come up with better solutions to the problems/challenges before them.

Why execution? There’s the obvious reason. I am personally accountable for executing on tasks the company needs to accomplish. Every individual on the team is responsible for their own part of the larger goal. So for obvious reasons we must execute to be healthy members of the broader organization. There’s a not-so-obvious reason, though. One that is intrinsically linked to fun. The reason I became an engineer was by default for me. I always enjoyed creating things. My hobbies as a child, and still today, include creating things. It is fun to build, it is fun to ship something. So we also focus on execution because we can be proud of the things we’ve shipped.

Prioritizing these has natural consequences for how I both run and build teams. Specifically, I build teams with:

  • High-trust
    • Succinctly: You are expected to be an adult
    • If you have an issue, raise it
    • If you sign up to accomplish something, accomplish it
      • Clearly communicate when circumstances prevent you from executing on what was agreed
    • You are expected to not require reminders for things you’ve agreed to
      • Daily stand-up? Do it. Boring task? Do it. Follow-ups with others who aren’t organized? Do it.
    • Relish accountability
  • Balance
    • There’s more to balance than work/life, but that’s part of it
    • “Not everything worth doing is worth doing well” - Tom West (Soul of a New Machine)
      • AKA “Don’t let perfect be the enemy of good enough”
      • Nothing is perfect. Know what is acceptable, aim for it.
      • Balance when, and to what degree, we polish, optimize, argue, etc.
    • You have a life outside of work, enjoy it
      • Things come up — sickness, emergencies, dry cleaning, vacations — we’re a high-trust team, you shouldn’t feel guilty about life happening
    • Learn to master your day — you know best how to manage your own time. If you work better at night, work at night. Certainly there are exceptions (like when we need to communicate with other during respectful hours), but for managing your own time you have free rein. I do trust you to MANAGE it, though.
    • Learn to know when to say “no”
      • When you’ve taken on too much
      • When the return isn’t worth the investment
  • Empathy/Respectful
    • We’re all organisms flying around on a space rock trying to figure out life — there will be differences in how we figure life out. That should, minimally, be respected.
    • Everyone is different and brings a different perspective to the table. No perspective is fully right or wrong, but every perspective can be learned from.
    • Answer your own questions
      • Most questions can be answered without outside assistance, when you can you should err towards answering for yourself
        • Practice balance here, at some point it’s more efficient to raise your hand and ask
        • Time-boxing is a good mechanism for this
      • If something is sufficiently obscure and you’ve taken time to answer it then it’s worth documenting for others
      • There’s natural limits to this, you’re trusted to balance
    • Ask Questions Correctly
    • Prefer async comms
      • Almost every team I’ve run has been distributed (Few developers live in Louisiana, turns out)
        • Distributed teams REQUIRE good async comms
      • Async comms allows others to answer in their own time
        • When the context is right to find the answer
        • When its durning regular office hours
      • Not everything can be done async
        • You’re trusted to balance when it’s not appropriate
        • When done correctly you can maximize productivity by being async
    • Write down/document obscure/unintuitive things
      • Help others answer their own questions
  • Rigor
    • Be thorough. Have reasons for your beliefs.
    • Be data driven
    • Be aware of your bias
    • Test your assumptions
      • Yes that means code, too
    • Know what you’re doing, and communicate it
    • Remember to keep it balanced
  • An iterative nature
    • Things improve through investment
    • Things are built or fixed where we place our resources (time, money, etc.)
    • Start with minimum-viable solution and build from there
    • Avoid the pull to optimize before knowing the constraint
    • Try to iterate while it’s cheap
      • Designs are easier to change than code
    • Everything is mutable
      • Even this document
  • High performance
    • Our team is one others wish they could join and one the we are proud to be a part of
    • We finish the things we start
    • We make high integrity commitments
      • Other teams (engineering or cross-functional) can rely on us
    • We deliver on what we’re accountable for with speed and accuracy
    • We solve problems others can’t

Questions

Below I copy/paste from some advice John Hart once provided an intern, because it characterizes things a lot better than I could. Also (John here) I find myself sometimes forgetting these points, and have to remind myself. Sometimes it feels useful to post stream-of-consciousness discoveries in Slack, but quality beats timeliness 99% of the time. This isn’t pop journalism, you’re not going to get “scooped” if you spend a bit more time before hitting “send”.

I want to offer some guidance about the best way to ask questions & communicate with other members of the team, be they myself or Bob/Alice or other team members or, really, anyone else in the company. This is the type of thing that people tend to learn after they’ve graduated and entered industry. The big thing is “don’t send incomplete information” - if the other party immediately has to turn around & ask you a question to figure out what you’re talking about, then you haven’t provided sufficient data in your first communication and thus are not respecting the other person’s time. Every email you sent should be as complete as possible, and should represent your best possible effort at being the last email you have to send regarding the topic at hand. In other words, don’t say “hey something is wrong why won’t it compile”?. For anything you send, you should provide a ton of information so the person receiving it doesn’t have to turn around and ask you a question right away. Lots of little “clarification” emails sap the will of both parties and lead to fatigue. More concretely, this means any request for help should include:

  • Full context - the exact situation you are in, what you are trying to achieve, and what is blocking you
  • The exact error or unexpected behavior, including error message(s) if any
  • What you have done to try to resolve the problem yourself - links to StackOverflow articles that you’ve read, why they didn’t work or don’t seem to apply, etc.
  • Possibly paths forward that you are considering, and need help arbitrating amongst
  • Links to anything linkable, including results in Scalyr, blog posts / stackoverflow articles, and relevant Scalyr code lines in github. Don’t make the recipient do any searching.

One thing that you are likely to find is that, in the process of writing a complete & well-described “ask for help email”, you’ll actually figure out the answer yourself.  This is the best possible outcome! A question well-stated is a question half-solved. See also “debug duck”.

Buddy

When bringing on new members I will pair them with existing members of the team. I want to create a high bandwidth connection between the new team member and our team. This will allow the new member to understand and adapt to our culture, have guidance while getting familiar with our tech stack, and give a connection back to the team on areas to improve or change. A buddy is a formal title with formal time limit. Formal “buddy” relationship will only last the first 3 months of the new member’s time on the team.

For the New Member

  • Ask for clarity on confusing items/tasks/documentation/code
    • Enhance our docs/code comments etc where it makes sense to
    • Keep this mostly to our team or dev-related questions. There are company resources for the other items (HR, Legal, Finance, Me, etc.)
  • Technical Issues/Dev Setup
    • This is well documented, but can sometimes go out of date, if you have an issue that is somewhat tribal knowledge, ask
    • Make sure you update the onboarding documentation when you’re done
  • Team Dynamics
    • Don’t be afraid to ask about things that aren’t documented
    • Knowing how the team actually works is important
      • Don’t just get the idealized version from this doc
  • Remember to try to answer your own question first, but time box it so you don’t get stuck
  • Provide feedback on improving onboarding process

For the Existing Member

  • Read the above for what I expect from the new member
  • Ensure you push the new member towards the team culture
  • Don’t be too quick to answer questions
    • Your default should be to push help them answer their own question
    • There’s the “teach a person how to fish” adage, that I like to adapt to: “Teach a person how to learn how to fish”
  • Be generous up-front but taper — over the 3 months it should decrease