Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
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…
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.
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?
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.
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.
Give “ad hoc” teams a try in your organization and let your problems be solved!
