Technical leadership groups can take a number of forms: working groups, architectural groups, operational touchpoints, cross-functional teams, etc. Remembering some principles up front will help build a healthy and inclusive culture that not only gets things done, but keeps its eye on the needs of the technical organization by raising up new talent and creating a sense of belonging for everyone.
We don’t want to build an “ivory tower.” 🔗
We want the group to be inclusive, meaning that it involves the right people at the right time for a given problem.
We want to constrain the size of the standing group. 🔗
When we have too many people looking at too broad a collection of problems, we can’t be sure we have the right people for each problem, and we lower the quality of decisions due to lack of engagement and/or context.
We want to make sure the group can continue to work week-to-week in anyone’s absence. 🔗
The group should be able to operate asynchronously, taking homework away, reliably engaging the right people outside the group’s standing meeting cadence.
We want the group to work in the open, with open access to notes, artifacts, and decisions. 🔗
The group should have a Confluence space that allows for use of meeting notes with assigned actions and links to artifacts and pertinent docs.
We want to ensure that the work put in front of the group is actionable, tied to customer value, and prioritized in a global context. 🔗
The group should not be a place to scratch itches or grind axes. Its backlog should be the result of collaboration between the group’s leader (the CTO, Chief Engineer, etc.) and “senior customers,” (e.g. the Product leader, the Engineering leader, etc.)
We want the group to reflect our diversity goals by giving people from under-represented groups access to technical leadership 🔗
Too often, we frame advancement as a progression to management. By making an effort to include under-represented people, the arch group can be a forum for technical mentorship that increases engagement and retention.