When I started working in IT in 2000, I believed that technical excellence was the primary determinant of project success. I had spent years developing deep technical knowledge — systems architecture, database design, application development, network infrastructure — and I applied that knowledge with the confidence of someone who had not yet encountered the full complexity of organizational reality. The lessons that followed over the next twenty-five years did not invalidate technical excellence. They taught me that it was necessary but insufficient, and that the factors I had underweighted — organizational dynamics, change management, stakeholder alignment, and the sheer difficulty of getting people to change how they work — were the factors that most consistently determined outcomes.
Technology Problems Are Almost Always People Problems
The most important lesson I learned, and learned repeatedly before it became instinctive, is that technology problems are almost always people problems wearing a technology disguise. A system that does not get used is not a technology failure — it is an adoption failure. A project that fails to deliver its intended benefits is not usually a technical failure — it is a requirements failure, or a change management failure, or a governance failure. An integration that produces inconsistent data is not just a technical problem — it is a data ownership problem, a process handoff problem, or a business rule definition problem that the technology has made visible.
Speed Is a Risk, Not a Feature
The organizations that wanted to move fastest were almost never the ones that delivered the most value. Projects executed at the pace the technology allowed, without the time required for proper change management, stakeholder alignment, and user preparation, consistently produced systems that were technically delivered and operationally rejected. The discipline of appropriate pace — fast enough to maintain momentum and stakeholder confidence, but slow enough to do the organizational work that makes adoption possible — is a discipline that takes years to develop and that I would not have believed necessary in my first decade.
Simplicity Is Always Harder Than Complexity
The more technically capable I became, the more I was tempted to solve problems with sophisticated solutions. The more experienced I became, the more I valued simple solutions — ones that the organization could understand, maintain, and evolve without specialized knowledge. The simplest solution that meets the business requirement is almost always the right one, and arriving at it requires more discipline, more understanding of the real requirement, and more confidence in the face of pressure to build something impressive than complexity does. Complexity is the default. Simplicity is the achievement.