The Collaboration Issue

• The team’s communication over work should default to happening here where others can follow along.
• Publicize these channels on all team artifacts (plans, charters, all hands presentations, etc.)

• While the majority of the company’s communication, especially about the work, should be open, it’s important to create a space where teams and working groups can communicate amongst themselves. 
• This is the space for not only sensitive information, but also team team chit chat.

• Team meetings can be a cornerstone of team-wide communication and team culture. This becomes increasingly true as teams grow- recurring team meetings may be the only time that everyone on the team is in the same place at the same time. Treat this time as precious and make sure that either gathering adds value to not only the work, but also team culture. 
• Try using team meetings as a chance to collaborate instead of just share updates/show completed work. The latter is definitely the easiest to pull off, but it is also the laziest and could end up being a drain on team culture because the time spent together isn’t high quality. But, the former can make team meetings a real source of connection for the team. 
  • Topics for collaboration can be sourced from some combination of requests from individual team members (“can I ask the team for help on x in the team meeting”) and requests from the curator for the meeting (“what would you think about asking for the team’s input on y challenge you’re facing?”).
• If you are using your team meeting to spotlight great work (from your team members or those outside your team), have clear principles for what is selected and document them. This will help ensure the representation is thoughtful and balanced in presenters (and not about playing favorites).  
• Send an agenda for the meeting out at least 24 hours in advance. 
• Appoint a note-taker for each meeting and have them send them out within 24 hours. 
• No meeting should be mandatory, but the content and spirit of this meeting should be so good that no one wants to miss it. 
• Try to leave administrative stuff to asynchronous communication. 
• While the team lead typically owns the agenda for the meeting, rotating ownership over the agenda can help increase engagement. This adds a bit of operational overhead for the team lead but can be a boon to meeting content because it opens the meeting up to new perspectives and personalities.

Ideas for ways to reframe your approach to meetings:

• What would it look like if we only showed work-in-progress instead of completed work?
• How can our meetings create space for team members to help each other navigate hard challenges in their work?
• What if our meetings oriented around asking questions instead of providing answers?
• What could be better shared in an email?
• What are tricky topics facing our team that could benefit from a conversation or discussion?

