(Not Required) "README" for Managers

There are as many reasons as not to create documents about your core beliefs, personal mission, and working style.

When you manage a team that cannot frequently sit in the same place, it is important to create documentation that allows your team to reference that useful thing you said once in a team meeting or 1:1.

My format changes over time, but key sections I always recommend:

• Your core professional values (as a manager, leader, person, etc)
• Tips for people onboarding to working with you to set reasonable expectations
• Your expectations as a manager that may not be written in an issue tracker or HR document
• Areas that light up your brain (where someone can find common ground with you)

I keep this mostly as an internal document, since the target audience are people on my team or those thinking about working with me. Publicly, one version of this can be found as a Gist.

my (current) Manager (Not Required) README

My core values

• Enable a growth mindset
• A team is more than a collection of individuals
• Sustainability is always a priority
• Give cover for calculated risks
• Build soapboxes, shine spotlights

On working with me (and space i’ll definitely give you)

• I work spiky :) This is sometimes due to personal commitments, community organization work, talks, coffees, my brain getting interrupted by things that are not specifically helping me to achieve the deep concentration or mundane task accomplishment that I need to at the time.
• Finding me at a given time can be challenging. I am doing my best to keep my calendar up to date with personal commitments, WF[x] where x = TLA for office location
• Am I OOO? (Hooray for me!) [internal doc] can help you find a person who is not me to help you on X.

on team culture

• I don’t believe that people fit in boxes. People aren't defined by check boxes and surveys. I actively rail against managers trying to make squishy people into squares that fit into the spreadsheet of a team.

• I think of teams like moss gardens. I look for gaps, try to understand the shape of that gap, then look for humans seem capable of growing to fill that gap. Then I watch them grow, see their directions, and try to guide based on where they find air + energy. I am not perfect. I make lots of mistakes. I am learning constantly.

• Building a psychologically safe, effective, distributed, asynchronous team is harder than any other professional challenge I have faced. But this is what I am here for. This is my hill right now.

• Psych safety in our team means building a team culture where people can be present externally + internally, in different time zones + communication channels, and where dissenting voices or those impacted by acts of others are able to voice that in forums without feeling 'othered'. This is a challenge for all of us.

General managery bits

• More frequent check-in's > If you need time with me more frequently than bi-weekly, that’s fine! Let’s talk about how we can balance check-ins to make you feel supported and able to move quickly. I will always find time for at least a quick VC.
• On feeling overwhelmed > Scaling back is always okay. If you feel like you are being pulled in too many directions at once, we need to check in on your time, capacity + priorities. I never want you to feel like you have impossible choices to make or that you are not able to be effective with all that is being asked of you. It’s not a burden and is my job to help you focus your energy and impact.
• On ruthlessly prioritizing > I am a big advocate of this and still very much growing in this area. I promise that I am better at helping you do this then I might be doing it for myself. Again, never a burden. I want to make sure that you are focusing on the right things. It won’t always be what I choose, but I will ask questions and try to help you understand what choices you should be making. Of course, there will be times that I bump things up to deliver on promises we have already made over what might be more exciting projects. Consistently following through on work we start is important. Saying no when we are at capacity is always better than taking on too much.
• You are always empowered and encouraged to deflect future work asks + scoping of priorities to me. You don't have to organize the priorities of the product/DPE team yourself. A very handy phrase I expect you to use as often as you need: "I need to check my priorities and capacity with my manager before committing."
• On saying yes or no > I will never commit you to work without asking you first. If someone asks me for more, or for additional assistance, you’ll always get a private communication from me checking in on your capacity + interest. If you don’t know your capacity against your current commitments, this is the perfect time to talk about them with me! You can say “I don’t know.”
• You are always empowered and encouraged to add me to meetings or calls with the teams you work with. This gives me a better perspective on what is being asked of you and allows me to better scope what resources we need. Never a burden, is my job, and I delight in party invitations.
• The collective DevRel commitment and aligning of resources for launches is not on your plate. This is something for the managers to work, especially as we have resource constrained teams. It’s never a negative mark on anyone to pull together the collective people on a launch/project with me and other DevRel managers to make sure we are able to provide a good experience for our developers and with our partners.
• Getting more help > Do you need more help for a project? Mentors for a specific language community? Assistance getting your vision for a product experience executed to the level you want to deliver? Excellent! I want to help you find that. Our team is big. Sometimes comms fall through. Don’t lose sleep. Don’t burn out. I want to help you find the help you need.
• [deprecated for now] If you are having to WFH as a “work around” to not finding conference rooms, quiet work spaces, or transportation, please use our team’s steam valve to let me know.

on prioritizing EDII + community building

As our team grows, continuing to bring in team members who reflect the intersectionality of our current + future developer communities is one of my highest priorities.

I always view work in building external relationships with developer communities for existing and future customers as vital + essential to our team. The directions that you specifically move is entirely up to you, and I will be interested in hearing about the decision making process you use to determine this.

on taking care of yourself + self-care

• I may not always recognize when you are struggling or need more help. You are allowed to say to me “Help, I need help.” without knowing how, why, or what’s going on. I don’t expect you to have all the answers immediately and will do my best to listen (working on this). We’ll find a path forward.
• Work-life balance…. I agree with [internal doc]. When you spend personal time for our company, I expect that we will balance that out with your traditional working hours. I can’t add your extra hours in Workday, so we can come to an agreement about how to balance out your unbalanced schedule when it happens. I am vested in your health + success, which means I would prefer that you are not a crispy critter (aka burned out).
• Take the time you need during the day to be most effective. Schedule breaks, food, social interaction, perks, team activities, exercise. I trust all of you to be responsible adults who will carve out their general cadence to be healthy, happy, productive people. You have my explicit permission to take care of yourself.
• At some point in your life, you may find yourself in the role of caretaker of another adult. This guide, written by an excellent human, is extremely helpful.

on devrel

No one uses our products because they just absolutely love it. People use our products to solve their problems. They adopt different products that help them solve problems in different ways.

• We enable adoption by helping developers understand how to use our products to solve their problems. We help our products by shaping the developer experience so that their hard work is as effortless and easy as possible to implement, by making it easy to understand how our products solve their problems, how to get started to find the right choices for themselves, how to know what to do when things go sideways, and how to find human help when the docs aren't enough.
• Community organization + involvement in DevRel should be opportunity without obligation.
• Get cards, preferably an international style. It’s easier to have them on hand for events than order last minute. [internal doc]

big ideas my brain is working on that I don’t always realize

• Lifting up the next generations of developers
• Building teams holistically
• Evolution of compute-at-scale and open source as complex networks
• Impact of pseudo-infinite compute-at-scale for systems where - ML/AI can be unintentionally weaponized against users
• Sustainability in open source communities