Organize your experts with ad hoc teams

Many engineering organizations sort developers into teams like application engineering, platform engineering, web development, systems, and quality. Structuring organizations in this way can leave blind spots that exclude the people best qualified to help solve a given problem. To address this blind spot at GitHub, we’ve tested out a few alternative ways to organize teams by expertise, rather than by application. We refer to these highly specialized groups as ad hoc teams.

What are ad hoc teams?

• GitHub Teams that group people with similar skill sets or interests
• An opt-in social contract to respond to problems in a given domain when called upon
• A vehicle to facilitate developer capability and knowledge growth
• Can be created without administrative intervention
• Variable duration: could be for one problem or long-running

Why use ad hoc teams?

It is rare for a problem to be uniquely applicable to any one application team. Members of several other teams may be better qualified to solve a given problem. Additionally, when a problem is overwhelming to the team primarily responsible for a solution they are often left with few options for help. Why let these common issues stop you from getting the job done when you can organize folks across formal teams into highly specialized problem solving forces?

How do ad hoc teams work?

Imagine a scary situation where a security vulnerability in a JavaScript application has opened up your SQL database to malicious actors. Who would you call for help? While the application may belong to a specific project team, high profile issues like these are everybody’s problem. You can immediately get more eyes on the issue by @mentioning teams that might be able to help. This may include your JavaScript developers, SQL experts, and the security team.

The image below illustrates how ad hoc teams can leverage the expertise of multiple members on different teams to solve a single problem.

If devGroupA owns the application, @mentioning all three function-oriented teams helps them reach several people who are members of all three teams but not part of their formal group. This increases devGroupA’s problem-solving capacity, puts more eyes on the issue, and results in a faster solution.

Meanwhile at GitHub

We’ve applied this concept internally with an enterprise-scaling team made of Hubbers that design, build, support, and sell GitHub Enterprise. We encourage folks to @mention this team whenever a customer is planning to scale up their use of GitHub in any aspect. Team members also happily @mention the whole crew whenever interesting threads pass their way. Through this team we’ve been able to spread information from multiple perspectives to those consulting directly with GitHub customers without scheduling meetings with everyone synchronously present.

What benefits should be expected?

• Better support teams with escalation paths for common engineering issues.
• Resolve problems more quickly by involving the experts when you need them most. No need to wait until tomorrow’s stand-up meeting.
• Uncover underutilized known and unknown talents.
• Get fresh perspectives, challenge assumptions, and thwart groupthink.
• Share knowledge when problem domain experts see an issue differently than application experts.

In conclusion

Give “ad hoc” teams a try in your organization and let your problems be solved!