Stacking bricks vs. designing the architecture

The reality of stepping away from the keyboard and the trap of custom engineering

Ask an engineer to solve a technical problem, and a beautiful, custom-made solution is designed right away. I rolled into the profession and landed in that seat myself, so I know how addictive that is. Technology is tangible: you solve a puzzle and it works instantly. Strategy and overarching architecture, on the other hand, can feel very elusive, and the results often take much longer.

Stepping away from the keyboard and no longer laying the bricks yourself is therefore a mental process. The pitfall is that, as engineers, we sometimes stand there working incredibly hard to masonry a beautiful little shed, without asking ourselves whether that shed is actually functional for the organization at that location. I notice this in myself too; when a project becomes complex, I prefer to dive back into the code myself for a bit. In my spare time I still do, but on the work floor, the focus must be on the long term.

The 'Pico Bello Inc.' method

With this method, the operational mindset wins over the strategic. A project is rushed or an update needs to go live immediately, leading external engineers to make quick, manual ad-hoc adjustments outside of the official deployment pipelines. It’s the engineering equivalent of quickly rigging a drainpipe with some duct tape and sealant. It works perfectly that specific afternoon, so the business is happy at that moment. Until three months later, when the sealant degrades, the basement floods, and the engineer in question has already moved on to the next gig. No one remembers how the drain was built, documentation is non-existent, and the organization is left to clean up the mess. This kind of manual customization and undocumented self-building are the ultimate long-term enemies of a stable platform.

The rule of thumb: give custom builds an expiration date

Sometimes building it yourself is simply unavoidable, for instance, when you need to innovate rapidly or when a standard market solution just doesn't exist yet. But to prevent those ad-hoc solutions from quietly turning into permanent, unmanageable systems, I maintain a strict rule of thumb: every custom-build decision must have a hard, documented expiration date for re-evaluation right from day one. Naturally, this causes some initial resistance among engineers because they pour a lot of time and pride into their own code, and an evaluation can feel like an attack on their craftsmanship. But this isn't about the quality of the code; it is purely about long-term maintainability. By enforcing a hard evaluation date, you prevent temporary fixes from quietly becoming the new, rattling standard, and you force the team to keep a sharp eye on what the organization truly needs.