There are many paths to the center in both life and software engineering:
Engineering First Organizations: where engineering trumps everything else. Many implementations of the same thing scattered about; they fall out of sync with one another almost immediately. Systems get rebuilt until the gap in feature parity is too high, then abstraction layers are piled on top. Engineers love metawork, or the engineering work that is supposed to make other engineering work easier, faster, more secure. Midcareer engineers aspire to deploy features, senior engineers aspire to deploy massive frameworks. Look for problems associated with unnecessary complexity. Good news: the practices one must take on to survive complex systems are good practices regardless. Bad news: beautiful tech is unrelated to profitable tech. Complexity should be growing to support business growth, not the other way around.
Engineering Reports To Product: Engineering and Product have fundamentally different goals. When one reports up to the other the parent group just ends up suffocating the subgroup. Engineering wins by producing beautiful and scalable systems, in pursuing that they sometimes build too complex too quickly. Product, on the other hand, wins by putting new stuff in front of customers as often as possible. Cut corners start off small and compound over time. Ask yourself: when a prototype or MVP becomes an actual product, how do people know? The answer to that question will tell you a lot about what kinds of technical debt to look for. The irony of the Product First team is that the race to ship as many features as often as possible typically slows feature development down to a crawl over time.
Engineering Reports To Security: Security teams tend to stop development work. Perfect security does not exist. Every security professional I’ve worked with has understood that (save for some government CISOs who were really lawyers). But being in charge, means being accountable for failure which naturally increases risk aversion. Technology built by organizations with security above engineering tends to be frozen in time. New features don’t get shipped, but sometimes upgrades don’t get shipped either.
Flat Organizations: Fortunately for us, the realities of flat organizations are pushing them out of favor and lively conversations about engineering leadership as a craft are taking over. Flat organizations are a nice idea, but they just don’t reflect how people behave. Conway’s Law runs amok in flat organizations. Because communication pathways grow up around personal relationships rather than chains of command, you often see problems in the protocols and data contracts that govern the specific subsystems. Conway’s Law runs amok in flat organizations. Because communication pathways grow up around personal relationships rather than chains of command, you often see problems in the protocols and data contracts that govern the specific subsystems. There may be duplicate components, or extra layers of complexity being used to patch an organizational silo. Data may go from one schema, to another schema, back to the first schema. The internal logic of the architecture can be difficult to see or explain. As people leave, no one knows who the work should be transitioned over to … or who determines who the work is transitioned over to.
How bad this get depends on how large the organization is and how flat is it. Organizations that are a collection of small teams can and do run high quality technology, but the overhead on individuals to be proactive in their communication is high and burns people out over time — especially software engineers. This shouldn’t come as a surprise, because this kind of people work is literally why managers exist. If you don’t hire managers the need for that work doesn’t go away, it’s just handled with work arounds.
If you want to find problems on systems built by these organizations the easiest way to do it is by asking yourself who isn’t talking to whom and look in places where what those siloed teams are building need to talk to one another.
Systems Out of Balance: If you’re clever you probably spotted it on your own: in each example the tech debt produced pulls the organization further away from what it’s trying to accomplish by taking on that debt:
As the saying goes "all things in moderation." The best organizations at managing technical debt tend to be the ones that have a thoughtful process in place to adjudicate competing incentives. Everyone has to have a pathway to win. Engineering needs Product to be successful in order to safely grow their beautiful systems. Product needs Engineering to win in order to maintain agility in the market. Security needs people to listen to them, but also needs mere mortals to reign in their paranoia.
Although we’re more accustomed to legacy projects coming from large organizations, all large organizations start off as small organizations first. If the organization is too small for a structure (or even worse has given in to the delusions around “flat” organizations) you can still predict the set of problems by looking at who’s on top. What is the background of the CEO? If they have a free hour… are they pushing code or making sales calls?
Last modified 16 December 2024