"I'm the lead, and we are going to do it this way": avoid it for as long as you can, but do NOT hesitate to use it when it's the appropriate answer.
Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice. But sometimes teams can get caught in an endless futile discussion over details that don't matter for the stated goals.
In that case, it's *your duty* as the leader to play the dictator and impose order. "If you want to make everyone happy, don't be a leader. Sell ice-cream", Steve Jobs reportedly once said.
If it happens though, don't forget to re-establish trust with your team members and make sure they understand the circumstances that led you to act in that way.
This is a lesson I learned the hard way. When I was a first time manager I had the naive idea that I was going to build consensus for everything and get everyone to come to an agreement naturally.
It worked at first with a good team. Then later I inherited a fragment of another team with some older know-it-all engineers who thought everything modern was garbage and we should be doing everything like they did 25 years ago. I wasted too much time letting them stonewall everything while thinking we’d eventually reach a consensus.
Then at some point you realize you have to put your foot down and pick a direction after they’ve had a chance to state their position.
You can build consensus around the decision making process and build a culture where the outcome of that process is widely accepted. As long as people have the time and pathways to make their case and input, and understand there will be some verdict that may or may not align completely with their opinion. Then its just the decision makers duty to synthesize things in good faith but probably has bought themselves some leeway.
One thing I like to do with sr+ engineers who will feel burned by a decision - esp. those very publicly against it - is to lead with some sort of concession... maybe a project they expressed interest in, greenlight for a week to research some POC.
Whatever it is, it tends to be considerably less value to the business than the decision itself, but it directly acknowledges their discontent and allows them to get something out of the process besides platitudes, (perceived) public embarrassment, and frustration.
You could learn from consent based decision making, a hallmark of sociocratic worker coops that is underrated and can be applied elsewhere.
Hierarchy and coercion isn't necessary for avoiding decision paralysis in organizations. It appears to be the practical route but has all sorts of harmful and counterproductive consequences.
I don’t think that is a practical framework for situations where people aren’t already very closely aligned.
What happens when a few people are very vocal (and firm) in opposition to basically every change? Having dissenting views is valuable, but not when they have veto power.
Additionally, I think that framework is vulnerable to what I refer to as “death by yes but” - when everyone is just piling on amendments and precursor conditions, oftentimes conflicting, that result in a decision taking months (maybe even years) to make or scuttle.
I’m basing these comments out of experience - one example is a workgroup/committee operating under a similar model that was completely unable to do anything due to decision paralysis. The committee grew significantly more effective when we reformed the decision making process to have a small group of owners to handle pitching and (potentially) implementing the decision, then had approval be a simple yes/no majority vote.
Yes it only works when participants have a shared aim
In full sociocracy, it...
> honors the circle’s ability to freely make decisions within its domain. This is key for the organization to remain effective. But it comes at the cost of members not having “consent rights” to every decision the organization makes. Each member will only have those rights for the circles they are a part of.
So it's not necessary to allow people outside that working group to veto or require compulsory followup through objection
There's no perfect solution to organization, everything is a tradeoff. I've also been part of working groups (made of people whose job description is to manage the scope of changes they're proposing) where everyone and the workers impacted by the decisions are in agreement and no impact on cost etc., but the exec decides no change can be made due to personal preference despite disastrous consequence. Or where an exec who abstains from checking in on a working group's efforts nonetheless counters it with shifting and contradictory demands whenever it comes time to take action, requiring going back to the drawing board repeatedly until people simply give up or leave the organization. Or where the exec asks for more data for a proposal, and then doesn't evaluate the data once gathered, leaving no recourse but to give up or leave the organization. We all have stories like this. Hierarchical organizations are also susceptible to paralysis.
I've often taken inspiration from RFC 2418, "IETF Working Group Guidelines and Procedures" [1], a rare RFC that defines a human protocol ("rough consensus") rather than a technical one.
Interesting. For that to work, though, it has to be true consent, not "it's the boss's idea and I don't dare to object out loud".
But I guess, if that's the environment you're in, then you're stuck with autocratic leadership (no matter what label it claims for itself), and your only choice is to leave or not.
Right, and some people’s role is to organize people and orient the group’s efforts.
There’s rarely a single correct answer— lots of good solutions have trade-offs— but there are often various wrong answers. Do the best you can to avoid the wrong answers, and when you inevitably run into the business end of one of your trade-offs, take comfort in knowing the other answers probably also had trade-offs, and tell the know-it-alls to cram it.
People working effectively towards a non-optimal solution is far more useful than around arguing about the best way to do it.
It took a while to emerge but a couple years into my F50 gig we ran into a situation where we had a bus number if 3 in a domain, we all knew that solution A sounds good on paper but is a shitshow in practice, but the rest of the team was still enamored of it and our reasoned explanations just weren’t being persuasive enough.
The popular vote was going to load us up with little emergencies that were going to slow several divisions down and we ended up talking to the bosses and ignoring the vote.
In trying to smooth this over, I realized that the problem is that the people who would be dealing with the consequences of a decision wanted solution C and everyone else wanted solution A. And I think it’s something worth remembering for future indecisions, that the people with skin in the game need to be able to veto a popular vote. If you don’t want the project to lose momentum.
Generally on a large project you will have a bunch of leads all dealing with different domains, and they will reach quorum on major architectural decisions, particularly cross cutting concerns and interfaces between Conway’s Law modularizations. The boss only needs to break ties when a consensus does not emerge. And I mean NEEDS. Second worst boss I ever had refused to break ties and we had an even number of leads, so it happened half a dozen times. We wasted hours every month venting to each other about what we hated about him and one of the regular attendees just about wanted to murder him for that, and have us help him hide the body.
In my opinion this advice is quite fatuous, because it skips over the actual difficult bit, which is figuring out what to do when you have a problem that can't simply be decided by the person directly responsible for the the work, either due to complexity/scale of the problem, or because that person is not capable of making the decision.
“If you want to make everyone happy, don't be a leader.”
This is the most important line. You shouldnt be afraid to hurt some peoples feelings (though not intentionally and as kindly as you can of course). Absolutely nothing will get done if you want everyone to be happy
Very good point. There’s a big difference between “everyone gets heard” and “everyone gets a veto.”
Breaking ties is part of the leader’s job.
Of course if every issue requires the leader to break the tie, then perhaps there’s either a management issue, and incentive issue, or people don’t understand the strategy.
Steve Jobs was also known to lock teams in a room until they arrived at a common vision. It's a difficult task, to align everyone, but in my limited experience not doing it resulted in extremely inefficient execution. What's more, people feel belittled and rejected if you disregard their viewpoints. Sometimes you need to get things done regardless of what people feel or think, but you can't sustain that for a long time.
100%. I worked for a brilliant lead, he had a team of excellent engineers. But he was stuck on the socratic method, determined to lead by asking thoughtful questions and letting us sort it out. Important discussions would go in circles a lot, frustratingly so. Sometimes you have to be the decision maker.
Make sure people understand why you're making the tradeoff you're making, and also make sure they know you're taking the fire for it if you were wrong and they were right, not them.
Humans sometimes yearn for the leader to put their foot down.
The quiet ones may want the yapping voices silenced so progress can be made.
And sometimes the yapping ones get out ahead of their own skis and don't know a graceful way to back down so they're happyish to be closed down, even if they're primed to come back with an "I told you so" if the leader gets it wrong.
In my experience, you don't really want to say "I'm the lead" (it can come across insecure), but you do need to be able to confidently say "Ok, here's what we're going to do" or "Here's what I'd like you to do" once you've gathered all the relevant information and come to a decision.
First build the thing that works, and only if it's really necessary, split it up in separate (networked) parts. You won't have to deal with unreliable network communication, or coordinate on a breaking API change with several teams when a simple search/replace on several function definitions and calls suffices.
Funnily enough, microservices. In the macro economy you don't have to have such strict coordination with Microsoft, or OpenAI, or Google, or whomever you interface with. You just figure out how to make your solution work within the confines of the service they give you. Like it or not.
Microservices is exactly the same concept except in the micro economy of a single organization. Each team is like Microsoft, OpenAI, Google, etc. You don't coordinate with them, you deal with what they give you. Like it or not.
I expect the earlier statement confused microservices with a multi-process application.
I love the phrase "It's because that's why". For anyone interested in this kind of subject I've benefited a lot from Vanessa Van Edwards books which essentially boil down to signalling warmth and competence in the right ways for a given context. Of course, it's a giant field and no one person has all the answers, but for me it's yielded some wins.
I like to use something along the lines of "anyone in this room is capable of handling the minutia satisfactorily, there is no need to waste time on the details".
What is a lead developer in this context? An engineering manager? Is it like an architect (staff engineer/whatever)? An engineer who is in charge of a specific project?
There are different dynamics at play in each role and reading the guy's bio I'm getting the sense that he is a freelancer? or has a consulting company? which would have a whole different dynamic.
The lead developer is the person assigned to the lead developer role. I know it's cheeky but it really could be anyone. It's usually at least a senior-level individual contributor (IC). It's not uncommon for it to be a manager (that hopefully used to be an IC).
The lead's authority also tends to be varied in scope. They could be the lead of the feature, project, repo, team, initiative, or org. Depending on the context, their hierarchy might not always be the same.
So really, a lead is someone that is in or uses leadership within their scope and with others in the same position. Alternatively referred to as "politics".
In this context, they're handing the politics of development issues with the goal of getting features done.
In the aerospace world, it's called a "systems engineer."
The lead:
1: Understands the whole system, but not necessarily every detail.
2: Plans the whole project.
Edit:
Sometimes in the software world, the title is "architect."
This is rarely the "manager," except in organizations that have a hard-on for hierarchy and artificial promotion for "career advancement." Managers are usually concerned with people, schedules, and resources; but don't go very deep into technical issues.
That being said, the lead/manager may fill in for each other when one is on vacation, sick, quits, ect.
> I often get "eye rolls" when I say this to developers: You are not going to convince anyone with facts.
True in technical leadership and true in life. Engineers are especially prone to this sort of frustration, where you're technically right but socially aren't speaking the right language for your audience.
This is a difficult lesson to swallow, but must be understood. I do still retain some frustration that there does not seem to be more effort to correct for this problem locally. For instance, in general you must speak to your audience and make emotional appeals. But me, your boss, should understand how to look past that and work with the facts, at least to the degree possible.
There are places that have this norm, but it's exceedingly rare, and it's not some perfect utopia. We're all susceptible to emotional appeals to different degrees, and emotions aren't some inconvenience that you should try to eliminate in favor of pure cold calculations, they also have a place and a reason to be.
People care about different things, so trying to focus just on facts can end up with people talking past each other, because they have different goals, value systems, or other fuzzy human feelings that can't be graphed in an Excel spreadsheet and compared numerically.
I'm not saying that emotional appeals and sophistry are fine, but I find that often when people accept an emotional appeal over a cold purely factual argument, it's because the factual argument is missing the point. A more important part of the discussion is understanding what other people actually care about to make sure we're not all talking past each other, or spending hours arguing details that won't matter in the end.
Why? Are they insufferable otherwise? Or is it more that you find it unbearable to tolerate a different opinion? I'm so curious, about both of you. What part does he think was a hoax?
In my experience that's usually just the tip of the iceberg. You've heard the expression "All happy families are alike; each unhappy family is unhappy in its own way"? It's like a link broke in a chain, and usually it's many links correlated. Maybe they just distrust expertise, well I have a phd and I assure you it'll come up later. Maybe he's an immigrant from Russia and he just distrusts everything to do with the news, well that's not really fixable except maybe with many years of therapy. And yes it will come up later too. I'm not a professional, I didn't want to ask the specifics or get into the weeds, I just have a developed nose for these things. My brother is into conspiracy theories.
> I have a phd and I assure you it'll come up later.
Will it? One would have to dig pretty deep into one's personal life to learn about that. Someone who thinks COVID was a hoax isn't going to be one to dig deep. And, well, if he really did somehow dig deep enough to find that information, you can just laugh it off as a hoax.
> Someone who thinks COVID was a hoax isn't going to be one to dig deep.
This is kind of a side point, but people with fringe beliefs tend to dig a lot deeper to validate those opinions than those with a mainstream view.
You can bet that someone who thinks that the moon landing was a hoax to the point that they would tell someone about it will know more about the moon landing than a random person who believes it was real.
It often takes an expert in something to shoot down the arguments.
Linkedin is editable, no? Maybe he could still find it in a cache if he digs deep enough, but I mean, really, it is highly unlikely that anyone is going to put in that much effort unless they are on a mission. Nobody casually cares.
It's directionally correct but not entirely accurate IMO. It would be more accurate to say, your audience does not have the experience and context necessary to turn the facts into a decision criteria. You need to translate your "raw data facts" into "refined facts" ready for consumption by the audience. That's what a good communicator does. The original phrasing makes it almost sound like the decisions are not fact-based or emotional, which should elicit eye-rolls.
> It would be more accurate to say, your audience does not have the experience and context necessary to turn the facts into a decision criteria.
I don't agree. Humans are fundamentally social and illogical creatures, and in many cases regardless of the experience or context they have, they will make decisions based on social factors regardless of hard logic.
I think it does deserve eye roll, because it is huge oversimplification on itself. The situations in which you convince people with facts are not exactly rare.
That person is getting an eye roll, because they are just repeating popular phrase that is not even particularly useful.
“Expert” doesn’t mean much anymore. They’re more likely than not to be under the control of their employers, their funders, or even their political ideology.
"I'm the lead, and we are going to do it this way": avoid it for as long as you can, but do NOT hesitate to use it when it's the appropriate answer.
Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice. But sometimes teams can get caught in an endless futile discussion over details that don't matter for the stated goals.
In that case, it's *your duty* as the leader to play the dictator and impose order. "If you want to make everyone happy, don't be a leader. Sell ice-cream", Steve Jobs reportedly once said.
If it happens though, don't forget to re-establish trust with your team members and make sure they understand the circumstances that led you to act in that way.
This is a lesson I learned the hard way. When I was a first time manager I had the naive idea that I was going to build consensus for everything and get everyone to come to an agreement naturally.
It worked at first with a good team. Then later I inherited a fragment of another team with some older know-it-all engineers who thought everything modern was garbage and we should be doing everything like they did 25 years ago. I wasted too much time letting them stonewall everything while thinking we’d eventually reach a consensus.
Then at some point you realize you have to put your foot down and pick a direction after they’ve had a chance to state their position.
You can build consensus around the decision making process and build a culture where the outcome of that process is widely accepted. As long as people have the time and pathways to make their case and input, and understand there will be some verdict that may or may not align completely with their opinion. Then its just the decision makers duty to synthesize things in good faith but probably has bought themselves some leeway.
One thing I like to do with sr+ engineers who will feel burned by a decision - esp. those very publicly against it - is to lead with some sort of concession... maybe a project they expressed interest in, greenlight for a week to research some POC.
Whatever it is, it tends to be considerably less value to the business than the decision itself, but it directly acknowledges their discontent and allows them to get something out of the process besides platitudes, (perceived) public embarrassment, and frustration.
You could learn from consent based decision making, a hallmark of sociocratic worker coops that is underrated and can be applied elsewhere.
Hierarchy and coercion isn't necessary for avoiding decision paralysis in organizations. It appears to be the practical route but has all sorts of harmful and counterproductive consequences.
https://www.sociocracyforall.org/consent-decision-making/
I don’t think that is a practical framework for situations where people aren’t already very closely aligned. What happens when a few people are very vocal (and firm) in opposition to basically every change? Having dissenting views is valuable, but not when they have veto power. Additionally, I think that framework is vulnerable to what I refer to as “death by yes but” - when everyone is just piling on amendments and precursor conditions, oftentimes conflicting, that result in a decision taking months (maybe even years) to make or scuttle.
I’m basing these comments out of experience - one example is a workgroup/committee operating under a similar model that was completely unable to do anything due to decision paralysis. The committee grew significantly more effective when we reformed the decision making process to have a small group of owners to handle pitching and (potentially) implementing the decision, then had approval be a simple yes/no majority vote.
Yes it only works when participants have a shared aim
In full sociocracy, it...
> honors the circle’s ability to freely make decisions within its domain. This is key for the organization to remain effective. But it comes at the cost of members not having “consent rights” to every decision the organization makes. Each member will only have those rights for the circles they are a part of.
So it's not necessary to allow people outside that working group to veto or require compulsory followup through objection
There's no perfect solution to organization, everything is a tradeoff. I've also been part of working groups (made of people whose job description is to manage the scope of changes they're proposing) where everyone and the workers impacted by the decisions are in agreement and no impact on cost etc., but the exec decides no change can be made due to personal preference despite disastrous consequence. Or where an exec who abstains from checking in on a working group's efforts nonetheless counters it with shifting and contradictory demands whenever it comes time to take action, requiring going back to the drawing board repeatedly until people simply give up or leave the organization. Or where the exec asks for more data for a proposal, and then doesn't evaluate the data once gathered, leaving no recourse but to give up or leave the organization. We all have stories like this. Hierarchical organizations are also susceptible to paralysis.
I've often taken inspiration from RFC 2418, "IETF Working Group Guidelines and Procedures" [1], a rare RFC that defines a human protocol ("rough consensus") rather than a technical one.
[1] https://www.rfc-editor.org/rfc/rfc2418.html
Interesting. For that to work, though, it has to be true consent, not "it's the boss's idea and I don't dare to object out loud".
But I guess, if that's the environment you're in, then you're stuck with autocratic leadership (no matter what label it claims for itself), and your only choice is to leave or not.
You can also try to organize your peers in those environments (or even from the outside if so inclined)
It's not autocratic, it's not a form of government at all.
Each role is a module to take in inputs, process them, and produce outputs. it is effectively a program.
Define your roles, and expectations of each role, then run the program and edit as needed.
Right, and some people’s role is to organize people and orient the group’s efforts.
There’s rarely a single correct answer— lots of good solutions have trade-offs— but there are often various wrong answers. Do the best you can to avoid the wrong answers, and when you inevitably run into the business end of one of your trade-offs, take comfort in knowing the other answers probably also had trade-offs, and tell the know-it-alls to cram it.
People working effectively towards a non-optimal solution is far more useful than around arguing about the best way to do it.
It took a while to emerge but a couple years into my F50 gig we ran into a situation where we had a bus number if 3 in a domain, we all knew that solution A sounds good on paper but is a shitshow in practice, but the rest of the team was still enamored of it and our reasoned explanations just weren’t being persuasive enough.
The popular vote was going to load us up with little emergencies that were going to slow several divisions down and we ended up talking to the bosses and ignoring the vote.
In trying to smooth this over, I realized that the problem is that the people who would be dealing with the consequences of a decision wanted solution C and everyone else wanted solution A. And I think it’s something worth remembering for future indecisions, that the people with skin in the game need to be able to veto a popular vote. If you don’t want the project to lose momentum.
Generally on a large project you will have a bunch of leads all dealing with different domains, and they will reach quorum on major architectural decisions, particularly cross cutting concerns and interfaces between Conway’s Law modularizations. The boss only needs to break ties when a consensus does not emerge. And I mean NEEDS. Second worst boss I ever had refused to break ties and we had an even number of leads, so it happened half a dozen times. We wasted hours every month venting to each other about what we hated about him and one of the regular attendees just about wanted to murder him for that, and have us help him hide the body.
Alternatively, my preferred method: "You're the one doing the work. Tell me what your decision is."
Your job as a leader isn't necessarily to make the decision, just to be sure that the decision was made.
In my opinion this advice is quite fatuous, because it skips over the actual difficult bit, which is figuring out what to do when you have a problem that can't simply be decided by the person directly responsible for the the work, either due to complexity/scale of the problem, or because that person is not capable of making the decision.
Also, to ensure that the decision made is based on logic and reason. Insofar as that is even possible.
“If you want to make everyone happy, don't be a leader.”
This is the most important line. You shouldnt be afraid to hurt some peoples feelings (though not intentionally and as kindly as you can of course). Absolutely nothing will get done if you want everyone to be happy
Very good point. There’s a big difference between “everyone gets heard” and “everyone gets a veto.”
Breaking ties is part of the leader’s job.
Of course if every issue requires the leader to break the tie, then perhaps there’s either a management issue, and incentive issue, or people don’t understand the strategy.
Steve Jobs was also known to lock teams in a room until they arrived at a common vision. It's a difficult task, to align everyone, but in my limited experience not doing it resulted in extremely inefficient execution. What's more, people feel belittled and rejected if you disregard their viewpoints. Sometimes you need to get things done regardless of what people feel or think, but you can't sustain that for a long time.
This is what we do with juries, so there's something to be said for it.
100%. I worked for a brilliant lead, he had a team of excellent engineers. But he was stuck on the socratic method, determined to lead by asking thoughtful questions and letting us sort it out. Important discussions would go in circles a lot, frustratingly so. Sometimes you have to be the decision maker.
Make sure people understand why you're making the tradeoff you're making, and also make sure they know you're taking the fire for it if you were wrong and they were right, not them.
Humans sometimes yearn for the leader to put their foot down.
The quiet ones may want the yapping voices silenced so progress can be made.
And sometimes the yapping ones get out ahead of their own skis and don't know a graceful way to back down so they're happyish to be closed down, even if they're primed to come back with an "I told you so" if the leader gets it wrong.
> "I'm the lead, and we are going to do it this way"
"Okay. Let me know when you are done with that."
In my experience, you don't really want to say "I'm the lead" (it can come across insecure), but you do need to be able to confidently say "Ok, here's what we're going to do" or "Here's what I'd like you to do" once you've gathered all the relevant information and come to a decision.
> When the product team requests a "simple" feature, I'm thinking about the 3 teams that need to be involved to update the necessary microservices.
God I hate modern web sometimes
What's the alternative?
https://news.ycombinator.com/item?id=43925892 "Microservices are a tax your startup probably can't afford" (310 points, 263 comments).
First build the thing that works, and only if it's really necessary, split it up in separate (networked) parts. You won't have to deal with unreliable network communication, or coordinate on a breaking API change with several teams when a simple search/replace on several function definitions and calls suffices.
Funnily enough, microservices. In the macro economy you don't have to have such strict coordination with Microsoft, or OpenAI, or Google, or whomever you interface with. You just figure out how to make your solution work within the confines of the service they give you. Like it or not.
Microservices is exactly the same concept except in the micro economy of a single organization. Each team is like Microsoft, OpenAI, Google, etc. You don't coordinate with them, you deal with what they give you. Like it or not.
I expect the earlier statement confused microservices with a multi-process application.
A monorepo that the microservices are deployed from?
Works great for Google.
Or request access for the repo and make the PR yourself.
Macroservices, or several megaliths instead of one monolith, if you will.
What about going the other way and Unix-piping together hundreds of thousands of nano-services?
I love the phrase "It's because that's why". For anyone interested in this kind of subject I've benefited a lot from Vanessa Van Edwards books which essentially boil down to signalling warmth and competence in the right ways for a given context. Of course, it's a giant field and no one person has all the answers, but for me it's yielded some wins.
Probably better to say "because it is a bikeshed not worth debate". Often there isn't a right answer but a decision is needed.
I like to use something along the lines of "anyone in this room is capable of handling the minutia satisfactorily, there is no need to waste time on the details".
What is a lead developer in this context? An engineering manager? Is it like an architect (staff engineer/whatever)? An engineer who is in charge of a specific project?
There are different dynamics at play in each role and reading the guy's bio I'm getting the sense that he is a freelancer? or has a consulting company? which would have a whole different dynamic.
The lead developer is the person assigned to the lead developer role. I know it's cheeky but it really could be anyone. It's usually at least a senior-level individual contributor (IC). It's not uncommon for it to be a manager (that hopefully used to be an IC).
The lead's authority also tends to be varied in scope. They could be the lead of the feature, project, repo, team, initiative, or org. Depending on the context, their hierarchy might not always be the same.
So really, a lead is someone that is in or uses leadership within their scope and with others in the same position. Alternatively referred to as "politics".
In this context, they're handing the politics of development issues with the goal of getting features done.
In the aerospace world, it's called a "systems engineer."
The lead:
1: Understands the whole system, but not necessarily every detail.
2: Plans the whole project.
Edit:
Sometimes in the software world, the title is "architect."
This is rarely the "manager," except in organizations that have a hard-on for hierarchy and artificial promotion for "career advancement." Managers are usually concerned with people, schedules, and resources; but don't go very deep into technical issues.
That being said, the lead/manager may fill in for each other when one is on vacation, sick, quits, ect.
> I often get "eye rolls" when I say this to developers: You are not going to convince anyone with facts.
True in technical leadership and true in life. Engineers are especially prone to this sort of frustration, where you're technically right but socially aren't speaking the right language for your audience.
This is a difficult lesson to swallow, but must be understood. I do still retain some frustration that there does not seem to be more effort to correct for this problem locally. For instance, in general you must speak to your audience and make emotional appeals. But me, your boss, should understand how to look past that and work with the facts, at least to the degree possible.
I don't see much of that.
There are places that have this norm, but it's exceedingly rare, and it's not some perfect utopia. We're all susceptible to emotional appeals to different degrees, and emotions aren't some inconvenience that you should try to eliminate in favor of pure cold calculations, they also have a place and a reason to be.
People care about different things, so trying to focus just on facts can end up with people talking past each other, because they have different goals, value systems, or other fuzzy human feelings that can't be graphed in an Excel spreadsheet and compared numerically.
I'm not saying that emotional appeals and sophistry are fine, but I find that often when people accept an emotional appeal over a cold purely factual argument, it's because the factual argument is missing the point. A more important part of the discussion is understanding what other people actually care about to make sure we're not all talking past each other, or spending hours arguing details that won't matter in the end.
You need to get a better audience. I recently met a good developer who still thinks Covid was a hoax. Doing my best to avoid him.
You think you can just politely work around him -- that's how you get vaccine skeptics dismantling the CDC.
Why? Are they insufferable otherwise? Or is it more that you find it unbearable to tolerate a different opinion? I'm so curious, about both of you. What part does he think was a hoax?
In my experience that's usually just the tip of the iceberg. You've heard the expression "All happy families are alike; each unhappy family is unhappy in its own way"? It's like a link broke in a chain, and usually it's many links correlated. Maybe they just distrust expertise, well I have a phd and I assure you it'll come up later. Maybe he's an immigrant from Russia and he just distrusts everything to do with the news, well that's not really fixable except maybe with many years of therapy. And yes it will come up later too. I'm not a professional, I didn't want to ask the specifics or get into the weeds, I just have a developed nose for these things. My brother is into conspiracy theories.
> I have a phd and I assure you it'll come up later.
Will it? One would have to dig pretty deep into one's personal life to learn about that. Someone who thinks COVID was a hoax isn't going to be one to dig deep. And, well, if he really did somehow dig deep enough to find that information, you can just laugh it off as a hoax.
> Someone who thinks COVID was a hoax isn't going to be one to dig deep.
This is kind of a side point, but people with fringe beliefs tend to dig a lot deeper to validate those opinions than those with a mainstream view.
You can bet that someone who thinks that the moon landing was a hoax to the point that they would tell someone about it will know more about the moon landing than a random person who believes it was real.
It often takes an expert in something to shoot down the arguments.
It's right on my linkedin, and I'm joining their team as a specialist/consultant.
Linkedin is editable, no? Maybe he could still find it in a cache if he digs deep enough, but I mean, really, it is highly unlikely that anyone is going to put in that much effort unless they are on a mission. Nobody casually cares.
Need ethos, logos and pathos. Not just the logos.
It's directionally correct but not entirely accurate IMO. It would be more accurate to say, your audience does not have the experience and context necessary to turn the facts into a decision criteria. You need to translate your "raw data facts" into "refined facts" ready for consumption by the audience. That's what a good communicator does. The original phrasing makes it almost sound like the decisions are not fact-based or emotional, which should elicit eye-rolls.
> It would be more accurate to say, your audience does not have the experience and context necessary to turn the facts into a decision criteria.
I don't agree. Humans are fundamentally social and illogical creatures, and in many cases regardless of the experience or context they have, they will make decisions based on social factors regardless of hard logic.
I think it does deserve eye roll, because it is huge oversimplification on itself. The situations in which you convince people with facts are not exactly rare.
That person is getting an eye roll, because they are just repeating popular phrase that is not even particularly useful.
I thought the new way was to just say "You're absolutely right" to any objection and then rephrase your original proposal without really changing it.
That just makes you sound like a weasel and destroys your trust.
It was a joke about how AI loves to tell you that you’re right but then it regurgitates its prior plan verbatim.
“Expert” doesn’t mean much anymore. They’re more likely than not to be under the control of their employers, their funders, or even their political ideology.
I recommend _Becoming a Technical Leader_ by Weinberg for a deeper take.
The software examples are dated, but the wetware observations and advice stands.
https://www.amazon.com/Becoming-Technical-Leader-Gerald-Wein...