Sharing technical debt
March 9, 2020
Is there a word for "technical debt" but for when you're transitioning from a one-person workflow to a communal one?— Christina K. (@_christinaLK) March 9, 2020
Building collaborative teams that work on technical problems is much like moving in with a roommate or two. All of your norms for how you’ve worked/lived on your own are up for scrutiny. This is a deeply uncomfortable feeling for many and feels tantamount to having your bedroom ransacked and looked through. Why do we do this? Is it purely economic, we can live more cheaply in community, is it just part of being social? As we transition from a single-person technical project to a team effort, we encounter many of the same emotions and feelings.
Our personal practices are just that, personal, our community practices can often be quite different, and how we make the transition between them can be challenging. At home, if you live with others, what is your mental model for the acceptability of leaving a dirty dish in the sink, or on a technical project, a new feature undocumented? Are there clearly defined roles and expectations on the team around these practices?
Extending the roommate analogy, we’re pretty good as humans at trying to set collective expectations and practices when we live in community. Our yearning for social bonds often allows us to power through the unease toward a place where we accept the benefits even in light of the challenges. In my house we have roles and chores and a shared agreement on the divisions of labor across the family. We sometimes switch up these roles and help each other out, but we’ve built expectations and agreements on cooking, cleaning, setting/clearing the table, and the ever dreaded taking out the trash and recycling. Building a technical team can and should have some similar norm-forming activities where shared expectations are conveyed.
Established projects have the benefit of established practice for new people to see. This isn’t much different than walking into a new job and watching how people work and emulating that to “fit-in”. When we put together a technical team, what we allow, accept, discourage and encourage really do matter. I think one of the challenges on technical teams is that these things are hard to name and point out, and we don’t always bring as much intentionality to them as we could. As Christina’s tweet above points out, we literally don’t have names for these things. Not having names makes it very hard to talk about them.
In the absence of names, maybe we can use this analogy to help out. Or perhaps we can borrow a name “shacking up”, “moving in together”, “cohabitating”. How do you handle the norm setting of team formation on technical projects you’ve created and led?comments powered by Disqus