Total Engineering: Break Down Silos and Drive Better Customer Outcomes
By now you’ve probably heard us talk about the importance of Balanced Teams in software development. Made up of product design, product management, and software engineering, Balanced Teams ship products as a highly collaborative, cohesive unit. Each discipline does not operate as a silo and simply hand off work to the other functions, but instead stays tightly aligned with other departments throughout the software development process.
It is equally important to operate as a Balanced Team within each discipline. When it comes to software engineering in particular, developers should minimize silos between development and operations and own their own code throughout the entire software development lifecycle (SDLC). Enter the concept of “Total Engineering.” In this blog post, we’ll break down what it means and how you can begin to implement Total Engineering practices at your organization to tap into the superpower of engineers owning user outcomes.
Total Football, Meet Total Engineering
If you’re a Ted Lasso fan, you’re likely familiar with the term “Total Football.” Total Football was famously implemented by Johan Cruyff, one of the most influential European footballers. When Cruyff played for Ajax in the late 1960s and early ‘70s, together with his coach Rinus Michels, he honed the total football tactic. It centers around the ideas of utilization of space and fluidity of position. In other words, no player has a fixed position and each should be technically sound no matter where they are on the pitch. This helps teams be able to spread out and pass quickly when attacking, and make the pitch small when defending. Total Football requires a great deal of physical fitness, broad skill sets, and excellent team cohesion.
Similar to Total Football, Total Engineering sets the expectation that there are no walls between engineering groups. Every engineer must have tools in their toolkit to own code throughout the entire SDLC, from building, to releasing, to measuring high-quality code. This includes:
Planning
Feature & System Design
Implementation
Testing
Integration & Deploy
Maintenance
Monitoring & Alerting
The Benefits of Total Engineering
The ultimate benefit of Total Engineering is that it minimizes silos between development and developer operations, which leads to better user outcomes. User outcomes are your customers’ measures of success, and are the reasons your users are seeking out, using, and recommending your products and services (Jeff Gothelf).
When engineers have empathy for their users and a better understanding of their pain points, they can apply that thinking throughout the SDLC and drive better technical implementations. Testing is carried out by people with an intimate understanding of risks. Alerts are triaged quickly to the teams that wrote the code, and those teams are motivated to build with high quality to avoid the negative user impact of a production outage. Production stability and quick incident response lead to high trust with customers.
Is Total Engineering Right for Your Organization?
Take a moment to reflect on your organization and how your engineering department is currently structured. Most often, we see the following organizational silos:
Quality Assurance (QA) Team - A big, growing QA org is almost always an anti-pattern. Writing large automated test suites outside of the development process leads to catching bugs late in the SDLC, decreasing developer ownership of software quality (user outcomes), and siloing development and operations. Also, when a QA team writes E2E (end to end) tests, they aren’t refactored as new features are developed, which decreases confidence in the tests’ effectiveness.
Infrastructure/Release Team - Siloed release teams manage physical or cloud servers running application code. This removes application developers from the monitoring and altering related to their production code. If development teams don’t run and support their own production code, they may not be incentivized to take extra care in ensuring the application is reliable and easily observable.
Front-End Team - Engineers that work on the user-facing side of the application and are focused on things like functionality, layout, and speed. Keeping this function siloed could cause a lack of understanding of technical options to bring new backend functionality to market.
Back-End Team - Engineers that focus on the structure, system, data, and logic of the application. It is mission critical that application data and architecture properly reflect the product domain. Siloed back-end teams run the risk of under- or over-engineering solutions in ways that limit scalability, or bring software to market slower than necessary.
Besides breaking down silos, there are other use cases for implementing Total Engineering. Consider the following scenarios:
Scenario 1You’re a 60-person startup and engineering makes up half of your headcount
Your engineering team has doubled in size over the past year, and while you’re increasingly becoming more mature, you need to get beyond the “move fast and break stuff” pattern
You’re in a growth but also scale mode, where you want to get more sophisticated about your infrastructure and want engineers to maintain a stable production system
Scenario 2You’re a big, 500-person organization, but it takes forever for engineering to release code
Your team structure (siloed, highly specialized engineering teams) creates friction, resulting in slow release cycles
Your teams may also be organized by sub-sections of an application, which is especially common of organizations that need to modernize
How to Implement Total Engineering
Total Engineering affects every aspect of an engineering organization: team charters, performance management, metrics of success, etc. As such, Total Engineering must start with organizational leaders actively supporting and pushing for cross-discipline organization and development. By codifying Total Engineering, you set the expectation that there are no walls between engineering groups. It is expected that every engineer either has the tools in their toolkit to own code throughout the entire SDLC, or is willing to develop those tools.
Once the decision is made to adopt Total Engineering, the pathways to begin organizational transformation become clear. Some relevant questions to ask as you begin your implementation journey:
Are technical teams aligned to technical systems (i.e., database team) or aligned to user outcomes (i.e., ability to pay for products quickly and efficiently)? Total Engineering teams are most effectively aligned to user outcomes rather than technical domains.
Do technical teams have the skills to independently deliver solutions from inception to production? Total Engineering teams need the breadth of skills required to drive software all the way into their users’ hands in production (or a confidence and willingness to build those skills).
Are accountability structures properly aligned with the goals of Total Engineering? When a team owns the quality of their solution, the performance of their solution, and the speed of delivering their solution to users, everyone wins.
The goal of Total Engineering is to create as much interconnection between teams as possible, while allowing people to focus and specialize where they see fit. Similar to Total Football, Total Engineering requires engineers with diverse skill sets and a high degree of flexibility.
Every organization has to start somewhere, and as you’re ramping up your strategy, start with a more senior profile in each domain (front-end, back-end, etc.). That engineer is responsible for training green developers and teaching them best practices when it comes to planning, testing, maintenance, and so forth. Over time, you’ll grow a team of mature, highly experienced engineers that can move freely between domains based on need or career interests.
Conclusion
When you implement Total Engineering, you develop stronger engineers, knowledge silos are broken down (pretty much eliminated), and bottlenecks between groups (such as between QA and development) no longer exist.
If you’re ready to start practicing Total Engineering at your organization but you’re not sure where to start, reach out to Crafted and we’d be happy to show you how! We’ve helped build and scale engineering teams at companies of all shapes and sizes, from growth stage to startup to enterprise. Not only will we help you break down silos across engineering, but we’ll share best practices from our seasoned team of experts and help you ship high-value products fast by leveraging Balanced Teams.
