Unfortunately for myself at least I seem to be faaar too autistic to be able to do this.
I am good at writing code, writing queries, solving interoperability problems, analyzing large data sets, and I can even manage to present reports in ways that are statistically valid but summarized to narratives.
What I cannot handle is my bosses bosses boss insisting I use an entirely new software I have never used before to solve a problem that we can already solve with software we have, for a problem that would not be a problem if she had listened to either my boss, my bosses boss, or the leads of all the other teams who have all been saying the same thing for months.
This kind of thing has happened to me at every single tech role I have ever worked.
Logic means nothing. What matters is the high up thinks something is ‘neat’ and theres no way they can be told, directly, or indirectly, that they have no clue what theyre talking about.
Those are different problems, though. Or at least only slightly related.
Business people operate on a different plane. Not necessarily a bad one, just different. Not, that there’s no stupidity involved, but if you dig a bit (they’re often surprisingly incapable of expressing their own motivation), you’ll often find that in their reality tunnel, their decision makes total sense. And from their perspective, we are just a bunch of semi-autistic nerds who can’t even explain what they’re doing and cost ungodly amounts of money. If we complain about a decision in technical terms, they don’t understand that.
So, assuming the decision makers in your organization don’t act in bad faith or are really just stupid, try to think from their standpoint. If that helps you, think about it like an RPG. If you’re talking to a character whose entire motivation is money, you wouldn’t choose the dialog option about what a great warrior your paladin is.
For business people the relevant metrics are costs, time to market, risks. If they come around with a new software that is objectively bad, you don’t argue that you can already do that, you only need to deploy the Operator with the AbstractBusinessFactoryBuilder configured differently, etc etc. Instead, you argue, that this poses immense risks, since you’d have to redo a lot of work, which of course costs a lot of resources. Also, you could argue, that such a vendor lock in poses immense risks, since you can’t really extend the software. And so on.
Don’t start as being the hysterical autist they see us as. Try to ask, why this is relevant. What exactly do they think is the benefit? If they can’t explain it to you, say that. You’re the expert, after all. And then, give the software a chance, so your objections have a basis.
Finally, don’t forget the magic of the word “no”. There’s a good chance, that simply downright rejecting work on a change/project will actually make some people think.
Maybe it’s lame and old fashioned… but I’ve had success with explaining things with flow charts. Make some boxes to represent APIs, make some cylinders to represent DBs, etc, draw some lines to show how things connect. Pick some pretty colours, managers like that. Think more on the lines of explaining to a child how things work.
Once you have that picture you can point to things on it and say “we can add some code here, and a few tables here to provide the feature.” You can add more boxes and lines on another version to represent the new software they want to add to the flow, and they will be able to visualize how that makes things more complicated. Then talk in terms of time to maintain this new software that makes the process more complex… “My estimate is it will take 200 hours to implement this and an additional 100 hours per year to maintain it.” Yeah, it’s mostly going to be numbers you pulled out of your ass, but if your boss is the kind of person that pulls ideas from their ass, they really can’t dispute what you’re saying. And they will hopefully be capable of converting the time estimate into a money estimate themself and they will come to the conclusion on their own that your preferred approach is better on their own.
The trick is to make them think it was their idea.
Unfortunately for myself at least I seem to be faaar too autistic to be able to do this.
I am good at writing code, writing queries, solving interoperability problems, analyzing large data sets, and I can even manage to present reports in ways that are statistically valid but summarized to narratives.
What I cannot handle is my bosses bosses boss insisting I use an entirely new software I have never used before to solve a problem that we can already solve with software we have, for a problem that would not be a problem if she had listened to either my boss, my bosses boss, or the leads of all the other teams who have all been saying the same thing for months.
This kind of thing has happened to me at every single tech role I have ever worked.
Logic means nothing. What matters is the high up thinks something is ‘neat’ and theres no way they can be told, directly, or indirectly, that they have no clue what theyre talking about.
Those are different problems, though. Or at least only slightly related.
Business people operate on a different plane. Not necessarily a bad one, just different. Not, that there’s no stupidity involved, but if you dig a bit (they’re often surprisingly incapable of expressing their own motivation), you’ll often find that in their reality tunnel, their decision makes total sense. And from their perspective, we are just a bunch of semi-autistic nerds who can’t even explain what they’re doing and cost ungodly amounts of money. If we complain about a decision in technical terms, they don’t understand that.
So, assuming the decision makers in your organization don’t act in bad faith or are really just stupid, try to think from their standpoint. If that helps you, think about it like an RPG. If you’re talking to a character whose entire motivation is money, you wouldn’t choose the dialog option about what a great warrior your paladin is.
For business people the relevant metrics are costs, time to market, risks. If they come around with a new software that is objectively bad, you don’t argue that you can already do that, you only need to deploy the Operator with the AbstractBusinessFactoryBuilder configured differently, etc etc. Instead, you argue, that this poses immense risks, since you’d have to redo a lot of work, which of course costs a lot of resources. Also, you could argue, that such a vendor lock in poses immense risks, since you can’t really extend the software. And so on.
Don’t start as being the hysterical autist they see us as. Try to ask, why this is relevant. What exactly do they think is the benefit? If they can’t explain it to you, say that. You’re the expert, after all. And then, give the software a chance, so your objections have a basis.
Finally, don’t forget the magic of the word “no”. There’s a good chance, that simply downright rejecting work on a change/project will actually make some people think.
Maybe it’s lame and old fashioned… but I’ve had success with explaining things with flow charts. Make some boxes to represent APIs, make some cylinders to represent DBs, etc, draw some lines to show how things connect. Pick some pretty colours, managers like that. Think more on the lines of explaining to a child how things work.
Once you have that picture you can point to things on it and say “we can add some code here, and a few tables here to provide the feature.” You can add more boxes and lines on another version to represent the new software they want to add to the flow, and they will be able to visualize how that makes things more complicated. Then talk in terms of time to maintain this new software that makes the process more complex… “My estimate is it will take 200 hours to implement this and an additional 100 hours per year to maintain it.” Yeah, it’s mostly going to be numbers you pulled out of your ass, but if your boss is the kind of person that pulls ideas from their ass, they really can’t dispute what you’re saying. And they will hopefully be capable of converting the time estimate into a money estimate themself and they will come to the conclusion on their own that your preferred approach is better on their own.
The trick is to make them think it was their idea.