Set up Your Engineering Teams for Success

TLDR;

Successful engineering teams don't need to coordinate. The need for coordination kills the ability to deliver. A standard set of properties help avoid coordination.

Those properties are:

• The team is small, usually 4-8 people.
• The team is cross-functional.
• The team has transparent, well-defined processes a clear process.
• The team has no silos
• The team has clear ownership.
• The team balances work intentionally between Feature, Reinvestment, and Operational work.
• The team has a manager who is accountable for the success of the team.
• They have clear metrics to measure success.
• They do not have hard dependencies on other teams.

You should build those properties into new teams from the beginning and work hard to teach them into existing teams. The result will be an autonomous, fully capable teams that execute independently towards their goals.

What Good Looks Like

Organizations need to be comprised of agile, autonomous teams that can deliver with minimal coordination with other parts of the organization. Those teams must plan work, solve problems, make decisions, and review progress in service of a specific set of goals related to the products and services they own.

Required coordination destroys a team's ability to deliver. Coordination is expensive, and it gets more costly the further apart the things move. We define distance in organizational terms a team is close, across teams within the same organization is further apart, across teams in different organizations even further. A single individual doing something requires no coordination. They lose no time in communication, they don't have to wait for anyone, and there are no opportunities for misunderstanding. One step out from that is work that happens within a team.  That work goes from not needing coordination to needing to coordinate between individuals on the same team. The cost of that is still 10x the cost of doing it with a single individual. Even within a team, communication and collaboration come with a price.  As you add members to the team member, that price grows. At a certain point, the cost of communication and collaboration becomes more than the value added by including team members. That number is somewhere around eight people.

Once you start spreading work across multiple teams, your shared context for understanding diminishes even further. That cost of communication hits another 10x increment. The situation gets worse as you try to distribute work across teams in different organizations. At some point, you spend so much time in communication that you don't get anything done. To avoid this, structure teams so that they don't need to coordinate with other teams and organizations.

Coherent Management

To minimize the cost of coordination and the risk of miscommunication, we need to structure our teams in a way that reduces the need to communicate across context gaps and in a way that promotes the creation of shared context within a team, reducing friction and error. The type of team we aim to build is a cross-functional team, in which we assemble all the functional capabilities necessary to deliver our product. Those functional areas are Engineering, QA, Product, and Design. These functional verticals should roll up through a single business manager. Moving those functional verticals under a single manager aligns the team, enables the team to own the product thoroughly, and leads to better overall outcomes. The most well-known example of this model is an early-stage startup. In an early-stage startup, always have a single cross-functional team reporting up to the CEO. That tends to work very well for the delivery of a product. We are building an organizational structure that is many little startups aligned along with the same goals. With these goals in mind, we can define a set of properties of a successful team.

Teams that meet the above definition have the following properties:

• They are small, usually 4-8 people.
• They are cross-functional.
• They have a clear process.
• There are no silos
• They have clear ownership.
• The team balances work intentionally between Feature, Reinvestment, and Operational work.
• They have a managers who are accountable for the success of the team.
• They have clear metrics to measure success.
• They do not have hard dependencies on other teams.

These properties are necessary but not sufficient to create a capable team.  Most technology teams do not exhibit any of these properties. Individually, the members of the team are competent. However, the organization isn't structured to allow those people to work together effectively. Structure the organization to reduce

Reduce team size

There is a sweet spot for team size. That sweet spot is between four and eight members. You should often require that you rethink the team structure.  Some senior or staff roles may need to be hoisted higher in the organization, or the proportion of different skills rebalanced.

Think strategically about this. If your organization is expanding, you may need to grow your team slightly bigger than eight to have a more viable team size when you split it. Sometimes, you may create a team under the minimum size of four due to various organizational pressures. However, these should always be temporary states that exist in response to some external driver.

Make Teams Cross-Functional

As we talked about earlier, coordination adds cost, especially coordination across teams. That includes teams of different skill verticals. Do your designers report to a director of design. They are on a different team. Your product people report to a director of product, also a different team. The fact that they sit next to each other doesn't change that fact.

All the skill verticals needed to deliver a product need to be on the same team reporting to the same manager.

Clear Processes

