Balancing feature development with stewardship

Software development organisations are increasingly based around the model of the cross-functional product development team - small teams of 3-12 people from varying disciplines given the autonomy and responsibility to deliver a whole product or sub-product across the full stack. Any organisation larger than a small startup will probably have more than one of these teams.

This model has given rise to questions of co-ordination, tooling, process and practice. While we like to talk of these teams as being fully autonomous, in reality this isn’t often the case.

How do we take advantage of learning, tools, practices and improvements across teams? Should practice be proscribed, recommended, suggested or completely autonomous? If features are handed down to ‘delivery teams’ by outside decision-makers, should development practices also be enforced in a similar way? If we’re determined to allow full autonomy, why shouldn’t individual teams choose their won tech stack and coding standards?

These are the kinds of question I asked myself when I first became a cross-team technology lead. We had split the growing product development organisation into multiple ‘streams’ to allow for parallel feature development. But the product was still enshrined in a single monolithic code base.

Up until then, life had been relatively straightforward as a tech lead. I had a team, we made decisions together. I guided those decisions as best I could and made sure we had either consensus or acceptance from everyone.

But a cross-team technology lead (‘chapter lead’, ‘architect’, ‘practice lead’, ‘head of X’ etc) suddenly has a different model to work with.

While each team has its own backlog of work, if they’re all tenants in the same code base, alignment in some working practices is vital. Splitting into two or more teams can exacerbate existing sources of waste in the development cycle: dependency clashes, release delays, code review disagreements, performance degradations, mounting tech debt.

This is why no team in a multi-team, single product organisation can ever spend 100% of their time on delivering their own product backlog. Each team must spend time on being good tenants and stewards of the wider system. This goes beyond an occasional chapter meeting. The wider discipline chapter should engage in cross-team collaboration, peer reviews, architectural decision-making, demos, group education and training events, conference attendance, etc, etc.

Your first job as a leader working across teams is to make sure these things happen, and to secure a the time for developers to focus on them. Nobody should be 100% allocated to feature development work.

How much time do developers spend on cross-team work? Is this officially recognised and planned for or does it happen ‘off the record’?

All the best,

– Jim