Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company?
Any tips of how to do DDD when every area is considered a core priority of the business because uncomfortable conversations are hard?
"There is some benefits to what you're proposing. My primary concern is cost. I see no technical difficulties with doing it <this other way>, and one of the benefits of that is that you'd have it ready in a tenth of the time. If I'm wrong, we can always change our minds and build it your way. That would barely take any additional time at all, since what I'm proposing is so simple to begin with.
"So, what do you say? Would you like to try to get it done by November, or should we labour over it until next June? If I understand the business figures right, if we can get it out in November, we'll make $6,000,000 more – and it would all be because you made the right technical decision here."
> "So, what do you say? Would you like to try to get it done by November, or should we labour over it until next June? If I understand the business figures right, if we can get it out in November, we'll make $6,000,000 more – and it would all be because you made the right technical decision here."
... <End of Year Review>
"We were able to get this out by end of November, thanks to your good technical decision. $6,000,000 saved! Congrats and great job. Accordingly, you've qualified for an annual bonus of a $100 Amazon Gift Card and the default 1.5% raise.
> Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company?
To get buy-in you have to provide value for them that aligns with their needs. If they desire a delusional feeling of outsized importance within an organization then you need to be quite creative. It's more likely that their needs are simpler though. They need to feel they are getting value from you, even if the other parts of the business hold more of the cards.
Try to find simple things to fix for them, choose to build out features with their input, and when building new features for the main stakeholders try and prioritize items which help multiple stakeholders. This is good practice in any case because in the long-term things can change quite significantly within organizations and you don't want to be perceived as only an ally of some within the business.
UPDATE: Beware of quantifying too much. This really impresses some people but will make others feel really small. You may completely lose a connection with one of the smaller stakeholders by quantifying every detail and calling out big numbers around the large stakeholders. You need to work qualitatively for the most part for them. If you want to use numbers, pilot something with a small stakeholder and make a 25% increase to their sales (or a cost reduction). If big holders can get a similar percentage then that translates to big numbers. It feels like a big number to both groups.
I have a few ideas, in fact I gave a talk about that a long time ago [0], but I think one of my friends Marijn gave a good suggestion on twitter [1]: don't sell DDD, but fix your the problem your boss has.
I think the question was more how to sell not-doing-DDD.
Reasonable people (including DDD advocates) clearly understand that tactical patterns can easily be misapplied, and that the strategic part of it is more important, but inexperienced programmers jump in on the "new" fad (it's not even that new, which is most perplexing to me), and misapply all the patterns they possibly can.
I see there's a lot of similar sentiment here, so I think the question really is: how to convince inexperienced "converts" where the right boundary of applying tactical DDD solutions is?
One cause of misapplying tactical patterns is learning. When people start learning something, they do it badly and in inappropriate contexts. The solutions to this are:
A. Don't learn things.
B. Dedicate some amount of time to learn something in a sandbox before using it on the job.
C. Once you've learned something well enough to see the error of your ways, dedicate some amount of time to clean up your old work.
I know A is a tongue-in-cheek, but I think you underestimate human's ability to apply things by learning from good learning materials.
B and C are a single thing, and unfortunately, C does not happen, which is why any particular methodology gets a bad rep. And it's obviously already happening with DDD (judging by the polarized sentiments around here).
And finally, while I do believe abstraction is the ultimate tool of the human mind (and mathematics is the purest form of abstraction we are capable of), I do not think it suits all brains equally, and not everybody will be equally capable of ever getting the right understanding. Basically, your architecture can be _too smart_ if you are looking to hire actual, real-world developers and software engineers, and have them be efficient.
Any tips of how to do DDD when every area is considered a core priority of the business because uncomfortable conversations are hard?