The team must have a clear set of processes that help them manage the workflow flow and optimize delivery. The most common one at the moment is Scrum. That is the process that you are most likely to settle on. However, keep in mind that Scrum and Agile are not religions; they are a set of techniques that help teams deliver more efficiently and effectively. Once you are comfortable with your process and understand how it works and why it works, you can modify it to fit the company and culture better. Over time you build an effective process that is tailored specifically for your organization. Don't start with that, but keep it in mind as you implement Scrum.

The managers from the CTO down are accountable for how effective their teams are. How effective the teams are is a function of well their processes work and how well they are applied, among other things. The managers in the organization must drive the adoption of these processes and iterate on them. They are not working in a vacuum, and they must include the teams in defining and supporting the process, but in the end, the manager is accountable. The manager needs to understand and champion those processes, ensure that they are running well, and work for their intended goals. All of the Managers should 'live' in your roadmap tool.

Remove Silos

For this discussion, a Silo is an individual on the team who is the only person that can work on a particular piece of the software. Silos are an anti-pattern that kills any chance of having a reasonable delivery cadence. Too many organizations have a severe problem with silos. Due to micro-optimizations under deadline pressure, they end up with individuals owning a particular piece of software. You must change the mindset of the teams.

The mantra to have in mind here is: Teams own the software, individuals don't. Breaking the emotional attachment between an Engineer and the code they have written can be challenging. However, once those emotional ties have been broken, and the engineer is comfortable in the new mindset, they tend to stay broken. Expect to provide help and support to the engineers as they make this transition.

The way we do this is by enforcing one particular scrum principle. When an engineer finishes up a piece of work, that engineer picks up the next available piece of work, regardless of where in the system that is. Managers need to pay attention to what the engineers pick up. If they see an engineer prioritizing work in a particular area, that manager should encourage that engineer to pick up a different piece of work.

Balance Work Intentionally Between Feature, Reinvestment, and Operational Work

You must balance work between Features, Reinvestment, and Operational load. An optimal balance is 40% Features, 40% Reinvestment, and 20% Operational load. That balance will vary sprint by sprint, but they need to balance out over the long term.  That said, the team should review the distribution of work over these areas to make sure that they are correctly balancing the work over larger time-frames.

Features and Reinvestment must be aligned to the team's goals and roll up to larger initiatives. The team is responsible for collaboratively defining and managing those features.

Operational work also needs to be managed. Many organizations have a problem with prioritizing and triaging defects. The engineering team works on every defect as if it was a high priority defect. Not all faults are high-priority defects, and the team only has limited bandwidth to do both feature work and operational work. To effectively manage work, the team needs to triage and prioritize defects. Work on those defects that are high priority immediately. Schedule those defects that are a low priority as routine work.

Managers Are Accountable for the Success of the Team

The manager is the lynch-pin of a team. They are responsible for managing the day-to-day work, the team's scrum ceremonies, and growing the team's members. Every team should have a manager. The members of that team should report directly to that manager without dotted line reporting to other managers.

Clear Ownership

Clear ownership is the other half of the 'No Silos' rule. Individuals don't own software. Teams do. Those teams must have a strong sense of ownership for that software. Any individual on that team should be able and willing to work on any part of the software the team owns.

The team must understand which products and services that it owns. Define those products and services in a way that is accessible to the team. That allows the team to feel a sense of ownership and be held accountable for those systems.

It is always tempting to have the teams focus on different codebases depending on the organization's current needs, but this robs them of the engagement and sense of ownership the team needs to do their best work. It also makes it impossible for the teams to get the depth of knowledge they need about their systems.

Once ownership is defined, the team needs the autonomy to execute on that ownership. Assigning ownership can be a challenge in sizeable monolithic code bases. In those cases, it's useful to define areas of ownership in those codebases, and the teams collaborate in how they make underlying system changes. It's non-optimal but necessary at times.

Clear Metrics for Success

Teams should have metrics that define success. Those metrics serve as a gauge for how a team is doing. Use them as an indicator where Reinvestment needs to happen. Use them in concert with the KPIs that the team uses to measure success against quarterly objectives.

Keep in mind that metrics gauge the team's performance and should be used to improve that performance. When a metric is off, the team should decide what things need to change to improve those metrics. Then those changes should be planed as routine work and implemented. You should not use metrics as a reason to beat the team when they are off.

No Hard Dependencies on Other Teams

Avoid at all costs designing teams that have hard schedule dependencies on other teams. An excellent example of this is a Product team that depends on a release team to release their software or a DevOps team to provision infrastructure. These kinds of hard schedule dependency kill a team's ability to deliver.