5 ms·

I implement workflows for a living and it is a million times easier to adapt your process to the tool than the other way around. You will spend more effort ada

by treis 6y ago

I implement workflows for a living and it is a million times easier to adapt your process to the tool than the other way around. You will spend more effort adapting the software than the people. That's for business but I think it applies to individuals as well. You're much more adaptable than software. Pick the thing closest to what you want and change how you work to fit the software.

freehunter 6y ago
I work in professional services for a large IT vendor (and before that I worked for a place that used that vendor’s products) and I can tell you we spend a huge amount of time working with our customers to help them fit their workflow to our tools. Because there is no way we can engineer our tools to fit or enable every workflow. Some companies have the skill and desire to build their own tools over our products so they can use their pre-existing workflows, but inevitably the abstractions start to leak and they almost always end up hiring us to train them on how to use the tool the way it was meant to be used.
- luckydata 6y ago
  Sure but how much you gotta change is the difference between a successful implementation and a failure. Good tools are already close to what people do.
  - wtetzner 6y ago
    > Good tools are already close to what people do. I’m not sure I agree. I think good tools represent the problem space well, and provide powerful ways of manipulating/interacting with it. That may or may not be what people are already doing. I’d say solving a problem well is orthogonal to what people are actually doing.
- trentnix 6y ago
  I'm living that now a little bit. New tools and processes are discussed and evaluated based on how easily they can be customized, perverted, and eventually bastardized. More frequently than you could imagine, people and organizations jump to how they are going to implement something before they define what they want to implement. And when the effort fails, the technology is blamed and they start all over again.
  - Aeolun 6y ago
    A lot of organisations make the mistake that they think they can fix a garbage process with more technology. They end up finding that garbage in = garbage out
conception 6y ago
This sounds right but in my experience most people are set in their ways and it is very hard to rewrite the muscle memory of a process. Especially since it appears that most people are sensors (vs intuitive if you buy Myers Briggs take on personalities https://personalityhacker.com/develop-intuition-intuitive-awakening/ https://personalityhacker.com/develop-intuition-intuitive-aw...) then it requires a whole retraining of x does y and a does b. In my experience it is tremendously easier to have a computer change then a person much less a group. Admittedly most people when put in the position don’t have a choice and the cost of retraining is rarely measured but studies on adult learners generally point out it’s hard and doesn’t go as well as we’d expect.
bryanrasmussen 6y ago
When you write a tool you do it around a workflow that you have observed as being beneficial. When you adopt a tool you adapt your workflow to its limitations. on edit: obviously this is an "ideally speaking" type situation.
- lioeters 6y ago
  Well put. And it's painful when either of these decisions goes wrong. - When you write a tool without knowing exactly what is a beneficial workflow, and this imperfect, probably under-documented and under-tested tool must be maintained over the long term. - When you adopt a tool - trusting that its developers know what a beneficial workflow is - and it doesn't suit your workflow, or skews your workflow unnecessarily, where you have to bend over backwards to suit the tool. It can add inefficiencies and cost of time/effort, that might not be worth it - but, once adopted, you could be stuck with it over the long term. --- The posted article argues for the advantages of "homebrewed tools". The main point being, the priority and emphasis on the workflow itself, which the tools should support. > I can build the tools that exactly conform to my workflows, rather than constructing my workflows around the tools available to me. > ..Tools you build yourself can grow and change as your workflow changes over time. > This is typical of the way I discover my workflows. I start with a minimal, bare-bones solution, and try to pick up on patterns and tricks I create for myself. And then I encode those patterns and tricks into the tools over time. In my experience, I've found this approach to result in simpler systems that are easier to understand in a sitting. When it goes wrong, it can be adjusted right there in the tool. And, in general, I feel that when things go wrong with an established, community standard tool, it's more painful to work around it since, usually, it's not easy or possible to change the tool to fit your ideal workflow. --- There's something to be said for community-developed and supported tools, with detailed documentation and a crowd of people using it in production, essentially testing every nook and cranny of the tool. I suppose only experience can truly distinguish when one approach is better than the other, in a given context.
gonzo41 6y ago
I came here to say this. And just mention that in most IT workflow disasters. It's usually when the company decides it doesn't want to bend a knee and change it's processes to fit the tool.
cjonas 6y ago
In general, I agree with this... There are cases in which there is actual value in breaking "out of the box", but it's difficult to calculate the ROI. It also depends on the licensing cost of a tool and the skill of your team. Enterprise software can be insanely expensive, and with the modern framework and the right team, it might actually be significantly cheaper to build features yourself. I recently built a DocuSign replacement which also collects payment method for 1/2 the cost of the yearly subscription. Turns out they didn't need to actually collect signatures in the first place, but they were doing so because they modified their process to fit the tool...
- ta17711771 6y ago
  That's wild. ½ of the subscription including your time, or no?
  - cjonas 6y ago
    ya really the only real cost was my time. It runs on their existing CRM platform so no additional infrastructure overhead. It's just a small react app which displays a PDF contract, gathers TOS acceptance and collects CC via a Braintree drop-in. They were sending contracts via Docusign (10's of thousands @ $11 per envelope!), then would still have to separately gather payment information and update the CRM to process the sale. I spoke with there legal team and turns out they didn't really need a legally binding signature. New system does everything they actually needed, without any real reoccurring costs.
