Held on 26 January 2023

Feature Teams and Handoff Hell

This is an exec member exclusive video.

If your software developers keep saying "I'm waiting for the mobile team" and their co-ordination plans make every bug sound like building the Taj Mahal, you've missed a trick.

Us engineers like to draw nice rigid boxes, with each element of our architecture cleanly responsible for one thing and one thing only. But our customers' minds and their demands are never so neat and regimented. The problems they want us to solve, the ones that make us stand out from competitors, are messy real-world tangles, expressed with confusing sketches of screens but requiring major changes throughout the business logic and the storage schema and the data warehouse.

The traditional division of engineering teams into "front end" and "back end" and other groupings by type of code fits these convoluted customer problems woefully badly, with a single conceptual change broken up into multiple pieces that require delicate co-ordination and delay progress as the right hand waits for the left and vice versa.

Instead, a simple structure called a "feature team" is simultaneously cross-functional, independent, and customer-driven; the feature team can attack any request at any point in your software stack and follow it all the way to release, without waiting for anyone else to "enable" them or build the API they need. And if demand requires, you can even start building a change with one team and finish it with another. It's not the path of least resistance—some engineers and product folk may need convincing to give it a try—but in most cases, the flexibility and customer focus is worth the effort to set it up.

Join me on this free Zoom call for executive members, where we'll cover:

The horrors of the "Spotify model", a dangerous brew of matrix management and functional division that gives you the worst of both worlds.
How to nurture, hire, and grow the "full-stack developers" who can meet customer needs wherever they are (the foes of "demarcation" in all its pernicious forms).
Ways to optimise for flexibility, without limiting an engineer or a team to any particular language, technology, or product.