Four Essential Specializations In High-Performing Engineering Teams

High-performing teams self-organize best when everyone brings complimentary skills

What Makes Teams High-Performing?

Think back to the most effective teams you've ever been a part of, observed, or led. What were the qualities of those teams that made them stand out? Why did you and others have high regard for that group of people?

The best teams I've observed were independently delivering desired business outcomes by shipping high-quality, incremental releases on a regular cadence. These teams didn't only ship features, they regularly worked to improve how they designed, built, tested, monitored, and maintained their systems. Each team member understood how they contributed to their team's outcomes and the company's success.

The most effective teams weren't chosen based on availability or convenience, they were chosen specifically to contribute skills necessary to create an autonomous team capable of independently delivering value.

Laying The Right Foundation

I suspect most individual contributors and leaders understand intuitively that building and growing teams is about finding the right balance between just enough structure, process, and policy and ensuring the right skills are present. We all want recognition and support in pursuing our own career paths and growth trajectory. Having too many people in the same specialization will result in competition between team members for opportunities to grow and demonstrate proficiency while creating vacuums and skill gaps in neglected areas.

High-performing teams require thoughtful planning around the necessary specializations and a solid understanding of your team member's areas of expertise and interest.

T-Shaped Skill Sets

Specialization and general competency are equally important

Successful teams are composed of members with T-shaped skill profiles; competent across multiple specializations and focused expertise in one area. Teams with overlapping skills are more resilient to temporary and long-term changes in membership. Teams with engineers that lack rudimentary skills and understanding of disciplines outside of their specialty will struggle to maintain delivery during periods of change and will likely require more engineers to address gaps in the team's collective skillsets.

Four Essential Specializations

Infrastructure

Key activities in this specialization center around provisioning, securing, managing, and maintaining the hardware, operating systems, third-party systems, and permissions required by their team. They should be proficient at automating repetitive tasks, familiar with one or more cloud providers, good with continuous integration and delivery, and supply the team with guidance around secure engineering practices.

Teams with adequate ability in this specialization won't see PRs and build pile up behind provisioning, build, or deploy steps in their process. Teams insufficiently staffed in these skills will:

1. wait days, weeks, or months for provisioning

2. get stuck in slow and error-prone builds

3. spend a lot of time coordinating human-intensive processes to deploy

Platform

The platform specialization should provide abstractions over infrastructure; data storage, networking, and third-party services. These abstractions should handle input/output considerations through APIs that express engineering capabilities in the context of the business domain. A platform focus in your teams will accelerate the creation and evolution of the application by reducing the cognitive load that gets introduced when every "back-end" engineer has to know how to program directly against infrastructure dependencies. Poor or missing platform focus on a team will slow delivery as the entire team gets bogged down in:

1. how to model, store, cache, and retrieve data

2. how to defer work to background processes

3. third-party technology selection

Services

The services skill set should produce business capability-oriented APIs for client applications and integration partners to consume. The model developed to implement business capabilities is arguably the most critical part of your system. When engineers can focus on the model, free of side effects and cognitive load handled by platform and infrastructure engineers, the result should be a model that is easy to understand, easy to change, and easy to test.

Teams that are missing a service specialization will:

1. minimize effort by relying on "one model" to use across multiple value streams

2. avoid automated testing because of tight coupling with infrastructure concerns

3. produce APIs that leak implementation details and have a narrow scope

Client

Can you think of products or services that failed to take off because of poor user experience? Mobile, web, and desktop application skills will support the delivery of compelling user experiences. Like the other disciplines, there are separate bodies of knowledge and experience necessary to produce good outcomes. A good user experience seamlessly combines branding, accessibility, information architecture, and simple interaction design that allows new users to learn your application or system through intuition, unintrusive prompts, and opportunities to grow into advanced users. Without solid client development skills, your application is going to turn customers away and limit your company's potential. It won't matter if the other concerns are handled well without adequate ability and focus on building the right interfaces to your systems.

Autonomy Over Standardization

I've had the opportunity to work with teams that handle cross-cutting concerns and organize their work like a service center based on incoming requests from "upstream" teams. This could be thought of as putting ownership of a technical domain before autonomy over a value stream. A service center approach prioritizes standardization across all value streams over cohesion and velocity within specific value streams. It also creates a moral hazard by removing teams focused on feature/value delivery from the consequences of their decisions.

Organize your teams so that they have the skills necessary to ship value as independently as possible. To address broader concerns like knowledge-sharing and collaboration across teams, create supporting secondary organizational structures and processes for practitioners with shared specializations.

Have you worked on a team that was built to have good representation across these four areas? Did you feel like the team was able to grow and deliver or were there obstacles that prevented you all from reaching your potential?