Recently I had the opportunity to interview for a manager of manager role. This caused me consider more deeply what I really want for my own career. The process helped me clarify what's most important to me and where I find the most enriching experiences in my job.
My most important goal is to increase predictability in the teams I support. I believe everything else is built upon a foundation of predictability. People need to feel part of the group, and it's very easy to figure out when you don't belong in a team. When I understand what is expected of me, of my colleagues and partners, I feel like I'm part of the team! Inclusion means I feel a part of it. But why do I believe predictability creates inclusive team dynamics?
I am most stressed when unexpected and uncontrolled events require my attention. I feel this way whether it's an incident or someone handing me a task. The world is chaotic and not handling it well looks like your manager dumping a surprise task on you, particularly with an urgent deadline. Maybe it's getting feedback late into a process, sometimes when you think you're done with the task.
Build interfaces inside your team
Rather than try to apply rigid process or structure, I think around interfaces. Organizational processes and interfaces exist so managers are successful in supporting the team. The team must be represented accurately upward and outward. In discussing the products and systems we build, the interface focuses on what isn't true and is slowly becoming true (for example, "We could not do blue/green deploys last week, but we will next week"). I don't need to know how the team will do their work. I only focus on understanding the truths and features about the systems we operate.
This interface is different than what the team needs from the other engineers. The interfaces they need define behaviors in code review and code quality, pairing, and getting design input. Creative communication is fundamentally different than tactical, technical discussion. I try to make sure there is separation and processes support that separation.
Technical discussions need to take place in the open.
Conversations about what we're doing need to be either in email (which is visible to everybody in the company) or in a ticket. The email aspect of our culture is easy to uphold and requires few nudges. It's important to push back against easy and lazy ways to make decisions, especially if the decision will be worse. For example, Slack provides an easy way to dump a quick idea into a channel and anybody who is available responds and it feels like there was collaboration. This is often fake collaboration, though. If the people chatting weren't the right people (or thinking about it deep enough) the decision will be low quality and people will be unhappy. I believe in a high functioning, inclusive team people care a lot about the quality of decisions even if they aren't directly involved. Setting an expectation that decisions are made publicly and that we will record how a decision formed improves decisions and team dynamics. If everyone understands how decisions are made they can, and will, participate.
Notifications for what you care about (like code)
Another forum that works for technical discussions is code review. We use GitHub pull requests and it only works if everybody sees the relevant PRs. To do this, we use GitHub templates to suggest reviewers and groups to notify. This ensures people will see notifications for code they care about. It's the submitters responsibility to follow this practice but the templates make it easy. People stick with it because it's easy and it works. We have several monorepos and watching entire repositories is not an option. Some awesome folks built a great tool (inspired by Herald) to create rules that allow "For any change to this file, notify @team".
If something is truly urgent, we treat it as such. Handling emergencies well is another aspect of being predictable. We can't predict emergencies but we can predict how we'll respond and support each other in difficult and urgent situations. Fortunately our incident response practices help us, even if it's not a true incident. It's always acceptable to ask, "is this urgent enough to interrupt people?" If it is people should know what actions they need to take. This needs to be very clear, like "You have 5 minutes to acknowledge the page, have your laptop connected and be ready to work the problem" rather than "You have a 5 minute response time SLA".
Asynchronous processes help Remote inclusion
If the interfaces are well defined and understood, supported by lightweight processes, then they can be adapted to support people who may not be in the same office. Moving conversations to structured, permanent mediums includes people across timezones and lifestyles. We have an expectation that you should clear your PR review queue twice a day, evenly spaced out. We also ask people to be predictable with their hours, so even if someone is in London we know when they'll be available. Usually this just looks like putting specific end of day markers on your calendar, in addition to setting working hours.
Supporting remote workers well is an exchange of temporary, real-time efficiency for a few benefits. The most obvious and widely cited benefit is a larger talent pool. What's relevant in this context is being more meaningful and deliberate in discussions. There is plenty of evidence that suggests the more mindful and deliberate we are in discussions the higher quality work is produced. Interfaces that enable this type of distributed collaboration come at an efficiency cost, but in my opinion the rewards are well worth it.
Feedback is an interface, use it regularly.
Feedback is critical and something we should always work to improve both receiving and giving feedback. I give feedback on meeting participation in 1:1s to help guide and nudge the meetings in the direction we want. Whether someone is interrupting, speaking "out of your lane", or not speaking up enough it's easy point these behaviors out. People want to be part of a team and pointing out any actions that move them outside the team has never been unwelcome.
Building up a culture of regular feedback in a team requires constant energy investment, especially when new people are added. Last year the team grew a lot, and in the beginning I tried to propose a working agreement and it landed nowhere. When a team is just starting to normalize and gel, expectations around feedback are hard to solidify and all of my efforts failed. Once the team knows each other (in my experience this takes a minimum of 3 months after adding someone to the team), setting feedback expectations will start to be successful.
Separate Expectations, Goals, and Feedback
In the beginning, rather than feedback on individual behavior it's important to talk clearly about expectations. I realized over the last year that many of my expectations for myself weren't talked about openly, and also I didn't understand all the expectations people had for their manager. Some people want deeply technical managers, others want a manager who largely leaves them alone and advocates for their work or provides aggregated feedback. Knowing what's necessary is a two-person agreement, but an agreement comes from talking about expectations openly.
One area I'm actively working to support is an interface around team members sharing goals directly. It's common that 3 people on the same team share the same goal but nobody except the manager knows. I would love to work in an environment where people share their goals and aspirations and feel they'll benefit directly. When opportunities come up that would help my progress I can be included if people know those goals. Without that knowledge why would someone invite me to shadow a process or take smaller projects? They wouldn't!
Some of these interfaces feel stable and some are still very much a work in progress. At the core, my actions originate from core principles. I'll close with 3 guiding principles I use to support a team. (This is entirely stolen, with much love, from Jerry Colonna):
- Hold the vision: We set the team vision together, with input from our users and customers. It is my expectation to hold this vision so we don't lose sight of it. I expect the members of the team to deliver great products in line.
- Cultivate the culture: This is watching, listening, observing and sharing those with as little judgement as possible. After learning from a team member, I can state that my goal here is "Help everyone contribute to the environment so everyone succeeds, as success is a byproduct of a healthy environment"
- Provide the resources: If someone needs time to learn I need to make sure that's available. If there is missing knowledge I will find a path to gain it. If someone is unwell, as we're fragile sometimes, I will work to support restoring health and wellbeing.