TL;DR
Engineers waste 33% of their time (and $1.52 trillion annually) rebuilding solutions that already exist. The culprits? Not stubbornness, but hardwired psychological biases: Not Invented Here syndrome makes us reject external solutions, the IKEA effect makes us overvalue our own work by 63%, and Dunning-Kruger convinces us we understand problems we don’t. Research shows 84% of teams fall into this trap. The fix isn’t better engineers. It’s better systems: Architecture Decision Records that force justification, InnerSource practices that give teams ownership without reinvention, and platforms designed to reduce cognitive load instead of enforce compliance. Elite teams deploying multiple times per day don’t avoid customization. They make it intentional instead of reflexive.
Picture this. Your platform team just spent six months building the perfect authentication template. OAuth? Check. Session management? Sorted. Rate limiting? Built in. Audit logging? Already there. The docs are solid. The code has survived production across a dozen services. It’s battle-tested, ready to go, gift-wrapped with a bow.
Then a new team picks it up. They take one look and think, „We can do this better.“ Out goes the audit logging (who needs that anyway?). The session store gets replaced with their favorite tech. The rate limiter? Rewritten from scratch because reasons.
Three months pass. A security audit drops. Guess what they mandate? Audit logging. Compliance shows up next. They need rate limiting that matches the org standard. The team quietly reverts to the original template, having burned an entire quarter reinventing a wheel that was already spinning just fine. This happens everywhere. Platform teams build templates, shared libraries, standardized approaches. They document them, test them, polish them. Then consuming teams customize them into oblivion, waste months on reinventions, and eventually crawl back to the original. It’s one of the most persistent forms of waste in software development. And the wild part? Research tells us exactly why it happens and how to stop it.
The reasons go way deeper than stubbornness or bad communication. We’re talking fundamental human psychology, organizational trust issues, and cognitive biases that mess with even the smartest engineers. Understanding these forces is the first step to building teams that actually use shared work instead of reflexively rebuilding it. The psychology behind „we can do it better“
There’s actually a name for this in research circles: Not Invented Here syndrome. MIT researchers Ralph Katz and Thomas Allen nailed it back in 1982 [1]. They described it as „the tendency of a project group of stable composition to believe it possesses a monopoly of knowledge of its field, which leads it to reject new ideas from outsiders to the likely detriment of its performance.“
Katz and Allen studied 50 R&D groups and found something fascinating [1]. Team performance peaked around 1.5 to 4 years of working together. After 5 years? It dropped off a cliff. The teams got insular. They stopped talking to outsiders. They developed this tight internal identity and became convinced they knew better than everyone else. A later survey of 565 innovation projects found that only 16% escaped NIH syndrome. That means 84% of teams fall into this trap. It’s practically universal. Here’s how it works. When external knowledge looks a lot like what your team considers its specialty, accepting that knowledge feels like admitting you’re not as essential or skilled as you thought. Hussinger and Wastyn found in 2011 that the closer external knowledge matches internal expertise, the harder teams reject it [2].
This is why platform teams get the most pushback when they’ve built exactly what the consuming team needs. The template works perfectly? That’s proof the platform team is good at their job. Which threatens the consuming team’s sense of ownership. Ironic, right? The better the solution, the more likely it gets tossed aside. When effort creates irrational attachment
There’s another bias at play here, and it’s sneakier: the IKEA effect. Norton, Mochon, and Ariely documented it in 2012 [3]. The concept is simple. People overvalue things they build themselves compared to identical things someone else built.
They ran experiments with IKEA furniture, origami, and Lego sets. Builders bid 63% more for stuff they assembled versus the exact same thing assembled by someone else. Even better, people thought their janky origami looked as good as expert work. They genuinely believed others would agree. Spoiler: outside observers valued the amateur origami at less than a quarter of what the creators thought it was worth.
Norton’s team connected this directly to software: „The overvaluation that occurs as a result of the IKEA effect has implications for organizations more broadly, as a contributor to two key organizational pitfalls: sunk cost effects…and the ’not invented here‘ syndrome, in which managers refuse to use perfectly good ideas developed elsewhere in favor of their sometimes inferior internally-developed ideas.“ [3] The psychology behind this comes down to effort justification (Leon Festinger’s cognitive dissonance theory from 1957 [4]) and effectance, which is just a fancy word for the human need to feel competent. Finishing a task, even if it’s reinventing the wheel, gives you a hit of „I did that.“ It feels good.
The template in the repo? You didn’t build it. No dopamine hit. The custom implementation you spent three weeks on? That’s your baby. Your brain inflates its value to justify the time you sunk into it. Even if it’s objectively worse. The dangerous confidence of limited expertise
When engineers decide to rewrite a library or customize a template, they usually think they understand the problem well enough to improve it. This is where Dunning-Kruger kicks in. Kruger and Dunning published their famous 1999 paper showing that people with low ability at a task wildly overestimate their competence. Meanwhile, experts tend to underestimate theirs [5].
Here’s the kicker. „The skills that engender competence in a particular domain are often the same skills necessary to evaluate competence in that domain.“ [5] Translation: you need expertise to recognize expertise. If you don’t know much about authentication, you can’t accurately judge how much you don’t know about authentication. In software, this shows up constantly. A developer with limited auth experience looks at session management and thinks, „This is easy. Store a token. Check it on requests. Done.“ They can’t see the edge cases, the security holes, the operational nightmares the template already handles. The sophisticated rate limiting looks over-engineered because they don’t have the experience to understand what it’s solving.
Mohanani and colleagues mapped out 37 cognitive biases affecting software decisions in a 2020 study [6]. Anchoring bias hit particularly hard, with a Cohen’s d of 1.19. Once you decide „this template is too complicated“ or „we only need 20% of this,“ your brain filters everything else through that lens. New evidence? Doesn’t matter. You’re anchored. Planning for success while ignoring base rates
The planning fallacy is another killer. Kahneman and Tversky described it in 1979 [7]. It’s the tendency to underestimate time, costs, and risks while simultaneously overestimating benefits. Sound familiar?
Kahneman split planning into two views: inside and outside [8]. When you estimate how long your custom implementation will take, you’re using the inside view. You focus on your specific project, its unique features, and you imagine everything going perfectly. The outside view asks different questions. How long do custom implementations usually take? How often do they get abandoned for the original solution? Engineers almost never use the outside view. The inside view wins every time. Buehler, Griffin, and Ross ran a classic study in 1994 [9]. Psychology students estimated their thesis would take 33.9 days on average. Actual time? 55.5 days. Only 30% finished on time. When asked how long it would take „if everything went poorly,“ they said 48.6 days. Still under the actual average.
Software engineering research backs this up. Magne Jørgensen found something wild in 2010 [10]. More effort spent identifying risks led to more optimism, not less. Why? Illusion of control. By listing the risks, engineers felt like they’d handled them. Confidence went up even though the risks were still sitting there, waiting to bite. The staggering cost of reinventing wheels
These biases would be fun academic curiosities if they didn’t cost so much money. But they do. Technical debt, which includes all the unnecessary customization and divergence from standards, is one of the biggest drains on engineering productivity.
CISQ estimates technical debt costs U.S. companies around $1.52 trillion every year [11]. The average enterprise is carrying $3.61 million in tech debt right now. Stripe’s 2018 study found developers waste about 33% of their time on technical debt and maintenance instead of building new features [12]. One third of your engineering budget, gone. Sonar analyzed over 200 projects and calculated tech debt at $306,000 per year for one million lines of code [13]. That’s 5,500 developer hours on remediation instead of value. Over five years? $1.5 million and 27,500 hours. McKinsey found one large bank with 1,000+ systems generating over $2 billion in tech debt costs [14].
When teams customize templates or diverge from shared libraries, they create a special kind of hell. Now the org maintains multiple solutions to the same problem. Platform team patches a security hole in the original? The custom versions might get the fix. Or might not. New requirements drop (that audit logging you removed, that rate limiting compliance now demands)? Custom implementations need bespoke work. Teams using the standard get it automatically. The nine wastes of software development
Sedano, Ralph, and Péraire spent over two years at Pivotal, interviewing 33 engineers and analyzing 663 retrospection topics. They published nine categories of waste in software development at ICSE 2017 [15].
Several hit directly at unnecessary customization. Unnecessarily complex solutions: over-engineering and skipping code reuse when something already exists. Extraneous cognitive load: mental energy burned understanding and maintaining redundant systems. Knowledge loss: what happens when the one person who understood the custom implementation leaves. Rework: fixing or reverting work that should have been done right (or in this case, using the template from day one).
Their key finding: „Software development is a complex socio-technical activity that involves coordinating different disciplines and skill sets, it provides ample opportunities for waste to emerge. Waste is any activity that produces no value for the customer or user.“ [15] Custom implementations of solved problems are the poster child for this definition. The compounding problem of code duplication
Code duplication research shows how this gets worse over time. Kim’s clone genealogies study found 38% of duplicate code groups were consistently changed at least once [16]. Over a third of duplicated code needs synchronized maintenance.
Hotta’s team found that „the presence of duplicate code increased cost for modification, and programmers were not aware of the duplication, so that they sometimes overlooked code fragments that had to be modified simultaneously.“ [17] Developers don’t know the duplication exists, so they miss stuff.
It compounds. Duplicate methods get modified more often than unique ones, but they’re modified simultaneously less often because nobody realizes they’re duplicates. The platform team updates the original. The custom versions drift. Eventually the gap gets so wide that bringing them back together is a whole project. DORA’s research in Accelerate by Forsgren, Humble, and Kim gives us the strongest evidence that standardization and high performance go together [18]. Elite teams deploying multiple times per day with lead times under 26 hours and failure rates below 1% all have loosely coupled architectures. They deploy independently while building on shared foundations.
The 2021 DORA report found loosely coupled architecture is one of the strongest predictors of successful continuous delivery [19]. Elite teams meeting their reliability targets are three times more likely to have these architectures than low performers.
Here’s the critical bit: „Speed and stability are not tradeoffs. In fact, we see that the metrics are correlated for most teams. Top performers do well across all five metrics, and low performers do poorly.“ [18] You can’t achieve this when teams are constantly reinventing wheels. They’re too busy maintaining redundant systems. Why trust erodes between platform teams and their users
Knowing that customization is wasteful doesn’t explain why smart engineers keep doing it. The answer is trust. Or the lack of it. Trust dynamics between teams, organizational structures, psychological safety, and communication failures all play a role.
Amy Edmondson defined psychological safety back in 1999 as „a shared belief held by members of a team that the team is safe for interpersonal risk taking.“ [20] She studied 51 teams and found psychological safety enables learning behaviors: seeking feedback, sharing info, asking for help, talking about mistakes, experimenting. Teams without it avoid all of that. Why? Because „those in a position to initiate learning behavior may believe they are placing themselves at risk; for example, by admitting an error or asking for help, an individual may appear incompetent and thus suffer a blow to his or her image.“ [20]
This connects straight to template adoption. Using someone else’s solution means admitting they solved the problem better than you could. For engineers whose whole identity is wrapped up in being technically competent, that’s risky. Building a custom solution, even a wasteful one, preserves your sense of mastery. You don’t have to depend on anyone else’s work. What Google learned about effective teams
Google’s Project Aristotle spent two years studying 180 teams, running over 200 interviews and analyzing 250+ attributes [21]. The biggest finding? Psychological safety mattered more than anything else. Teams with high psychological safety had 19% higher productivity, 31% more innovation, and 27% lower turnover.
Want to know what didn’t matter? Colocation. Consensus-driven decisions. Individual performance. Seniority. None of it.
„What really mattered was less about who was on the team, and more about how the team worked together.“ [21] Trust dynamics determine whether teams can leverage each other’s work, not technical skill. When psychological safety is low, teams go it alone, even when collaboration would win. The distance matters paradox
ACM CSCW published research in 2022 that found something weird: „Despite exhibiting excellent remote collaboration, teams paradoxically struggled to collaborate across team boundaries.“ [23] Teams that nailed intra-team work often sucked at inter-team collaboration. Four things kept breaking: establishing common ground, collaboration readiness, tech readiness, and coupling of work.
The tension is real. „The collaboration technology and practices that help individual teams thrive (e.g., adopting customized collaboration software) can also prompt collaboration challenges in the inter-team layer, and conversely the technology and practices that facilitate inter-team collaboration can harm practices at the intra-team layer.“ [23] The same tools that make your team tight can make you insular. Katz and Allen saw this exact pattern in their NIH research.
A 2021 case study in Empirical Software Engineering confirmed that team size kills cross-team awareness. What helps? Interaction frequency and personal contact. When platform teams and consuming teams rarely talk directly, trust never forms. The trust equation in distributed knowledge
Research splits organizational trust into two types. Cognitive trust is based on capability: the other team’s knowledge, skills, competencies. Affective trust is based on emotional bonds and positive interactions. McAllister’s 1995 research showed you need both for cooperation [24].
Platform teams struggle with both. Cognitive trust requires consuming teams to see the platform team’s competence. But if you only interact through docs and async Slack messages, that demonstration never happens. Affective trust needs repeated positive interactions. But platform and consuming teams rarely talk face to face.
PMI’s research on knowledge sharing found barriers on both sides: lack of time, fear of losing status, belief that sharing knowledge reduces your value, fear of looking incompetent [25]. Platform teams hesitate to engage deeply. Consuming teams avoid asking questions. The result? Teams customize instead of talking to the people who built it. Concrete strategies for breaking the cycle
Research and practice show several ways to cut down on unnecessary customization. These work at different levels (validation, communication, documentation, culture) and they work best together.
Architecture Decision Records create accountability and context
Michael Nygard introduced Architecture Decision Records (ADRs) in 2011 [26]. ADRs capture the context, decision, and consequences of big architectural choices in a structured format. AWS, Google Cloud, and tons of other orgs have adopted them.
ADRs hit the customization problem two ways. First, they force you to say why you’re deviating. Writing „We will replace the standard authentication library because…“ means finishing that sentence with actual reasoning. A lot of unnecessary customizations die right there when you have to write them down.
Second, ADRs preserve the why behind templates and libraries. Nygard puts it: „The motivation behind previous decisions is visible for everyone, present and future. Nobody is left scratching their heads to understand, ‚What were they thinking?'“ [26] When you know the audit logging exists because of a compliance incident, you’re less likely to rip it out.
AWS reports teams spend 20-30% of their time coordinating with other teams. ADRs can cut that overhead. Google Cloud recommends them for tech debt prioritization and decision docs before deadlines.
The RFC (Request for Comments) process scales this up. Uber, Airbnb, Amazon, Booking.com, Spotify, LinkedIn all use RFCs or design docs for big decisions [27]. Gergely Orosz, who built Uber’s RFC process, says: „This process works and scales really well, from a handful of engineers to teams of thousands. It addresses not only issues on visibility or reducing tech/architecture debt, but also spreading knowledge and having engineers be more engaged day to day.“ InnerSource transforms platform teams into enablers
InnerSource, which is basically applying open-source principles inside your company, is one of the most effective ways to stop unnecessary customization. The PayPal case study from OSCON 2015 shows what’s possible [28].
PayPal’s Checkout Platform team had a problem. Regional teams kept submitting code that didn’t meet standards. The platform team burned two-thirds of their time rewriting submissions. Mandates didn’t help. More processes didn’t help. More meetings definitely didn’t help. So PayPal went InnerSource: created „trusted committer“ roles (about 10% of engineers), made all code reviews public, and required mature, respectful communication.
Six months later, the results were insane. Platform team time spent rewriting code: 0%, down from 67%. Time spent reviewing submissions: 10%. They got a 4x performance boost through major refactoring they hadn’t even planned. The mindset flipped from „blocking change“ to „mentoring and coaching.“ [28]
Cedric Williams, who led it, explained trusted committers: „They must have deep technical skills and know the codebase by heart, but they don’t have to be the best. They need to be coaches. Instead of saying ‚this code is unacceptable,‘ they need to say ‚here’s what I need you to do so that I can accept your code. Here’s why.'“ [28]
InnerSource fixes the trust problem head-on. When consuming teams can contribute to shared solutions instead of just using them, they get ownership without reinventing. When platform teams coach instead of reject, they build real relationships. Team Topologies provides structural solutions
Skelton and Pais’s Team Topologies framework from 2019 gives you structural ways to reduce customization [29]. It defines four team types (stream-aligned, platform, enabling, complicated-subsystem) and three interaction modes (collaboration, X-as-a-Service, facilitating).
Fowler nails the key insight: „The primary benefit of a platform is to reduce the cognitive load on stream-aligned teams. This insight has profound implications… Reducing client teams‘ cognitive load leads to different design decisions and product roadmap to platforms intended primarily for standardization or cost-reduction.“ [30]
This reframes what platform teams are for. Not building the „correct“ solution and forcing everyone to use it. Making stream-aligned teams more productive. If your template creates cognitive load because it’s hard to understand, poorly documented, or needs heavy customization for common cases, that’s your problem as a platform team, not theirs.
Team Topologies also introduces „Thinnest Viable Platform.“ [29] Build only what gives immediate value, then expand based on real needs. This stops the over-engineering that triggers NIH („we only need 20% of this“) while laying groundwork for future stuff.
The enabling team pattern handles knowledge transfer. Enabling teams „grow relevant skills inside other teams through coaching/facilitation“ with the goal of making them independent. No permanent dependencies. Work intensively with consuming teams, build their skills, then move on. Documentation must explain „why,“ not just „how“
Research consistently shows documentation quality matters for adoption. Plösch surveyed 88 practitioners on what makes good docs [31]. Top answers: accuracy, clarity, readability, structure, understandability. Bad docs kill software analyzability.
For templates and libraries, „why“ docs beat „how“ docs. Engineers can read code to see what something does. They can’t read code to understand why you made those design choices, what alternatives you considered, or what future requirements you’re anticipating.
Fowler emphasizes this: „Sharing useful and, above all, battle-tested code as libraries encourages other developers to solve similar problems in similar ways yet leaves the door open to picking a different approach if required.“ [32] „Battle-tested“ implies history. The problems the library hit and survived. Document that history so consuming teams understand the value.
Fowler also warns against premature standardization: „It is tempting to create a Foundation Platform, with all of the common visuals that will be needed across all applications. However, experience tells us that it’s difficult, if not impossible, to guess what the components‘ APIs should be before you have real-world usage of them… Allow the patterns to emerge naturally, and once the component’s API has become obvious, you can harvest the duplicate code into a shared library and be confident that you have something proven.“ [32]
Document the evolution, not just the current state. The patterns that emerged from real use. The customizations people tried and abandoned. The requirements that showed up after launch. Feedback loops close the learning cycle
DORA research shows feedback loops matter in high-performing orgs [18]. Gene Kim’s „Three Ways of DevOps“ puts fast, constant feedback as the Second Way, essential for continuous improvement [33]. Organizations with „generative“ cultures (Ron Westrum’s model) that openly share info get better delivery performance [34].
For templates and libraries, feedback needs to flow both ways. Platform teams need to hear about friction, missing features, doc gaps. Consuming teams need to know what’s on the roadmap (so they don’t rip out audit logging that’s about to become mandatory) and why decisions were made.
Research on retrospectives, including a 2018 Springer study „Learning in the Large,“ found short team-level retros mostly addressed team-level stuff and produced „single-loop learning“ (adjusting tactics within existing strategies) [36]. To get „double-loop learning“ (deeper org change that questions assumptions), you need inter-team retrospectives. Large projects benefit from retros that cross team boundaries, where patterns of unnecessary customization get spotted and fixed structurally.
Derby, Larsen, and Horowitz’s Agile Retrospectives sums it up: „Teams and organizations that learn rapidly deliver greater customer value faster and more reliably. Furthermore, those teams are more engaged, more productive, and more satisfied. The most effective way to enable teams to learn is by holding regular retrospectives.“ [35] Regular retros that examine customization decisions (what was customized, why, what happened) create organizational memory that stops repeated mistakes. Cultivating a „question first“ mindset
The strategies above give you structure and process. But lasting change needs culture shifts. Specifically, a „question first“ mindset where teams pause before customizing and ask if the change is actually necessary. Beyond „strong opinions, loosely held“
The phrase „strong opinions, loosely held“ (SOLH) is everywhere in engineering. Paul Saffo’s original idea was solid [37]: „Allow your intuition to guide you to a conclusion, no matter how imperfect. This is the ’strong opinion‘ part. Then, and this is the ‚weakly held‘ part, prove yourself wrong. Engage in creative doubt. Look for information that doesn’t fit or indicators pointing in an entirely different direction.“
In practice, SOLH mostly fails. Michael Natkin breaks down why [38]. SOLH shuts down discussion when loud, confident engineers state positions with certainty. It excludes people from underrepresented groups who might be less likely to assert strong positions. It creates anchoring bias where stated positions become hard to revise. And it has no feedback loop to tell whether the opinion was actually held loosely.
Brad Feld goes harder: „I’m not even sure that a ’strong opinion loosely held‘ qualifies as something useful… Basically, a SOLH is simply a hypothesis.“ [39]
This reframe matters for customization. Instead of „I think we should replace this library“ (strong opinion), start with „What would need to be true for replacing this library to be the right choice?“ (hypothesis). The hypothesis framing invites testing assumptions, creates space for disconfirming evidence, and makes reversing course feel less like failure. The power of asking „why was it built this way?“
Before customizing, ask questions about the existing solution. Why does this component exist in its current form? What requirements drove these choices? What alternatives got rejected? What future requirements is this anticipating? Consult ADRs, docs, and (critically) the people who built it. Those answers often kill the perceived need for customization.
This requires psychological safety. Asking „why was it built this way?“ can feel like admitting you don’t know something. In orgs where looking competent beats being effective, engineers skip this step and go straight to customizing. Leaders need to model curiosity, celebrating questions over confident assertions.
Kelsey Hightower warns against context-free „best practices“ in his PlatformCon talks [40]: „One question that most customers show up with is, ‚What are the best practices?‘ Not necessarily the best practices for me. They just want to know what everyone else is doing. I think that might be another anti-pattern in the mix, where you only care about what everyone else is doing and you don’t bring the necessary context for a good recommendation.“
Same thing applies internally. Templates and libraries embed the context they were created in. Before assuming your different context needs different solutions, verify that your context actually differs in ways that matter. Creating rituals that pause and reflect
Structure can reinforce questioning. Require a waiting period before approving customizations, even just 24-48 hours. That creates space for reflection and consultation. Mandate that customization proposals answer standard questions: What capability is missing? What did the platform team say when you asked? What’s the long-term maintenance plan? This forces systematic thinking.
Some orgs use „chaos monkey“ approaches for decisions. Randomly pick customization proposals for deep review. When any proposal might get scrutinized, teams put more effort into solid reasoning. The role of empathy in engineering collaboration
The technical and process stuff above handles systems and structure. But sustainable change needs real empathy between platform and consuming teams. Understanding that others have spent serious time thinking about the problems you’re hitting. Understanding that your situation is rarely as unique as it feels.
Understanding the platform team’s perspective
Platform teams face brutal tradeoffs. Build solutions general enough for multiple use cases but specific enough to be useful for each. Anticipate future requirements without over-engineering for stuff that might never happen. Maintain backward compatibility while evolving capabilities. Balance responsiveness to individual teams against the needs of everyone.
When consuming teams customize without talking to the platform team, they’re implicitly saying „we don’t value your work.“ When customizations create maintenance burden or security holes, platform teams deal with it. When teams revert to the original after their custom solution fails, platform teams help with the migration. Time that could have gone to improvements.
Camille Fournier, author of The Manager’s Path and an upcoming platform engineering book, puts it [41]: „One of the reasons that companies struggle with their platform teams is that the industry lacks an understanding of how these teams should be structured and managed in order to succeed.“ Consuming teams can help by engaging constructively. Report issues, suggest improvements through proper channels, recognize the constraints platform teams work under. Understanding the consuming team’s perspective
Platform teams also need to understand why consuming teams feel the urge to customize. Often, the template doesn’t quite fit the use case. The docs don’t explain why design decisions that seem wrong were made. The platform team is slow to respond or dismissive when you ask. The roadmap is opaque, so you can’t tell if needed capabilities are coming.
Charity Majors, co-author of Observability Engineering, says to treat platform consumers as customers [42]: „SLOs (Service Level Objectives) should be the entry point, not dashboards. SLOs are the APIs for engineering teams. SLOs provide a budget for teams to run chaos engineering experiments. SLOs are a hedge against micromanagement, because when teams meet their SLOs, the way they spend their time is not important.“
This works for internal platforms. When platform teams define clear service levels and measure themselves against meeting consumer needs, they create accountability that builds trust. When consuming teams see platform teams actually responding, they’re more likely to engage through proper channels instead of building around obstacles. Building bridges through collaboration
Team Topologies defines three interaction modes [29]. Collaboration (teams working closely for a set period) is explicitly designed for when standard X-as-a-Service breaks down. When a consuming team thinks they need major customization, a collaboration sprint with the platform team can figure out if the need is real (platform should improve) or perceived (better docs or education can fix it).
Kelsey Hightower talks about „serializing engineering culture.“ [40] Encoding org knowledge into platforms so new engineers can contribute immediately. Google’s monorepo does this: „Engineers just opened a browser, added code and reviews would start automatically.“ But this only works when it captures real best practices, not arbitrary decisions. Ongoing collaboration keeps platforms aligned with actual needs instead of calcifying around outdated assumptions.
Gene Kim’s „Third Way of DevOps“ is about „creating a culture that fosters continual experimentation (taking risks and learning from failure) and understanding that repetition and practice is the prerequisite to mastery.“ [33] This extends to platform adoption. When teams experiment with customizations, learn from failures, and share learnings, the org improves. The goal isn’t zero customization. It’s making sure customizations are intentional, considered, and add to collective knowledge. Conclusion: From reflexive rebuilding to intentional adoption
The pattern plays out everywhere. Teams get a template, think they know better, customize it, discover the original was right, and revert. Enormous waste. Research estimates 33% of developer time goes to technical debt [12]. Unnecessary customization is a big chunk of that. At scale, billions of dollars per year.
The psychological forces (NIH syndrome [1], IKEA effect [3], Dunning-Kruger [5], planning fallacy [7][8], optimism bias) are deeply human. Awareness alone won’t fix them. But you can manage them with structure. ADRs that make you articulate why you’re diverging [26]. InnerSource that gives consuming teams ownership in shared solutions [28]. Team Topologies that make platforms valuable instead of mandatory [29]. Docs that explain „why“ not just „how“ [31][32]. Feedback loops that surface customization patterns for org learning [35][36].
Culture matters just as much. Move from „strong opinions, loosely held“ to „hypotheses, rigorously examined“ [37][38][39]. Ask „why was it built this way?“ before customizing. Build empathy between platform and consuming teams so collaboration beats isolation.
The best orgs treat shared solutions as gifts, not constraints. They know the auth template embeds months of learning about edge cases, security holes, operational nightmares. They understand the rate limiter’s „unnecessary“ complexity handles failure modes they haven’t hit yet. They value collective engineering wisdom over the dopamine hit of building it themselves.
For engineering leaders: create structures that make intentional adoption the easiest path. Measure and address customization patterns. Model curiosity and humility that enables learning from others‘ work.
For individual contributors: approach shared solutions with real interest in understanding their design. Engage with platform teams as partners, not obstacles. Recognize your time is too valuable to spend rebuilding what already works.
The template exists because someone put real effort into solving your problem. Before you decide you can do it better, understand what they built and why. More often than not, they already thought of everything you’re considering. And a few things you haven’t imagined yet.
References
[1] Katz, R., & Allen, T. J. (1982). Investigating the Not Invented Here (NIH) syndrome: A look at the performance, tenure, and communication patterns of 50 R & D Project Groups. R&D Management, 12(1), 7-20.
[2] Hussinger, K., & Wastyn, A. (2011). In search for the Not-Invented-Here syndrome: The role of knowledge sources and firm success. R&D Management, 46(S1), 945-957.
[3] Norton, M. I., Mochon, D., & Ariely, D. (2012). The IKEA effect: When labor leads to love. Journal of Consumer Psychology, 22(3), 453-460.
[4] Festinger, L. (1957). A Theory of Cognitive Dissonance. Stanford University Press.
[5] Kruger, J., & Dunning, D. (1999). Unskilled and unaware of it: How difficulties in recognizing one’s own incompetence lead to inflated self-assessments. Journal of Personality and Social Psychology, 77(6), 1121-1134.
[6] Mohanani, R., Salman, I., Turhan, B., Rodriguez, P., & Ralph, P. (2020). Cognitive biases in software engineering: A systematic mapping study. IEEE Transactions on Software Engineering, 46(12), 1318-1339.
[7] Kahneman, D., & Tversky, A. (1979). Intuitive prediction: biases and corrective procedures. TIMS Studies in Management Science, 12, 313-327.
[8] Lovallo, D., & Kahneman, D. (2003). Delusions of success: How optimism undermines executives‘ decisions. Harvard Business Review, 81(7), 56-63.
[9] Buehler, R., Griffin, D., & Ross, M. (1994). Exploring the „planning fallacy“: Why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366-381.
[10] Jørgensen, M. (2010). Identification of more risks can lead to increased over-optimism of and over-confidence in software development effort estimates. Information and Software Technology, 52(5), 506-516.
[11] Consortium for Information & Software Quality (CISQ). (2022). The Cost of Poor Software Quality in the US: A 2022 Report.
[12] Stripe. (2018). The Developer Coefficient.
[13] Sonar. Software Quality as a Business Enabler. Retrieved from Sonar resources.
[14] McKinsey & Company. (2020). Tech debt: Reclaiming tech equity. McKinsey Digital.
[15] Sedano, T., Ralph, P., & Péraire, C. (2017). Software Development Waste. IEEE/ACM 39th International Conference on Software Engineering (ICSE), 130-140.
[16] Kim, M., Sazawal, V., Notkin, D., & Murphy, G. (2005). An empirical study of code clone genealogies. ACM SIGSOFT Software Engineering Notes, 30(5), 187-196.
[17] Hotta, K., Sano, Y., Higo, Y., & Kusumoto, S. (2012). Is duplicate code more frequently modified than non-duplicate code in software evolution? Advances in Software Engineering, 2012.
[18] Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press.
[19] DORA. (2021). Accelerate State of DevOps 2021.
[20] Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350-383.
[21] Google re:Work. Project Aristotle: Understand team effectiveness.
[22] Duhigg, C. (2016). What Google Learned From Its Quest to Build the Perfect Team. The New York Times Magazine.
[23] ACM CSCW. (2022). Research on inter-team collaboration challenges. ACM Conference on Computer-Supported Cooperative Work and Social Computing.
[24] McAllister, D. J. (1995). Affect- and cognition-based trust as foundations for interpersonal cooperation in organizations. Academy of Management Journal, 38(1), 24-59.
[25] Project Management Institute (PMI). Knowledge sharing barriers research.
[26] Nygard, M. (2011). Documenting Architecture Decisions. Cognitect Blog.
[27] Orosz, G. The Pragmatic Engineer. RFC and design document processes at tech companies.
[28] Williams, C. (2015). InnerSource as the anti-silo: How open source style has broken silos while strengthening systems at PayPal. OSCON 2015.
[29] Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
[30] Fowler, M. Team Topologies. martinfowler.com.
[31] Plösch, R., Gruber, H., Hentschel, A., Körner, C., Pomberger, G., Schiffer, S., Saft, M., & Storck, S. (2014). The EMISQ method and its tool support. Software Quality Journal, 22(1), 3-36.
[32] Fowler, M. Shared libraries and platform guidance. martinfowler.com.
[33] Kim, G. The Three Ways of DevOps. The Phoenix Project and DevOps Handbook.
[34] Westrum, R. (2004). A typology of organisational cultures. BMJ Quality & Safety, 13(suppl 2), ii22-ii27.
[35] Derby, E., Larsen, D., & Horowitz, J. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
[36] Springer. (2018). Learning in the Large: Inter-team retrospectives research study.
[37] Saffo, P. Strong opinions, loosely held. Institute for the Future.
[38] Natkin, M. Critique of „Strong Opinions, Loosely Held“. Glowforge blog.
[39] Feld, B. Strong Opinions Loosely Held. Feld Thoughts blog.
[40] Hightower, K. PlatformCon talks on context and best practices.
[41] Fournier, C. Platform engineering insights. Medium and The Manager’s Path.
[42] Majors, C. Platform teams as customer service. The Pragmatic Engineer and Observability Engineering.