In the fast-paced world of software development, execution is everything. It’s not just about writing code; it’s about forming effective teams, collaborating across departments, focusing on outcomes, and managing technical debt. Let’s dive into these crucial aspects of engineering execution.

The Art of Forming Teams and Structures

When it comes to team formation, the old adage rings true: “Adding manpower to a late software project makes it later,” as famously stated in Brooks’ Law. This counterintuitive principle reminds us that team dynamics are complex and that simply adding more people doesn’t necessarily speed things up.

Understanding the stages of team formation is crucial. The Forming/Storming/Norming/Performing model, developed by Bruce Tuckman, provides a useful framework. In my experience, the Forming and Storming stages usually take a minimum of 2-3 sprints. If you’re struggling with these initial stages, consider reducing your sprint cadence to give the team a short reflection period on their working process to drive process change faster.

Here are some key principles for effective team structure:

Longevity should be a priority when structuring your engineering teams. Teams should be viewed as long-term investments rather than temporary assemblies. Even when headcount calculations don’t align perfectly, resist the urge to disband established teams. The relationships, shared knowledge, and mutual understanding that develop over time are invaluable assets that can’t be easily replicated. A team that has worked together for an extended period will often outperform a newly formed team, even if the latter looks better on paper.

Independence is another crucial factor in team effectiveness. Strive to create teams that possess all the skills necessary to execute their projects without constant handoffs to other teams. This autonomy not only boosts efficiency by reducing communication overhead and wait times but also increases accountability. When a team has end-to-end ownership of a project or feature, they’re more likely to take pride in their work and ensure its success.

Lastly, system ownership plays a vital role in team engagement and performance. In my experience, teams should have clear ownership over specific systems or components within your technology stack. This ownership fosters a deep understanding of the system and a sense of responsibility for its performance and evolution. Conversely, teams without any system ownership often struggle to appreciate impact of the technical debt they introduce and may lose respect for the value of the systems they interact with. By giving teams ownership, you’re not just assigning responsibility; you’re teaching a team about how to responsibly manage technical debt, as they are ultimately going to be then one’s responsible for it in their own system.

The Diplomacy of Inter-Team Collaboration

Working with other teams is an essential skill in any large organization, and it requires a strategic approach rooted in understanding human behavior and organizational dynamics. One crucial concept to keep in mind is what I like to call “Game Theory in Action.” When seeking collaboration with other teams, always consider the question, “What’s in it for me?” from their perspective. It’s a natural human tendency for individuals and groups to act in their own interest, and engineering teams are no exception. By anticipating this mindset, you can proactively address the needs and motivations of other teams, making collaboration more likely and more fruitful. This doesn’t mean being manipulative; rather, it’s about finding genuine win-win scenarios that benefit all parties involved.

Another key aspect of successful inter-team collaboration is the cultivation of informal networks within your organization. As a leader, one of your roles is to help your team build what I call an “irregular social network” that extends beyond the formal organizational structure. Encourage your team members to connect with colleagues from other departments, attend cross-functional meetings or events, and engage in casual conversations with people outside their immediate circle. These informal connections can be invaluable for smooth collaboration and problem-solving. They create channels for quick information exchange, foster mutual understanding, and often lead to creative solutions that might not emerge through formal channels alone. By building these networks, your team will be better positioned to know more about what’s going on within the org, and share more in common solutions to problems, in small organizations this isn’t as important as in large ones.

Shifting Focus: From Output to Outcome

It’s easy to get caught up in metrics like story points, sprint completion rates, or hours logged. However, these are merely measures of output, not outcome. Your true measure of success should be the business value your team delivers.

I once had a conversation with one of my engineers about changing the way the calculate carrier over work, I told him a half done story is “not done” and should count to zero for sprint completion, ultimately making their completion rate lower and closer to actual “completion”, his response was “But my points!”, he was fixated on his story points being his sole measure of success and was ignoring the actual value the team was delivering to the business.

Keep your engineers connected to the value they’re creating. Don’t let product management focus solely on “feature” or “milestone” success without tying it to measurable business value. If you do, you risk falling into the trap of DDD (Deadline Driven Development).

Remember Dan Pink’s insights on motivation: autonomy, mastery, and purpose are key drivers. By connecting your team’s work to real business outcomes, you’re providing that crucial sense of purpose.

Dan Pink, what motivates people

The Balancing Act of Technical Debt Management

Managing technical debt is a critical part of long-term success in software engineering, and it requires a strategic approach. One principle I’ve found effective is what I call the “30% Rule.” This involves allocating about 30% of your team’s time for technical improvements. While it might seem like a significant investment, especially when faced with pressing feature demands, this dedication to ongoing improvement pays substantial dividends in the long run. It helps prevent the accumulation of technical debt that can slow down development and increase the risk of system failures.

Why 30%? I asked Yaron Zeidman this once, who taught me this, and his response was, “Joel, I’ve worked in companies where we tried 20%, and we found that we weren’t able to keep on top of debt and technical improvements we needed, and i worked in companies where we tried 40%, and we found we weren’t able to execute on product enough, so 30% seems to be the happy middle ground.”.

Time-boxing is another powerful technique for addressing technical debt. One approach I’ve seen work well is the use of “Mobathons” – intensive periods focused solely on tackling technical debt or improvements. See this post about them.

Another instance, I once worked with a team that implemented a “60% leap sprint,” where the majority of a sprint was dedicated to making significant progress on technical debt, and every other sprint was 100% product work. These focused efforts can create momentum and visible progress, boosting team morale and improving system health.

If you try to do every sprint exactly 70/30 split, it almost never works out well.

One of the most important principles in managing technical debt is to finish what you start. It’s all too easy to let the tail end of technical migrations drag on for years, but this approach can be costly. The longer legacy systems remain in place, the more their costs grow, and the more significant their impact becomes. By seeing migrations through to completion, you can fully realize the benefits of your work and avoid the compounding costs of maintaining legacy systems.

When it comes to system design and development, thinking small can yield big benefits. Building small, modular systems allows for incremental improvement and quicker realization of value, for example framework upgrades such as reactjs or other frameworks, need to be done at system level, for a single large system it becomes an all in effort, if you have 10 smaller systems you can do one and measure the value in an increment, validate assumptions, to help you re-prioritize before continuing. This approach not only makes it easier to manage and update your systems but also allows for more frequent deliveries of value to your users and engineers.

While technical debt may seem like a purely engineering concern, it’s crucial to include product management in these discussions. Getting buy-in from product managers on your technical work can be tremendously beneficial. Not only can they help you ask the right questions about the business impact of technical decisions, but they can also become powerful allies in advocating for necessary technical work.

Finally, don’t hesitate to escalate when necessary. If technical debt is severely impacting your team’s ability to deliver, it’s time to have a serious conversation with product management and leadership. Work together to pitch for more headcount or resources. Remember, addressing technical debt isn’t just about engineering preferences – it’s about maintaining the health and efficiency of the systems that drive your business.

Conclusion

Effective execution in engineering teams is a multifaceted challenge. It requires thoughtful team formation, skilled inter-team collaboration, a focus on meaningful outcomes, and diligent technical debt management. By mastering these areas, you can create a high-performing engineering organization that consistently delivers value.

Remember, the goal isn’t just to write code or complete sprints. It’s to create systems and products that drive real business value. Keep this north star in mind, and you’ll be well on your way to engineering excellence.