nabilhat 6y ago
Absolutely! The majority of tools and systems in distribution are templates for effective workflows. For setting up your personal life as in this post, by all means go bespoke in your area of expertise or curiosity. It's certainly not the most effective or efficient workflow in the world, but that's not why you're using it, right? When performance really counts, always look long and hard at what the thousands-millions who've trod this way before have done before bushwhacking your own path. While hiking around Iceland, for example, one should adopt established tools and methods, and adapt to them. No one's workflow can ever grow to accommodate that level of embedded efficiency and safety. Real change in business requires adopting new processes. I just helped a small business shift from a paper driven workflow to electronic. Adapting their workflow to fit established tools was less work than doing nothing, less effort than their existing process; they doubled their output literally overnight. We'd have been fools to try to adapt a tool they'd never used or heard of before to look like their paperflow.
hinkley 6y ago
I had heard this about Salesforce years ago, that companies generally do better by adapting to Salesforce than by adapting Salesforce. In the end every quirky thing you do means more on the job training for all new employees. If you take quirky too far, then you can’t hire new senior talent (everyone starts as a noob). And it may be very uncomfortable to look at, but you need to think hard about who benefits by having things be this way. It’s not the company, and probably not the team. It’s a couple of people and likely also their manager.
rexpop 6y ago
> it is a million times easier to adapt your process to the tool than the other way around In the short term, perhaps, but at what cost in the long-run? We end up with channels of accepted behavior dictated, undemocratically, by software teams.

by treis 6y ago

freehunter 6y ago

I work in professional services for a large IT vendor (and before that I worked for a place that used that vendor’s products) and I can tell you we spend a huge amount of time working with our customers to help them fit their workflow to our tools. Because there is no way we can engineer our tools to fit or enable every workflow. Some companies have the skill and desire to build their own tools over our products so they can use their pre-existing workflows, but inevitably the abstractions start to leak and they almost always end up hiring us to train them on how to use the tool the way it was meant to be used.

luckydata 6y ago
Sure but how much you gotta change is the difference between a successful implementation and a failure. Good tools are already close to what people do.
- wtetzner 6y ago
  > Good tools are already close to what people do. I’m not sure I agree. I think good tools represent the problem space well, and provide powerful ways of manipulating/interacting with it. That may or may not be what people are already doing. I’d say solving a problem well is orthogonal to what people are actually doing.
trentnix 6y ago
I'm living that now a little bit. New tools and processes are discussed and evaluated based on how easily they can be customized, perverted, and eventually bastardized. More frequently than you could imagine, people and organizations jump to how they are going to implement something before they define what they want to implement. And when the effort fails, the technology is blamed and they start all over again.
- Aeolun 6y ago
  A lot of organisations make the mistake that they think they can fix a garbage process with more technology. They end up finding that garbage in = garbage out

conception 6y ago

