5 ms·

People forget that tech is able to automate workflows. You don’t often yield success when you attempt to automate and invent the workflows in parallel.

spywaregorilla 5y ago
I would say the opposite is true. Dying companies are stuck in their own routines because they're trying to automate their poorly designed processes that require humans at multiple steps. Smart companies are designing newer, better processes that are enabled by tech. Starting from scratch can be a huge advantage.
- javajosh 5y ago
  This is a statement I would have agreed with wholeheartedly 20 years ago, and that I disagree with wholeheartedly now.
  - spywaregorilla 5y ago
    I'd be curious to learn why. I've seen the pain of companies tricked into thinking robotic process automation to do their horrendous excel workflows is a good idea. I've seen the benefit of a decent python data engineer with a small AWS budget. The techier folks definitely have a different set of problems but the speed at which hings get done is night and day. Companies with old school work patterns (which, in my personal experience, means dusty old banks) are terminally entrenched in their ways.
    - mattcwilson 5y ago
      I think you’re both right. Taking some hopelessly byzantine, spreadsheet-driven process and “automating” it by building a Rube Goldberg scripting framework around it is the kind of totally stupid automation that doesn’t work. Actually getting down to surface level and understanding fundamentally what each of those humans is accomplishing via those spreadsheets, extracting that all the way back out to a domain model and process flow diagram, and then selectively replacing process steps, whole cloth, with tech designed to be an actual subservice with SLA targets, is the right way to do it. Throwing the spreadsheets and/or humans out altogether and starting “from scratch” is so exceedingly and needlessly risky from an information loss and hubris point that, well, good luck, but you’re nearly certain to fail.
- caseysoftware 5y ago
  Personally, I would treat the GP's mindset of "inventing workflows" differently than your mindset of redesigning at "poorly designed processes". Yes, a poorly designed process sucks but it works at some level. That means the rough flow of it is figured out. Yes, there are exceptions and complications and all kinds of odd things but it's fundamentally different. It's not "from scratch" as you're taking an existing working-but-broken process where you know the input, know the output, and rethinking everything in between. In an "inventing" scenario, you have what you think should be the input, a notion of what the output should be, and you're trying to build towards that notion.. without the validation that you're thinking of it correctly. The first is a harder social problem (aka getting people to change) while the second is a harder technical problem.
  - skohan 5y ago
    Ultimately you have to build within your sphere of competence. If you have a well-established but inefficient manual process, it may sometimes be the case that burning it down and replacing it with a tech-driven approach might be the best way forward. But if you are trying to solve a novel problem, and the proposed solution involves "ML will magically predict the future", you'd better have a very good idea of exactly how the problems will be solved, or else you're probably better off starting with good old-fashioned human intelligence.
- staticautomatic 5y ago
  It’s more complex than this in practice because in a large organization you have a significant change management component to every process change, whereas automation of an existing process immediately frees up bandwidth even if the process isn’t great. I interview global executives for a living; I hear this every day and I fully believe it.
- rrrrrrrrrrrryan 5y ago
  Ideally, you want to understand the whole process from beginning to end, including all the complex edge cases, before trying to automate it, then automate the whole shebang in one giant undertaking. You need a tremendous amount of high-level buy-in to pull this off, as people will have to wait and suffer with the old process until you're completely done building the new one. What often ends up happening is a large manual processes is automated bit by bit, and you end up with the situation you describe: a poorly designed manual process painstakingly replicated in code. Full automation is often never actually achieved here. The absolute worst thing to do, though, is to begin automating the thing without fully understanding it. It's putting rocket boosters on your self-driving car without first understanding the rules of the road.
deleted 5y ago
[deleted]
RyanDagg 5y ago
This is a critical concept that appears to be poorly understood in at least the web development circles I run in. It reminds me of one of my favorite Bill Gates quotes: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency."

spywaregorilla 5y ago

I would say the opposite is true. Dying companies are stuck in their own routines because they're trying to automate their poorly designed processes that require humans at multiple steps. Smart companies are designing newer, better processes that are enabled by tech. Starting from scratch can be a huge advantage.

javajosh 5y ago
This is a statement I would have agreed with wholeheartedly 20 years ago, and that I disagree with wholeheartedly now.
- spywaregorilla 5y ago
  I'd be curious to learn why. I've seen the pain of companies tricked into thinking robotic process automation to do their horrendous excel workflows is a good idea. I've seen the benefit of a decent python data engineer with a small AWS budget. The techier folks definitely have a different set of problems but the speed at which hings get done is night and day. Companies with old school work patterns (which, in my personal experience, means dusty old banks) are terminally entrenched in their ways.
  - mattcwilson 5y ago
    I think you’re both right. Taking some hopelessly byzantine, spreadsheet-driven process and “automating” it by building a Rube Goldberg scripting framework around it is the kind of totally stupid automation that doesn’t work. Actually getting down to surface level and understanding fundamentally what each of those humans is accomplishing via those spreadsheets, extracting that all the way back out to a domain model and process flow diagram, and then selectively replacing process steps, whole cloth, with tech designed to be an actual subservice with SLA targets, is the right way to do it. Throwing the spreadsheets and/or humans out altogether and starting “from scratch” is so exceedingly and needlessly risky from an information loss and hubris point that, well, good luck, but you’re nearly certain to fail.
caseysoftware 5y ago
Personally, I would treat the GP's mindset of "inventing workflows" differently than your mindset of redesigning at "poorly designed processes". Yes, a poorly designed process sucks but it works at some level. That means the rough flow of it is figured out. Yes, there are exceptions and complications and all kinds of odd things but it's fundamentally different. It's not "from scratch" as you're taking an existing working-but-broken process where you know the input, know the output, and rethinking everything in between. In an "inventing" scenario, you have what you think should be the input, a notion of what the output should be, and you're trying to build towards that notion.. without the validation that you're thinking of it correctly. The first is a harder social problem (aka getting people to change) while the second is a harder technical problem.
- skohan 5y ago
  Ultimately you have to build within your sphere of competence. If you have a well-established but inefficient manual process, it may sometimes be the case that burning it down and replacing it with a tech-driven approach might be the best way forward. But if you are trying to solve a novel problem, and the proposed solution involves "ML will magically predict the future", you'd better have a very good idea of exactly how the problems will be solved, or else you're probably better off starting with good old-fashioned human intelligence.
staticautomatic 5y ago
It’s more complex than this in practice because in a large organization you have a significant change management component to every process change, whereas automation of an existing process immediately frees up bandwidth even if the process isn’t great. I interview global executives for a living; I hear this every day and I fully believe it.
rrrrrrrrrrrryan 5y ago
Ideally, you want to understand the whole process from beginning to end, including all the complex edge cases, before trying to automate it, then automate the whole shebang in one giant undertaking. You need a tremendous amount of high-level buy-in to pull this off, as people will have to wait and suffer with the old process until you're completely done building the new one. What often ends up happening is a large manual processes is automated bit by bit, and you end up with the situation you describe: a poorly designed manual process painstakingly replicated in code. Full automation is often never actually achieved here. The absolute worst thing to do, though, is to begin automating the thing without fully understanding it. It's putting rocket boosters on your self-driving car without first understanding the rules of the road.

deleted 5y ago

[deleted]

RyanDagg 5y ago

This is a critical concept that appears to be poorly understood in at least the web development circles I run in. It reminds me of one of my favorite Bill Gates quotes: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency."