We want to maximize the impact of our work, right? Help all the teams, not just ours. Widely applied processes, reusable code.
Watch out: imposing reuse invites regret and resentment.
Reuse is coupling
In code: this one time, the lead devs at my small company made a utility library, full of little array and string manipulation functions. They encouraged everyone to include that library and use the functions.
Using the library was not great, because we didn’t know it, and it was harder to look through than google. Upgrading it was a nightmare.
Every team used the functions in different ways. To get one updated function, we had to accept all the updates, and hope they didn’t break us. I resented it.
Whenever the lead devs learned something and changed a function, the impacts were unpredictable. Regret!
Consistency is coupling
The other day, my team made a little internal web site. Three adjacent teams liked it. “Maybe we should all have one,” they said.
One level up, this led to ideas like: there should be One Place where everyone can go. With consistent design. Let’s design something and then put everyone’s content under that.
No! We are four teams in one department, but our internal audiences (customers) are different. And we are different, and our content is different. This is not a place for a framework. That framework restrains us, as we each try to fulfill different purposes. Regret!
Waiting for any decision that affects four teams, before we can do something in our one team, is a dependency and a handoff. I resent that.
Leverage goes both ways
When a small change has a wider impact, that’s leverage. A big push from a small push.
In these cases, the leverage didn’t make the big push easier — it made the small push harder!
If tweaking my site means changing four sites, it’s not free to tweak it. If improving a utility function might break other teams, it is not safe to improve it.
Instead of widening the use of our learning, we’ve constricted learning.
Legibility is only for you
There is one sneaky benefit that makes this pain hard to see.
Spreading that library around the company made the code clearer to the lead devs (because they wrote it).
Condensing four teams into a consistent web site design makes it prettier for the leadership of our department (because they’re the only audience for the collective teams).
This is legibility: they can look from the top and survey their domain and understand it.
Don’t be that person, that architect who values consistency from their perspective. Don’t put your aesthetics above the effectiveness of the people doing the work and the value to customers. Don’t mistake legibility for leverage.