Hello friends. I’ve been consumed for the last few months with finishing Chapter 3 of my book, some particularly intense client work, and, most recently, a collaborative post I wrote for The Pragmatic Engineer newsletter titled “What is good software architecture?”. If you’re a new subscriber, that post is probably how you found me. Welcome, it’s great to have you here.
I’m going to do a few posts to either expand on concepts I wrote in the aforementioned architecture post or share sections that were cut from the final version.
Today’s topic is an important skill you’ll need to master if you want to improve your architecture skills: Persuasion. To call back to the post title, a lack of persuasiveness is why many great engineers lose debates. Let’s get into it.
Unless you are a one-person engineering army, able to propose, design, build, deploy, and operate your ideas in production, you’re going to need to convince others that your ideas are worthwhile.
There are several techniques to improve at this. Here are a few that I’d suggest:
Imagine your listen-to-talk-ratio. It’s probably lower than you think it is.
Now, think of your least favorite people to interact with at work, or even outside of work. Their listen-to-talk ratios are likely on the lower side. This may not be the entire reason you don’t like interacting with them, but it’s relevant.
At a minimum, you want to be listening 50% of the time. Not only is this polite, but in a debate it often enables your opponent to wear themselves out. They talk and talk, and then, after they’re weak, you poke them with an insightful question. Which brings us to…
This can mean a few things:
Questions motivated by genuine curiosity
What business metrics do we expect to increase by adding this feature?
What happens if we have too much data to cache in-memory?
Asking one question at a time, especially when asking verbally (as opposed to in writing). Don’t bludgeon your target with 5 questions in a single run-on sentence, especially in a meeting full of people.
Don’t ask gotcha questions, it’s annoying and transparent. Great question askers do not bludgeon their target with inquiries - they gently guide them. If you do have a question that you are genuinely curious about that will also completely destroy your opponents argument, ask it as politely as possible, and give them space to recover. Your point will get across and it won’t seem as aggressive. Speaking of aggression…
Much of this is accomplished through tone and phrasing.
For example, “I have concerns with this approach” (followed by details) is exponentially better than “This approach won’t work.”
Assertiveness is often about setting boundaries. It can feel harsh to do this in a corporate environment. Not all of us can get away with being harsh, so you need some “soft” phrases in your arsenal.
Here’s an example…
I was in a meeting awhile back where a teammate and I were loaned to another team’s project, on the condition that our work would be mutually beneficial across teams.
The project lead then proceeded to assign us a bunch of random bugs to fix.
I said “I don’t think we’re aligned” with regard to our role on the project. This may sound like corporate speak, but it was much more polite and effective than saying “Stop assigning us these random bugs, as we don’t want to work on them.”
Last, but not least…
Logical fallacies are one of the primary weapons of technical debates. It pays to be wary of them because they are highly effective in heavily time-constrained environments where a quick decision must be made - which describes most interactions with executives, in my experience.
A fallacy I see often is when a person says, “We have problems A, B, C, and D, so we should pursue solution Z”. Typically, solution Z is a complete rewrite of a system, or a commercial product to replace a home-grown system. Technically this is a non sequitur, which is more flawed reasoning than a logical fallacy, but we’re in the ballpark.
You’ll want to learn to wield logical fallacies also, as sometimes the stakes are too high to remain a pacifist. But that’s a topic for another day.
Persuasion is an important skill to move your ideas forward. It can take many forms, depending on the context. In a 1:1 meeting, listening builds trust. In an incident review, being assertive prevents your team from absorbing random work. In an architecture meeting with executives, a well-placed logical fallacy can move a big project in a direction that favors your team, which, in this economy, could provide job security for a few more years. As your persuasion skills improve, your life will follow. Thanks for reading and have a great day.
If you liked this post, you’ll also enjoy:
PUSH TO PROD OR DIE TRYING: High-Scale Systems, Production Incidents, and Big Tech Chaos 🔥
Learn how to persuade your software systems to scale and serve you well. 🧠

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.