No Shortcuts Building Systems

Business managers will often encourage and pressure techs to finish a process as soon as possible. Often, that means cutting features, tests, documentation, and best practices that would delay rollout of a solution. The principle is that getting things done is more important and you were asked to make things happen fast. You do what you are told or what is expected.

Then one day, others look at what you did and criticize it. They criticize the lack of documentation, best practices, and implementation that, despite working as business managers wanted when they wanted, is not in the conventional form others expect, understand from industry trade journals, etc. These others may have even looked the other way for the success and sake of said business managers. Yet, their objections eventually become more noticeable.

Building a reliable, efficient system on time and on budget seems ideal. You get the job done and the business manager is happy. In terms of practical decision-making, it appears you did the right thing. You found yourself catering to the anxiety of the business manager to aleviate that anxiety by finishing a solution to their deadlines. Their angst at the prospect of failure to deliver was top of mind. You solve that problem and the business challenge had been met and has passed.

You did good. Except, you didn’t, because once criticism comes in, you are subtley disowned. You did good in the externally facing business situation, but you did wrong in the eyes of other technical reviewers well after the fact. I’ve seen such situations play out in which you got used but after enough internal social pressure or well-placed comment of dissension from those in who they trust more, the business managers who praise you in some situations, actually can’t wait to get as far away from your solutions as humanly imaginable.

What is the lesson?

That is the important point. Yes, these are all to common matters of human interaction, but they are understandable. That is the way it is sometimes. You help fix a messed up technical situation, but you are nonetheless sidelined. What is the lesson?

The lesson is in multiple parts.

  1. Do practical things in the beginning.
  2. Do not keep feeding others a steady diet of easy, quick fix solutions.
  3. Always work to shift to a more traditional technology delivery approach. You will encounter resistance but it is better to suffer for standards than to walk the shaky road of the alternative.
  4. On most things giving in to peer pressure is usually a better path to a more stable situation.
  5. Politics does exist in technology, it is not a purely merit based field.
  6. Slowing down is usually a better choice as you end up satisfying the preferences of more people which then equalizes out angst in initial preference of urgency.
  7. Upfront urgency can undermine you long-term so slow down and architect instead.