[xyzelement]

It's not just you who struggles with this - it's a very hard thing to do even for those who do it a lot. The number one barrier is just recognizing that it's a thing and you can work on it and do consciously (and sounds like you did that, so that's already huge!)

In fact, what distinguishes executives is their experience, ability and willingness to get others to see and rally around a problem or goal - which is why I positioned this to the person I was responding to as an opportunity. If you can figure this out, your career (and life) unlocks to the next level.

Now to answer your question, some practical advice:

1. Most often, people conflate problems and solutions and just say "we should do X" without making the person first understand and agree that there's a problem to which X is a solution. So when you get pushback on X, is it because the other person doesn't think it's a good solution, or did you not even help them understand that there's a problem to begin with?

2. People often fail to evaluate whether problems are relevant, and to communicate that relevance. EG, have a solid answer to "who gives a fuck?" Like "this system is not well designed and I want to refactor it" - "who cares?". "This system is hard to work on, and we work on it all the time, so our feature delivery velocity is only half of what it could be" - now I am listening.

3. If you lost people, troubleshoot where you lost them. "You don't agree with my proposal to refactor the system, so I just wanted to double check if I had explained the problem well. To remind, do you agree that our feature velocity is slow? (yes/no) If yes, do you agree with me that the root cause of the slowness is the complexity/messiness of the underlying system? (yes/no) Do you agree that my proposal to refactor it will address it (yes/no) Do you just think now is not the time we can afford that investment (yes/no)." etc. Walk them slowly through the conversation, and if you ever get a "no" you didn't expect - dig into that. Is it because you didn't explain something, or because the person knows something you don't? It's not THAT different that debugging code, by trying to find the place where it disconnected from what you expect. But it takes time and confidence to stick with this process.

4. Write it down and have someone read it and tell you if you actually got the point across clearly. Writing things down helps me establish the logic to my intuition which is what enables me to do #3 better.

5. Realize this will never feel easy because it's hard, as long as you're trying and learning from the experience you're doing all you can be doing.

6. Take a class or read a book on negotiations (negotiations is just a process of understanding the other side's position as well as your own and talking through it in a way that finds a solution that works for both).

Good luck. Happy to answer anything else.

[zug_zug]

Yeah I mean this is great in theory, but in practice it's very very hard.

Suppose I were to ask you to explain to somebody non-technical why your application shouldn't have 12 different databases. It's incredibly easy to provide hand-wavey claims about inefficiency, but non-technical people are rightly skeptical (after all for every good idea there are 10 developers claiming a complete rewrite in XYZ will 2x everything).

How can you really provide hard evidence that an application with 1 database instead of 12 will be easier to develop in? Are you going to have devs write code for both cases, and show how many fewer lines of code it is? Are you going to take a dev survey? You can provide your word that certain production bugs were caused by this, but that's again presuming this individual believes you.

Even if you could really spell it out in detail, it's likely they wouldn't have the patience to listen. A chess grandmaster could probably spend an hour explaining a crucial chess move to me, why couldn't an engineering problem warrant over an hour of explanation?

I find completely irrelevant details (how distressed you are by the problem, your race, your last performance review) often have an outsized bias on how persuaded people are.

[xyzelement]

// but in practice it's very very hard

I think I mentioned in my post like 3 times that this is a difficult thing to do even for those who are skilled. My point is that you still have to do it if you want a chance to get the outcomes you desire.

// How can you really provide hard evidence that an application with 1 database instead of 12 will be easier to develop in?

Great example. Like I said, the first step is to confirm a shared understanding of the problem. "Easier to develop" is not relevant, but "feature delivery velocity" is. So step 1, I'd ask the people I am trying to persuade whether they perceive a feature delivery velocity issue on your team.

If the answer is no - well that's a whole different conversation.

Assuming the answer is yes, the next question is - would it be impactful to the business if the velocity went up and should we think about how to do that? Again, if the answer is no - that's interesting. Ask why not?

If the answer is yes - then you come back with "as far as I can tell, one of the sources of our low velocity is the complexity. For example, we have 12 databases and on average, every feature requires 6 of them to be changed. From casual observation, each DB takes X days to update so this is how much tax we're paying every feature."

Then you ask - "does this make sense to you? I am not saying this is the only problem but it seems apparent to me as your technology lead that we're paying a high complexity cost for this design. Let me know if you're with me?"

If they say "no" - great - troubleshoot that.

If they say "yes" - "ok great. I have an idea for how we can go down from 12 databases to 3 at a development cost of X. Ballpark we will recoup that cost in Y months. Should we try this?"

In my experience, walking people through it this way patiently (and it may be multiple conversations), I either get a "yes" or learn a good reason why it shouldn't be done, 100% of the time. Notice that in this approach, I neither lead with the answer "12 DBs bad!" nor overload them with technical detail - but I give them just enough to follow my own logic - after all you must have done similar thinking (even if just intuitively) to arrive at your conclusion. Now you're externalizing your intuition in a way that others can follow.

Like I said - very hard to do. Most people don't bother, many other people are horrible at it (but way ahead of those who don't try!) But either way, this is the only way to get shit done so you gotta do it.

[epgui]

#3 is nearly impossible in practice, because your audience will not sit patiently and entertain you while you do this. In nearly all cases, they will derail your explanation and bring in all sorts of tangential issues that may not even be relevant. Threading through this will require more energy than everyone is willing to spend, so someone will find a way to cut the conversation short. They might also be upset because they feel like you think they're slow, whether or not that's true and no matter how nice your delivery is.

[xyzelement]

It's definitely possible (I do it all the time) but it requires framing.

If I have to, I will say something like "It seems to me like we're not eye to eye on this important topic, and I want us to be in sync. Would you mind if I ask you a few questions to understand where we are disconnected so I can improve my own thinking here?"

I literally say this stuff, and I've never had anyone say "no, I'd rather not get in sync w you on this." So I contextualize it, we work through it, and usually it takes <5 minutes for me to figure out where the other person's head is different from mine.

Then you figure out what to do about it, which may be another conversation (you may also learn that their reasons are good so you end up being persuaded by them which is also great)

[n0w]

Thank you for taking the time to reply so thoroughly, this seems like very actionable advice. Sounds like it's going to take a lot of effort to put into practice, but that it'll be effort well spent!

[xyzelement]

Absolutely! Good luck, your attitude is great.