I work at a company where we have built much of our own e-commerce platform from the ground up. We have a growing number of teams who effectively operate as stream-aligned teams, based on functional areas (Growing x capability, improving customer retention, etc etc). We have 10-15 teams containing a Product owner, delivery manager, business analyst, software dev in test, and engineers to give an idea for the size of the engineering department.
Our estate is made up of a number of large services built by the teams to meet the needs of the business. We have a target architecture within the business, however, the teams are given a lot of autonomy as to how they would like to work within this architecture and which tools they want to use. This works really effectively in the majority of cases – bar one area.
Our front-end platform, which is a mono-repo React application, is a large and growing project that houses the business’s front-end website. This project is contributed to by a number of different stream-aligned teams, who may not be working even within the same functional area. An example being one team working on my account feature, whilst others work on an improved search capability.
The project is version controlled via GIT and has a working pipeline with volatile environments for feature branches to allow for testing. Our teams all operate using either scrum or kanban and we do our best to invest in agile practices.
The issue we are having is this project does not have a clear owner, and is rapidly growing in complexity and diverging in standards of code, approach to e2e testing, etc. This is having an impact on our ability to release frequently and with confidence, as we are now frequently having issues.
I think Conway’s law is playing a large part in this, but it would be really interesting to see how others have managed this problem (open-source projects could be a good inspiration for a model we could use potentially).
I’d appreciate any suggestions for patterns or practices we can implement to better manage this repo. The engineering department has grown quite rapidly over the last two years, so some mistakes have been made along the way and I’m keen to address them.
Thanks for reading my question!
2
Stewardship
A steward is responsible for managing a common resource, be that: land, a rare resource, or your git repository.
They are responsible for managing the conflicting forces that afflict any shared/critical area, ensuring:
- that posterity has its voice (the future people),
- that chores are undertaken (like removing garbage),
- that maintenance is performed (because broken stuff isn’t useful),
- that squabbles and serious issues are adjudicated and decided on (because there is nothing like politics aka decision hell to bog a project down)
- that massive infrastructure is built (no one individual can build an airport, but everyone benefits from its existence)
In fact every git repo should have a steward.
Who is the Steward?
Most repositories implicitly have a steward – the team that works on that code base. And for small teams this works well enough. People work well in small teams/families ~12 individuals. There is usually enough bandwidth available to sort most stuff out then and there.
But what if you have a large team? < 250 individuals (which is the magic number for most villages without mayors). Generally there is someone: an architect, a senior dev, a manager. That someone is respected, and considered fair, and capable by the other team members. Sufficiently enough that they will be approached for guidance on big changes, and be asked to weigh in on disputes between two or more devs.
What if no one has stepped forth? Then you need to officially anoite someone as the steward of that repository.
But what if you have many teams working in the same repository? Time for a tough decision:
- Get each team to forward a steward to partake in a steward council. That council is responsible for that repo.
- Create a new team to be the exclusive stewards of that code base, and they are responsible for veting contributions.
- Break up that repository. Split it into smaller components and give each team their relevant component. Have a single repo serving as the platform to which the other components plugin and have a team responsible for that.
Chances are you will need to deploy all three strategies as you move toward whatever shape of code base/architecture is desired.
1