Be Special Only Where It Matters

There is a peculiar kind of pride in an engineering organization that has built everything itself. Its own framework. Its own communications protocol. Its own development tools. Sometimes its own operating system. The implied argument is that owning more of the stack makes the organization more capable, more independent, and more valuable.

Sometimes it does. But every one of those decisions needs a better justification than “we can build it.”

My starting point is simple: be special only where it matters. Put serious engineering effort into the things that make a meaningful difference to the customer. Be demanding about the rest, but make originality earn its place.

A customer buying an engine controller might care about load acceptance, transient response, reliable starting, fault recovery, diagnostics, and the ability to keep the equipment running for years. Those are outcomes worth being exceptional at. The customer is unlikely to care that we invented a new configuration file format unless that invention actually improves one of those outcomes.

Consider a hypothetical development team with two competing uses for the same month of engineering time. It can characterize a difficult operating condition that produces unstable behavior, or it can replace a perfectly serviceable diagnostic interface with something developed entirely in-house. Both activities can produce impressive demonstrations. Only one may address the reason the customer hired the team.

I encountered a more consequential version of that decision while supporting the sustainment of an embedded control system. The following account comes from that work; identifying details are omitted and the technical description is generalized.

The system combined a supplier-developed real-time operating system with custom logic in an FPGA and a proprietary diagnostic toolchain. The processor already included dedicated timing hardware and analog-input multiplexing, yet the design implemented similar functions in the FPGA. That overlap did not prove that the native peripherals could satisfy every requirement of the custom implementation. It did make the choice an important engineering question: what requirement justified taking responsibility for an additional implementation, and what benefit did the customer receive in return?

The consequences were tangible. The custom timing function became a recurring source of intermittent behavior and troubleshooting over an extended period. Correct timing was a prerequisite for normal system operation, so this was an operational problem, not merely an inconvenient development tool. Meanwhile, diagnosing the system and interpreting its diagnostic files depended on supplier-specific software. The customer needed both a reliable controller and a practical means of understanding and maintaining it. The architecture made those needs harder to satisfy independently.

The difficulty became more apparent when the customer wanted to take on software sustainment internally. Useful application behavior was bound to an environment whose operating software, hardware interfaces, and diagnostic conventions all required specialized knowledge and tools. Retaining the application meant dealing with those dependencies as well. The cost of a custom platform did not end when the original development effort ended.

I regarded that result as a failure to spend engineering effort where it mattered most. The supplier's value in that engagement was its ability to deliver and integrate a dependable system. A private operating environment or diagnostic ecosystem needed to improve that result enough to justify its continuing burden. Originality alone supplied no such justification.

I can describe the dependencies I encountered and the sustainment problems I observed. Those observations do not establish the original decision-makers' motives, or prove that every alternative would have worked better. Deliberate commercial restriction, historical constraints, and poorly assessed engineering tradeoffs can produce similar dependencies. The customer still has to live with the consequences. We should be able to defend an architecture on performance, maintainability, and lifetime value without needing to settle an argument about anyone's intentions.

There are practical alternatives to making every part of the support environment unique. For example, ASAM's Open Diagnostic Data Exchange format describes diagnostic information in a form designed to be independent of a particular vendor, bus, or protocol. [1] Such a standard is an option to evaluate for a suitable system today, rather than proof that a particular historical design could have adopted it unchanged. It illustrates the choice: a supplier can compete on the quality of its implementation while giving the customer a documented basis for using other compatible tools. Actual independence still depends on the delivered data, implementation details, and permissions.

That is the decision I want us to make deliberately, while the alternatives are still available and their costs can be compared.

The difficulty is that custom infrastructure can feel productive long before its value has been established. There are design reviews, code commits, diagrams, and gratifying technical problems to solve. Meanwhile, understanding the actual application can be messy. It may require uncomfortable conversations about requirements, measurements that contradict the model, or an admission that we do not yet understand the failure.

Engineering effort is finite. Spending it on one problem means accepting that another problem will receive less attention. A clever implementation can still be a poor use of a capable engineer.

There is also an obligation hiding behind every custom component. Someone must explain it to the next person, diagnose its failures, maintain its tools, and decide what happens when its original assumptions stop being true. The first implementation is only the beginning of that responsibility. We should judge the decision with that responsibility included.

This is why I am skeptical of treating the amount of proprietary technology in a product as a measure of its quality. Proprietary technology can be excellent. It can also be an expensive collection of obligations that the company has mistaken for an advantage.

