Sorry, Not Sorry

Progress without pain is a reasonable expectation.

​At a previous employer, my colleague in software product management had a mantra, “never apologize for making progress.”  This simple axiom was applied whenever we, as a software vendor, had to impose upon the customer base to accept changes, sometimes painful, if the reasons were good.  Some changes were mandated by our own partners – the OS or database versions went obsolete.  Some were mandated by us, as we repaired defects, or revamped approaches to help our customers get more value from our products.  In all cases, the combination of the technology at the time plus the mission-critical nature of that software, all but guaranteed some customers would push back on accepting the changes.  “Never apologize for making progress,” Tom would say.  “We can’t stop the industry from advancing the products we rely on, and we can’t improve anyone’s experience with our own products unless we are allowed to make changes.”

​Tom was right, of course.  The technology industry will never stop moving, nor even slow down.  Very few software applications are ever “done," and all rely on platform layers and industry standards that are part of the larger, living ecosystem.
 
The sentiment also encourages companies to act with conviction and courage, even faced with an unpleasant message.  Tom wasn’t telling anyone to be brash or obnoxious.  If certain updates are both inevitable and painful, the best way to approach is with honesty and determination.
 
However, the word that still bothers me is, “apologize.”  Upon reflection, if there is even a debate as to whether or not something deserves an apology, at the very least, someone is feeling some pain.  You can debate how “real” it is, how “severe” it is, or even who is at “fault,” but someone, somewhere, found something painful.  As the software / technology industry at large, if the general understanding of making improvements is accompanied by pain, that’s on us.
 
IT departments often find themselves on the narrow bridge between technology providers and technology consumers.  On one side of the bridge, technology providers are continuously pushing change, as described above.  They have no motivation to ever slow down.  On the other side, consumers have a dichotomous desire for both stability and improvement.  Whether external customers or the internal workforce, technology consumers want everything they find personally beneficial without disruption, while somehow seeing improvements elsewhere.  When an improvement in one area carries the cost of a temporary outage, or a disruption in a previously loved feature, IT is generally left holding the bag.  Worse, when the disruption yields no visible improvements for the consumer (EG, an OS upgrade), consumers are simply strapped with inexplicable inconvenience, and are left wondering why such things take priority over their own desired improvements.
 
As technology providers, we at LogistiVIEW both feel for our beleaguered IT brethren while we champion the technology consumers in the hands-on workforce.  We embed this ideology into our solution in several ways:

• Our platform allows separation of the human experience from all back-end systems.  Configured workflows implement the most desired processes, combining instruction and data capture ergonomically and intuitively.  If the back-end business systems are upgraded, modified, or changed out entirely, the human experience can remain untouched.  While the IT work is still required, the larger number of employees, the hands-on workforce, can avoid disruption.
• If certain process requirements only impact a small part of the population, or a small percentage of iterations, the workflow configuration can reflect that.  Whether it's increased instruction for beginners or special procedures for different customers, products or vendors, the workflow delivers only what is valuable to each individual.
• Cloud deployments shift the burden of technology upgrades and downtime to us, not the IT departments.  We are highly motivated to get these done correctly and quickly, and are the most familiar with the details of the change.
• We avoid custom code like the plague.  Every time custom code is introduced into a situation, years of potential logjam ensue.  We would rather spend the money making our core offering more configurable than writing one-off custom code which burdens all parties for the life of the system.

 
In brief, we are part of the fast moving world of technology providers, and we will not resist the flow of progress.  What we will strive for, however, is a world where progress isn’t associated with pain, and upgrades mean never having to say you’re sorry.