• The goal of standup should be to resolve any issues getting in the way of immediate progress. Most often, the meeting will center around ownership (who is taking on what workstream), priorities (what needs to be done now and what can wait, and blockers (highlighting that y is in the way and determining the best path forward). 
• When done well, this meeting should give everyone in the working group a sense that they are rowing in the same direction and mutually supporting each other’s progress. It’s also a great way for working group leaders to get a sense of when that’s not the case.

• Give everyone on the team write permissions. It may even be worth using some synchronous team time to contribute to it. 
• Make sure it’s really easy to contribute to and can accommodate a variety of formats.

•  I’ve seen teams use Figma/FigJam for these. (And, it can be extra fun to comment on/like each other’s updates)

• The list doesn’t have to be exhaustive.
• When done well, this can preempt time spent triaging hole-poking from onlookers.

• Example here

There’s more I’d like to learn before I make any suggestions. If you have any stories, learnings or best practices you’d like to see included, I hope you’ll leave a comment.

There’s more I’d like to learn before I make any suggestions. If you have any stories, learnings or best practices you’d like to see included, I hope you’ll leave a comment.

There’s more I’d like to learn before I make any suggestions. If you have any stories, learnings or best practices you’d like to see included, I hope you’ll leave a comment.

• I like Michelle Bu’s definition, “Each entry in the decision log concisely describes a product or technical decision, documents who was involved in the decision, and links to detailed supporting technical design documents that generally contain the full problem statement and evaluation of alternatives.”

• More details and examples from Michelle’s work at Stripe here.
• How WorkOS uses decision logs (and other tactics for clean cross-team interfaces)

• As time out of office goes up, so does the extensiveness of the coverage plan and the amount of notice you should give your teammates. It’s probably not necessary for a single day out, but everyone should actively consider making one for taking >= 3 days away. 
• Decide for yourself whether you will be hard offline or lightly checking in (hard offline is usually recommended to get the full benefit of the time off). Then, make sure you are setting appropriate expectations with your stakeholders. 
• A few rules of thumb:
• No one’s name can go onto a coverage plan without their explicit consent.
• Anything that can wait for your return should. There’s no need to place undue burden on anyone else in the organization.
• Request coverage from the person that has to do the least amount of work to cover you (ie- someone who already has context on the work). 
• Have a single point of contact to help route requests beyond those.  
• If you are the sole owner of something that, if it breaks could hurt the company, make sure there is active coverage.
• Team members should be enthusiastic about covering for their teammates while they take time off. Do whatever you can to build confidence that the team member going out of office really, really does not need to check it. This will make their time off more restful and impactful. Plus, helping your colleague do this will surely be a trust-building moment. And, it will make it more likely they do the same for you when you want to take time out. 
• Don’t forget to set your chat/email status to away (maybe even include an auto-response)
• It might be nice to share at least a light (but humble!) reference to how you are spending your time away to help show a bit of your personality (ie- in the mountains, in a cabin reading, going swimming, etc.). 

Take a look

There’s more I’d like to learn before I make any suggestions. If you have any stories, learnings or best practices you’d like to see included, I hope you’ll leave a comment.

• Think of “run” as a service desk that either 1/resolves requests themselves or 2/routes the request to the right people and/or process.  
• It should be easy for anyone interfacing with the team to identify who is on run. 
• The SLA for run should be very fast (minutes, ideally). 
• Measure this to the extent you can. 
• The responsibility of run should fall to a single person over a discrete time period. The expectation for the person on run is that this is their highest priority work over that time period. That responsibility should likely rotate. 
• This is a great function for new team members to shadow to build an understanding of how their team interacts with the broader organization.

• Use-case: employee A has a question that they can’t answer easily, but believes someone on team B could. Employee A submits an ‘askbot’ to team B. The members of team B are notified, and someone who knows the answer and/or is available answers.
  • Norms/expectations of employee A:
    • They have tried to answer the question themselves first (and may even share the steps they took to do so)
    • They have good reason to believe that the question can be answered easily by someone on team B
  • Norms/expectations of team B:
    • Someone will answer as quickly as possible. 
    • No askbot should go unacknowledged. If the answer is not known or easy to answer quickly, they will help the team route it to the proper place. 
    • A member of team B that sees the notification but doesn’t know the answer themselves might add a team member directly who they think can answer
    • If answering the question would meaningfully derail other high-priority work, they can ask employee A to escalate the ask where it can be prioritized against the other work the team is doing (ex- file a ticket)
    • The answer to any question that is asked >2 times should be documented to help other teams self-serve.
• Implementation: Establish a keyword/dingword (ex- ask-sales, ask-security, ask-analytics) or process that reliably notifies subject-matter experts on the target team. 

• Askbot originates in open-source software that was born in 2009 to enable internet forums to have question-and-answer functionality. 

• While there should only be one task management system for the entire company, teams should be very prescriptive about how they would like work requested from them. This will likely come in the form of a template the requestor is asked to complete. The goal of the template is to help the requestor ask their question in such a way that the target team can prioritize the request and get the question answered as efficiently as possible. 
• This is an ongoing exercise in everyone upholding global, not local, optimizations. Both teams must work together to build a shared understanding of whether the work should or should not be done, and on what timeline. 
• Aim to keep the ‘touch’ per ticket ratio as low as possible. An enormous amount of time can be wasted shuffling around priorities, updates, timelines, etc. Motion is not progress.
• Teams should think of their cross-functional partners as very high priority users and do what they can to unblock them as quickly as possible without sacrificing their own team’s progress and the global needs of the company. 

• If you get the same question 3 times, it’s probably time to document the answer somewhere. That way, your colleagues can self-serve on finding the information they need to do their work. It saves everyone time!

There’s more I’d like to learn before I make any suggestions. If you have any stories, learnings or best practices you’d like to see included, I hope you’ll leave a comment.

• Team leaders should decide with their working groups on the format and cadence for these updates. Then, they should provide the template and/or forum for them.
• There are two potential audiences for these updates- your internal team and those following along- and it may make sense for there to be a different format/cadence depending on the target audience. 
• Create an artifact of these updates to track work over time.
• These are good accountability and visibility mechanisms. They can also help supplant some of (boring parts of) meetings. 
• Team leaders and managers may want to collate individual updates as a way to report progress to their manager.
• Don’t be afraid to be open about things that aren’t going well or things you need help with. It will only increase the likelihood that help comes. And, it will show the organization what a self-aware and introspective team member you are.
• For team-facing updates, consider adding a little personality to help build more connections across your team. Maybe add a favorite song, something you’re doing outside of work, something you learned/read, etc. to the update template.

• At Alan, every employee completes an HPFO’s (Highlight, Progress, Fire, Objectives) every week. It comprises a short description of every team member’s week past and week upcoming and they are posted to a public channel every Tuesday evening. (In performance reviews, team members are asked to reference these as their official record of work)

Take a look

There’s more I’d like to learn before I make any suggestions. If you have any stories, learnings or best practices you’d like to see included, I hope you’ll leave a comment.

• This group shouldn’t be limited to people that have writing in their official job title, but they should all be great wordsmiths and upholders of the company tone. The more functionally diverse this group is, the better positioned the group will be to serve the many, many things your company will publish about. 
• They may cover: tweets, blog posts, documentation, email communication, landing pages, keynote scripts, or anything.
• Working with this group can be opt-in or required. Taking the feedback can be optional or highly encouraged. The scope of this group can expand to approvals, too. 
• This group can either be appointed or trained up. Bias towards the former to start, and consider having that team design the training.

• This group should be comprised of the people around your organization who are known to be total sticklers for product quality. It’s more important that they are able to point to places where the quality bar is not met, than have the skills or knowledge required to provide a path to fixing it (that’s the team’s job). 
• They may cover: products in any phase of development, design of the user experience or interaction 
• Working with this group can be opt-in or required. Taking the feedback can be optional or highly encouraged. The scope of this group can expand to approvals, too. 
• This group can either be appointed or trained up. Bias towards the former to start, and consider having that team design the training.

• Companies should do the right thing. There are many forces at play in an organization that might make it unclear how to do the right thing or hard for an employee to speak up about something that appears to be the wrong thing. An established process for escalating those things will encourage team members to bring these tensions to the surface and get support to resolve it. 
• Depending on the size and shape of the company, escalations might go directly to a leader or to a legal or policy team.

• McKinsey instills an “obligation to dissent” in every employee. This value clarifies that expressing disagreement with cause is not optional, it’s required. 

• Make the process as easy as possible for bug filers while still collecting enough information to get things fixed as soon as possible.
• Create a set time and cadence for the whole product team to come together for a bug squashing session. Make it fun to attend. Host it in a communal space, provide snacks, play upbeat music, encourage cross-team co-mingling.
  • Try creating a competition for most bugs squashed in the set time with some reward (formal or informal). 

• Great engineering teams will have observability systems that identify issues as early as possible in place. This is about human reporting based on what they are seeing in the run of their work. This could be anything from a potentially broken product to fraudulent behavior.
• Everyone at the company should feel empowered to open an incident. It’s better to be uncertain and open, than rigorously evaluated and not-open; the cost/minute of not opening is very high if there’s a real incident occurring. There should be no punishment for being wrong in opening an incident; it’s okay to be paranoid/trigger happy in this context.
• There should be a single and very simple way to report an emergency, and the reporter should not be burdened to find the right escalation path. This can be an email (ex- [email protected] or [email protected]) or Slack channel (#incident, #911) where the norm is to post 1/ that you think there may be an incident and 2/ what you are observing to suggest that there is an incident. There should always be a potential responder on run or on call (see: run, see on call) who can route the request to the right place. (Your PR, Sales, Account Management, and User Operations teams team may also want to follow along here).
• There should also be a directly, non-public, channel for reporting in case there is something sensitive to report. For example, a colleague doing something that requires urgent attention.

• Toyota was the first company that empowered any worker on an assembly line, not just supervisors, to stop  the assembly line if they observed a potential quality issue. This resulted in meaningful improvements to overall efficiency for the company. They later implemented the Andon Cord which is a long rope that can be pulled to simultaneously stop the line and alert a supervisor. 

• Getting this right can be hugely impactful. Communicating clearly, thoughtfully and empathetically, can boost your user’s trust.
• When the process of getting to and communicating resolution is clear, it can be a wonderful bonding moment for employees. When teammates treat each other well in these high-stress moments, high-intensity moments, it’ll build trust that lasts a lifetime.
• Incidents are almost always the result of inevitable human errors. It’s critical to your company’s culture that incidents are treated as failures of teams and systems, not individuals. If you don’t do this, it will be harder for individuals to pipe up and harder for the organization to understand and implement the systemic changes that will be more successful in preventing these in the future. 
• Set up this process before you think you need it and be committed to evolving it over time as you learn more and increase the complexity of your systems. 
• There will almost certainly be a temptation to implement fixes that make one-time incidents less likely, but the day-to-day work more toilsome. Find solutions with balance. 
• Open up a “war room” (both digital and physical space) that is a dedicated space for all communication regarding the incident. 
• Disseminate learnings broadly so that the entire company benefit from them, making the same mistake is less likely to occur next time (see: retrospectives) 

• The FAA’s Dirty Dozen refers to the twelve most common human error conditions that lead to accidents or incidents. The list was developed in 1993 by Gordon Dupont with the goal of raising awareness about the role of human error in flying accidents and incidents.  According to the FAA, 80% of maintenance mistakes involve human factors that if weren’t detected would lead to accidents. 
• Within 24 hours of one of Figma’s most disruptive incidents to-date, the company shared a blog post explaining “while there is still more work to be done to ensure we’ve learned everything we can from this incident, we want to share details about what happened and what we did to resolve it.” Even the most heavily-impacted customers thanked the team for being so thoughtful and rigorous in their investigations and communications. 

Take a look

• This is different from incidents in that it will require a meaningful strategic shift and ongoing, albeit timebound, dedicated work to resolve. 
• Code Red’s are disruptive to the organization and roadmap by design. The whole point is that everyone at the organization knows that if they are asked to work on something related to Code Red, they drop their current work to help.
• Staff strategically such that this Code Red does not cause a Code Red elsewhere. For example, you wouldn’t want to take all of your reliability or security engineers off their work at the same time. 
• Give it a descriptive and distinct name that everyone can refer to the Code Red by.
• If you’re experiencing a lot of these, there has likely been a failure in planning.
• Communicate progress often not only to direct stakeholders but also the broader organization. Everyone should know how to help.
• Gut check: If you don’t feel like it’s worth messaging the entire company about this, you are probably not faced with a Code Red.
• Note: you can do a lighter version of this for a “Code Yellow”

• Examples of external triggers for a Code Red: massive regulatory change like Brexit, global pandemic like COVID-19 
• Examples of internal triggers for a Code Red: CSAT scores at sustained lows, sustained low offer to accept rate for candidates, large sales deals keep getting lost to the same competitor

Take a look

This includes guidelines for entrance criteria, operating norms, and exit criteria.

• Create a database of employees who are open to and eligible for flexing their work if something relevant pops up. 
• This is particularly helpful for engineering teams. Include which parts of the codebase they’ve worked on (it’s a good indicator of where they can spin up quickly).  
• This is a great way to give career/explorative skill opportunities to your employees and expose leaders to the talent within their organizations that they may not encounter in the typical run-of-work.
• All projects should be mindful of any longterm tech debt they will be creating by orienting towards quick fixes/short-term solutions. 

• Google had these and called the pool of people that could be called upon to action things the chain gang. Projects were framed as business and were well-scoped (could only take 1 month or less to answer). Ambitious young employees often undertook projects.