Collaboration Across Organization
For the past few months, I’ve been part of a few programs where another organization within the company wanted and needed to change our system to create a new expected output.
Generally aimed at growth or reducing churn meant tight timelines and expectations were high. The first time through this exercise, the different engineering folks discovered multiple things.
Not every team was ready to start receiving a new stream of work from a different team, from things like documentation, PR standards, unit tests to training the folks in the tech stack, and sharing context for design choices, as well as taking time to do code reviews or pairing sessions.
Lastly, the code this team wrote was still supported and maintained by the receiving teams, meaning that this group of people was never on-call for the code they added.
We have constant tension with this sort of collaboration I described, where the team actively working to introduce new behaviors is motivated by short-term decisions or taking shortcuts given the tight timelines to release.
The teams are focused on making it work and releasing it, while the receiving team has to focus their efforts on providing good enough guard rails for the system’s sustainability.
These programs have had varying degrees of success, given that collaboration hasn’t always been with the same teams, except for small groups that maintain fairly popular services in which the team can get flooded to the point of dedicating more time than expected to incoming changes.
What we’re working on now is designing a proper ingestion process, where there are more formal reviews and design meetings, and the work gets written into a program management software such that there’s an understanding of the scope, the required teams, and there’s a balance against plans, and sustainability of the system.
Ideally, a formalized diagram of the system should exist that provides the multiple contexts under which it operates. This way contributors are able to understand how the choice they want to make affects the existing system.
Providing enough context, guard rails, and adaptability of the software has become a priority that I think about whenever I work with the different teams at the organization.
That’s all for this week. I’m trying to make this practice more constant and sustainable on my part, so I’ll be aiming for a more constant stream of newsletter issues.