The argument for building something ourselves becomes stronger when we can identify the particular limitation we need to overcome. Perhaps an available component cannot meet a measured timing constraint. Perhaps the environmental requirements rule out the obvious choices. Perhaps a supplier’s support horizon is incompatible with the intended service life. Perhaps a new capability requires an approach that does not exist yet.

Those are engineering reasons. They deserve analysis, prototypes, measurements, and a decision. “Our product is unique” is much less useful. Almost every product is unique in some respect. The important question is which differences have consequences.

This discipline also applies to architecture. David Parnas’s 1972 paper on modular decomposition showed that the benefits of modularity depend on how responsibilities are divided. In his example, boundaries organized around decisions likely to change contained the effects of those changes more effectively than boundaries organized around processing steps. He also addressed implementation efficiency; a useful conceptual boundary did not automatically require a costly runtime mechanism. [2]

I take a broader lesson from that: an architectural decision should have a reason that survives contact with the actual system. A diagram full of neat boxes is not evidence that we have chosen useful boundaries. We need to explain what a boundary makes easier, what it makes harder, and why the trade is worthwhile in this application.

Nor does specialization require outsourcing everything outside a narrow definition of our business. Buying a component does not relieve us of the obligation to understand how it behaves in the system. A supplier can deliver a conforming part while the integrated product still fails its purpose. Someone must retain enough knowledge to ask difficult questions, inspect the evidence, and own the result.

There is a serious economic argument for doing more inside one organization. Ronald Coase’s The Nature of the Firm explains that using a market involves costs, including finding relevant information and negotiating transactions. Organizing work within a firm can avoid some of those costs, although internal organization has costs and limits of its own. [3]

That matters when people present vertical integration as inherently foolish. A closely coordinated hardware and software development effort may solve problems that would be painful to negotiate across several suppliers. A company may need direct control over manufacturing, calibration, or system integration to deliver a particular result. That can be a sound business and engineering decision.

But it remains a decision. The fact that coordination has a cost does not establish that owning everything is the cheapest or most capable answer. Internal teams can have incompatible incentives, poorly defined responsibilities, and slow handoffs too. Moving a boundary inside a company does not make the boundary disappear.

I would want the justification expressed in terms we can revisit: the performance we gain, the risks we reduce, the expertise we must maintain, the alternatives we considered, and the conditions that would make us choose differently. That last part matters. A decision that was sensible five years ago is allowed to become obsolete.

Open standards can help here because they give specialist organizations a common basis for working together. But a standard should still be selected for a purpose. An impressive acronym does not establish that the standard fits the application, that available implementations are adequate, or that the required expertise is available. Adopting an unnecessarily complicated standard can consume the same scarce attention as inventing an unnecessary proprietary solution.

The practical objective is to spend less effort rediscovering agreements that other competent people have already worked out, while retaining the freedom to improve the things that need improving. That requires judgment about both the standard and the product. It cannot be reduced to a rule that everything must be custom or everything must be purchased.

Specialization, understood this way, is demanding. It asks a company to say what it is actually good at and to invest deeply enough to make that statement credible. It also asks the company to recognize expertise elsewhere. That can be uncomfortable for organizations accustomed to equating control with competence.

For a small engineering business, I think the discipline is especially valuable. We cannot be exceptional at every layer of every technology we touch. We can become very good at understanding a particular class of systems, making sound tradeoffs, integrating the right capabilities, and producing evidence that the result works.

There is nothing ordinary about doing those things well. There is also no requirement that every line of code or every component in the product originate with us.

When I look at a proposed custom feature, I want to be able to point to the person it helps and explain how. I want a credible account of who will maintain it and what we are giving up to build it. If the answer is strong, let’s build it properly - anything worth doing is worth doing right. If the answer is mostly that we would enjoy having our own version, we have some harder thinking to do.

The customer’s difficult problem is still waiting for us.

Sources

1. ASAM, “ASAM MCD-2 D,” also known as Open Diagnostic Data Exchange or ODX. Official standard description, accessed September 29, 2026. The standard defines a diagnostic data model and description format intended to be independent of specific vendors, buses, and protocols. 2. David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM 15, no. 12 (1972): 1053–1058. Publication record; university-hosted text. See “The Criteria” and “Efficiency and Implementation.” 3. R. H. Coase, “The Nature of the Firm,” Economica 4, no. 16 (1937): 386–405. Publication record; university-hosted paper. See especially pp. 390–395.

The experience-based example is the author's account, with identifying details omitted and technical particulars generalized. It is separate from the publicly documented sources above and makes no quantified claim about costs or savings.