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: