5 ms·

Sometimes in software it's a problem that once a solution is encoded in software by an external party, innovation stops. People inside the company with domain

Sometimes in software it's a problem that once a solution is encoded in software by an external party, innovation stops. People inside the company with domain knowledge and who work with the tool daily cannot contribute anymore.

danielmarkbruce 3y ago
This is insightful. Software is forcing a sub-optimal process which cannot be improved onto a company.
- le-mark 3y ago
  This basically the idea around Paul Grahams “Beating the averages” essay which is about 23 years old now.
  - danielmarkbruce 3y ago
    I don't see that. Seems like different issues.
DrScientist 3y ago
Indeed. This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. This leads to the 'computer says no' scenario - where people who used to be empowered to fix something can no longer do so because the software doesn't support the operations. There is also another problem - often during the implementation of the software solution - the administrator type people tend to pile on lots of requirements for recording stuff that was never previously recorded because the metrics might be useful and the new systems creates the opportunity to capture the data. This creates extra busy work at best - classic example is timesheets - most data entry into company timesheets ( unless you are the sort of company that charges by the hour ) - is a work of fiction. Even worse the 'data' gives upper management the feeling that they can make decisions on the data without talking to those middle managers who actually know what's going up. As a result it leads to poor decision making and an increasing breakdown of trust. It's amazing how much money senior management will spend on an IT system, a sink costs into data entry, in order to avoid a 5 minute conversation with somebody.
- DrScientist 3y ago
  Or to shorten the above - realising any IT system is a hybrid of it's users and the system, and it's critical to understand what people do best and make sure that's incorporated into the hybrid. Too often, the focus is on what computers do best only.
- Terretta 3y ago
  > This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. On the contrary, generally tools such as Workday support a generally ideal workflow, but buyers spend years "integrating" aka devolving that workflow to mimic the manual toil of before the tool, including often unnecessary exceptions and variations. The end result is often strictly worse, as the flow did not improve and now there are even more human (error prone) steps and more technical parts to break.
  - DrScientist 3y ago
    I'm not suggesting that you should build a tool that deals with all the exceptions and variations in the tool - that would be madness. I'm suggesting the process overall needs to be able to deal with these exceptions and variations - and it's people who are best at dealing with these fairly ( say in a Workday HR context ). What you often see is the implementation of an idealised process in the tool, with no way to deal with exceptions - which leads to 'computer says no' scenarios. Everybody knows what the right thing to do is - conceptually it's simple - but nobody seems to know how to make it happen.
    - Terretta 3y ago
      FWIW, the tool itself could almost always handle a convenient flow, and exceptions. At least, that's true of Workday, and most other SaaS I've helped enterprises install. People don't want that. They need a new tool because the old one generates nothing but complaints, then they want the new tool to do exactly what they used to do. So it too generates nothing but complaints, after the pain of transition. But what's a SaaS to do, refuse the revenue and share multiple? Right.
Jtsummers 3y ago
Ossification. The same thing happens with laws and regulations. It moves the knowledge and activity from one of expertise and judgement to a ruleset. Changing a ruleset is hard because you have to play within the bounds of the other rules (which may include rules for changing rules). The expertise in the ruleset also falls away over time as people become increasingly reliant on the software system. Eventually the software becomes the definition of the rules, and any changes to the rules have to be changes that someone today can figure out how to implement. If they can't implement it, the rules can't change. Then you get a big-bang rewrite because everyone is frustrated (or they move to SAP, and are frustrated for other reasons). The rewrite neglects a bunch of edge cases already accounted for in the old system, it takes a decade to finally retire the old system (hopefully), and then in another decade they repeat the process because the expertise is, again, lost.

danielmarkbruce 3y ago

This is insightful. Software is forcing a sub-optimal process which cannot be improved onto a company.

le-mark 3y ago
This basically the idea around Paul Grahams “Beating the averages” essay which is about 23 years old now.
- danielmarkbruce 3y ago
  I don't see that. Seems like different issues.

DrScientist 3y ago

Indeed. This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. This leads to the 'computer says no' scenario - where people who used to be empowered to fix something can no longer do so because the software doesn't support the operations. There is also another problem - often during the implementation of the software solution - the administrator type people tend to pile on lots of requirements for recording stuff that was never previously recorded because the metrics might be useful and the new systems creates the opportunity to capture the data. This creates extra busy work at best - classic example is timesheets - most data entry into company timesheets ( unless you are the sort of company that charges by the hour ) - is a work of fiction. Even worse the 'data' gives upper management the feeling that they can make decisions on the data without talking to those middle managers who actually know what's going up. As a result it leads to poor decision making and an increasing breakdown of trust. It's amazing how much money senior management will spend on an IT system, a sink costs into data entry, in order to avoid a 5 minute conversation with somebody.

DrScientist 3y ago
Or to shorten the above - realising any IT system is a hybrid of it's users and the system, and it's critical to understand what people do best and make sure that's incorporated into the hybrid. Too often, the focus is on what computers do best only.
Terretta 3y ago
> This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. On the contrary, generally tools such as Workday support a generally ideal workflow, but buyers spend years "integrating" aka devolving that workflow to mimic the manual toil of before the tool, including often unnecessary exceptions and variations. The end result is often strictly worse, as the flow did not improve and now there are even more human (error prone) steps and more technical parts to break.
- DrScientist 3y ago
  I'm not suggesting that you should build a tool that deals with all the exceptions and variations in the tool - that would be madness. I'm suggesting the process overall needs to be able to deal with these exceptions and variations - and it's people who are best at dealing with these fairly ( say in a Workday HR context ). What you often see is the implementation of an idealised process in the tool, with no way to deal with exceptions - which leads to 'computer says no' scenarios. Everybody knows what the right thing to do is - conceptually it's simple - but nobody seems to know how to make it happen.
  - Terretta 3y ago
    FWIW, the tool itself could almost always handle a convenient flow, and exceptions. At least, that's true of Workday, and most other SaaS I've helped enterprises install. People don't want that. They need a new tool because the old one generates nothing but complaints, then they want the new tool to do exactly what they used to do. So it too generates nothing but complaints, after the pain of transition. But what's a SaaS to do, refuse the revenue and share multiple? Right.

Jtsummers 3y ago

Ossification. The same thing happens with laws and regulations. It moves the knowledge and activity from one of expertise and judgement to a ruleset. Changing a ruleset is hard because you have to play within the bounds of the other rules (which may include rules for changing rules). The expertise in the ruleset also falls away over time as people become increasingly reliant on the software system. Eventually the software becomes the definition of the rules, and any changes to the rules have to be changes that someone today can figure out how to implement. If they can't implement it, the rules can't change. Then you get a big-bang rewrite because everyone is frustrated (or they move to SAP, and are frustrated for other reasons). The rewrite neglects a bunch of edge cases already accounted for in the old system, it takes a decade to finally retire the old system (hopefully), and then in another decade they repeat the process because the expertise is, again, lost.