This sounds right but in my experience most people are set in their ways and it is very hard to rewrite the muscle memory of a process. Especially since it appears that most people are sensors (vs intuitive if you buy Myers Briggs take on personalities https://personalityhacker.com/develop-intuition-intuitive-awakening/ https://personalityhacker.com/develop-intuition-intuitive-aw...) then it requires a whole retraining of x does y and a does b. In my experience it is tremendously easier to have a computer change then a person much less a group. Admittedly most people when put in the position don’t have a choice and the cost of retraining is rarely measured but studies on adult learners generally point out it’s hard and doesn’t go as well as we’d expect.

bryanrasmussen 6y ago

When you write a tool you do it around a workflow that you have observed as being beneficial. When you adopt a tool you adapt your workflow to its limitations. on edit: obviously this is an "ideally speaking" type situation.

lioeters 6y ago
Well put. And it's painful when either of these decisions goes wrong. - When you write a tool without knowing exactly what is a beneficial workflow, and this imperfect, probably under-documented and under-tested tool must be maintained over the long term. - When you adopt a tool - trusting that its developers know what a beneficial workflow is - and it doesn't suit your workflow, or skews your workflow unnecessarily, where you have to bend over backwards to suit the tool. It can add inefficiencies and cost of time/effort, that might not be worth it - but, once adopted, you could be stuck with it over the long term. --- The posted article argues for the advantages of "homebrewed tools". The main point being, the priority and emphasis on the workflow itself, which the tools should support. > I can build the tools that exactly conform to my workflows, rather than constructing my workflows around the tools available to me. > ..Tools you build yourself can grow and change as your workflow changes over time. > This is typical of the way I discover my workflows. I start with a minimal, bare-bones solution, and try to pick up on patterns and tricks I create for myself. And then I encode those patterns and tricks into the tools over time. In my experience, I've found this approach to result in simpler systems that are easier to understand in a sitting. When it goes wrong, it can be adjusted right there in the tool. And, in general, I feel that when things go wrong with an established, community standard tool, it's more painful to work around it since, usually, it's not easy or possible to change the tool to fit your ideal workflow. --- There's something to be said for community-developed and supported tools, with detailed documentation and a crowd of people using it in production, essentially testing every nook and cranny of the tool. I suppose only experience can truly distinguish when one approach is better than the other, in a given context.

gonzo41 6y ago

I came here to say this. And just mention that in most IT workflow disasters. It's usually when the company decides it doesn't want to bend a knee and change it's processes to fit the tool.

cjonas 6y ago

In general, I agree with this... There are cases in which there is actual value in breaking "out of the box", but it's difficult to calculate the ROI. It also depends on the licensing cost of a tool and the skill of your team. Enterprise software can be insanely expensive, and with the modern framework and the right team, it might actually be significantly cheaper to build features yourself. I recently built a DocuSign replacement which also collects payment method for 1/2 the cost of the yearly subscription. Turns out they didn't need to actually collect signatures in the first place, but they were doing so because they modified their process to fit the tool...

ta17711771 6y ago
That's wild. ½ of the subscription including your time, or no?
- cjonas 6y ago
  ya really the only real cost was my time. It runs on their existing CRM platform so no additional infrastructure overhead. It's just a small react app which displays a PDF contract, gathers TOS acceptance and collects CC via a Braintree drop-in. They were sending contracts via Docusign (10's of thousands @ $11 per envelope!), then would still have to separately gather payment information and update the CRM to process the sale. I spoke with there legal team and turns out they didn't really need a legally binding signature. New system does everything they actually needed, without any real reoccurring costs.

nabilhat 6y ago

Absolutely! The majority of tools and systems in distribution are templates for effective workflows. For setting up your personal life as in this post, by all means go bespoke in your area of expertise or curiosity. It's certainly not the most effective or efficient workflow in the world, but that's not why you're using it, right? When performance really counts, always look long and hard at what the thousands-millions who've trod this way before have done before bushwhacking your own path. While hiking around Iceland, for example, one should adopt established tools and methods, and adapt to them. No one's workflow can ever grow to accommodate that level of embedded efficiency and safety. Real change in business requires adopting new processes. I just helped a small business shift from a paper driven workflow to electronic. Adapting their workflow to fit established tools was less work than doing nothing, less effort than their existing process; they doubled their output literally overnight. We'd have been fools to try to adapt a tool they'd never used or heard of before to look like their paperflow.

hinkley 6y ago

I had heard this about Salesforce years ago, that companies generally do better by adapting to Salesforce than by adapting Salesforce. In the end every quirky thing you do means more on the job training for all new employees. If you take quirky too far, then you can’t hire new senior talent (everyone starts as a noob). And it may be very uncomfortable to look at, but you need to think hard about who benefits by having things be this way. It’s not the company, and probably not the team. It’s a couple of people and likely also their manager.

rexpop 6y ago

> it is a million times easier to adapt your process to the tool than the other way around In the short term, perhaps, but at what cost in the long-run? We end up with channels of accepted behavior dictated, undemocratically, by software teams.