The great shift left - understanding the cognitive load of making single title engineering teams own everything

There is a great shift left movement in software engineering that is in some ways the natural outcome of the Agile movement.  Everyone wants to push more power and responsibility onto engineering teams removing roadblocks and shortening cycle time for making changes and creating products.  This increases the number of tasks and cognitive load on those teams as a tradeoff for shorter cycle times and other concerns.

The idea is that you push ownership of every facet of a product to the lowest level possible.  People often use Amazon AWS as an example of success in this area.  Originally shift-left was primarily an engineering function where you pushed all of the technical responsibilities to a single team.  The team creates better products because they own the entire lifecycle and any of the cycle times.  Organizations have eliminated adjunct positions creating a staff single developer type that owns the previous test, DevOps, CI/CD, data, and all development disciplines. There can be multiple skills or ranks but everyone is a developer.  This has been very successful for a set of scenarios.

Some organizations have taken the next step pushing semi-technical and non-technical roles onto the development machines.  Business and Technical analysts and other product or business-related positions are eliminated and replaced with additional engineers.

Doing Everything - All The Time

What exactly are we asking of the software or other engineers?  People talk about shift-left and collapsing the workflow but what type of engineers do you need?  How do we expect them to organize?

This chart tries to give a feel for the range of capabilities we expect from the engineering teams.  Engineering teams own these responsibilities and must have these skills and build tooling relating to the items in this diagram.

I'm happy to update or clarify this chart if people find errors or think of missing items. I suspect most of the feedback will be around missing responsibilities. 

Click on the diagram to see a larger view or scroll down

Bubbles are all sized the same for appearances and do not imply that the items are of similar effort and complexity!

Help me find the missing responsibilities. I'm open to suggestions.

Teams and Org Collapse

Shift-left means eliminating or reducing support teams.  Some of this is made easier by moving to the cloud and cloud automation because the cloud can make some skills less mandatory.  Companies see this type of team reassignment or elimination in these "move left" efforts.
Old TeamNew Team
Shared ServicesDevelopment

Roles Collapse

Shift left often means the elimination of a wide range of titles and specialist positions. They are replaced with the general role of developer.   Here we have an example list of roles that could be collapsed into the Developer role on Delivery or Stream-aligned teams. This is the purist view of how this works.
Old RoleNew Owner
User ExperienceDeveloper
Business AnalystDeveloper
System AnalystDeveloper
Data DesignerDeveloper
Infrastructure TriageDeveloper
Tier 1 SupportDeveloper

The reality is that there will need to be specialization because everyone can't be great at everything.  Each of these roles may now be represented by a primary and a secondary but they cease to exist as a standalone.  Teams have to operate this way because the average SCRUM or other team is probably 8 people or less. You can't afford to have half the team as specialists that don't contribute to the main line code base or development process.



This group represents the work done to synchronize inside the value stream or with a program or product workstream of multiple teams and with the work done to support a manageable and clear backlog.

This is explained in the video. Additional content may be added here in the future.

Outward Facing

This group contains the tasks done to synchronize with external teams. This is the entire lifecycle from initiating conversations, reaching interaction agreements, negotiating interactions, and troubleshooting difficulties in the development and integration process.

This is explained in the video. Additional content may be added here in the future.


This group contains the tasks and responsibilities required to define the work required, reach decisions, capture non-functional requirements, and define how systems our subsystems will be built. This is the high-value part of the technical process that must be done well to build a robust system that meets regulatory requirements and protects the customer and enterprise.

This is explained in the video.  Additional content may be added here in the future.


This section contains the skills or work areas when actually building software. The testing here is the most inside the development portion that is tightly integrated with the development process.  Some things here are actual tasks.  Others are required skills that may stretch a person's capabilities or may not be possible for one person.
This is explained in the video.  Additional content may be added here in the future.


This section describes a lot of the quality assurance tasks and capabilities that the development team owns when in a You Build it You Own Everything About pattern. The engineering team owns all testing and all quality analysis functions.  Most of these tasks must happen every sprint in a truly agile / SAFe shop.
Click on the image to expand

This is explained in the video.  Additional content may be added here in the future.

Operational Excellence

This area is a bit of a dumping group of the skills and tasks required to create a maintainable and supportable system where the company knows what is actually happening.  They don't feel related but they can all impact operational excellence.
Click here to expand

This is explained in the video.  Additional content may be added here in the future.

Less than Excellent

The flip side of operational excellence is the problem resolution, triage, and fixing processes and responsibilities.  These are in some ways all after-the-fact actions taken to remedy problems that got through quality or where other systems caught issues or requirements weren't known.

Things like "fail forward" overlap this area and others above.

This is explained in the video.  Additional content may be added here in the future.

Continuous Everything and Everything as Code

This area has been a major focus of agile and the drive for automation.  Teams and companies can only move faster if they can reduce cycle time and increase reliability in the assembly, test, and deployment functions.  Teams now own these tasks as the staff in supporting roles is reduced.
Click to expand

This is explained in the video.  Additional content may be added here in the future.

Compliance Governance Security

Software and technical products must meet internal and regulatory guidelines.  The development team must implement those guidelines and policies in order to create a secure and correct system.  Some of these boxes need to be re-labeled but they give a general idea of the scope.

This is explained in the video.  Additional content may be added here in the future.


This area represents the general overhead of being an employee and all that entails.  It represents some percentage of time that does not directly apply to business or technical deliverables.

This is explained in the video.  Additional content may be added here in the future.


to be added

Revision History

Created 2023 01


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs