Engineering team identity

I recently shared some tips for helping teams define how its members work together. You could think of that as defining your internal interfaces. As your organization grows, it's also important to define your external interface, outlining how other teams and individuals in the org work with your team.

Both distributed and co-located teams can benefit from getting explicit about their role within the broader organization. Here are some practical things to include in your team's intranet page or GitHub team repository README.

Who we are

Include a team roster with names and photos or avatars. Every team has its own unique identity, but try to put a human face on the work you do, especially in remote environments.

In an industry of overloaded terms, avoid confusion and clearly state why your team exists, its raison d'etre. Call it your mission statement if you like, just keep the language aspirational yet grounded, something the entire team can buy into.

When Rick, Jason, and I were booting up an API team at GitHub we settled on something like:

We help developers build workflows on top of GitHub.

Why it's important: Getting explicit about your team's purpose helps frame what you work on, and what you don't.

What we do

Every organization has seams, gaps, and overlap. Building on your team's purpose, outline your team's areas of responsibility, enumerating the services and swaths of the code base your team maintains. If you share responsibility with other teams, get explicit about that, too.

Why it's important: Discoverability accelerates work, especially in distributed organizations. Use your team page to outline your areas of responsibility and link to documentation that might answer someone's question and save your inbox.

What we don't do

When you're seeking help, an unresponsive team can cause frustration and quickly erode trust. It's better to preemptively let others know what things fall out of your area of responsibility than constantly field @mentions for things you don't handle.

Why it's important: Failing to get explicit about what your team does (and does not do) can lead to unmet expectations and mistrust from those outside your team, impacting your ability to deliver.

How to get in touch

If you're going to work together as a team, you need to manage communication as a team.

Preferred channels

Different teams doing different types of work will need different tools to manage inbound and outbound communication. Your team likely uses a blend of email, chat, issue trackers, or help desk tools. Clearly advertise your preferred method for receiving messages from others — your Slack channel, GitHub team handles, help desk queues, etc.

Expectations of response

Most teams perform a blend of duties, not all having the same priority. Set some goals for how quickly your team will respond to a ping (especially for support questions or requests for code review). People are usually better at waiting if they know up front what to expect.

Why it's important: Getting explicit about how others ask you questions or get work into your queue reduces drag on your process and avoids unmet expectations which can diminish your teams social capital within the org.