13 ms·

How to Get Your Teammates to Follow Your Lead

186 points by BSVino 8y ago

TinyBig 8y ago
Curious if anyone here has seen success with the first step, "Get Approval From Leadership". I tend to favor "ask for forgiveness, not permission". Nobody is more resistant to change than middle management, so I tend to jump straight to small-scale adoption and coalition building.
- lgleason 8y ago
  agreed!
- mieseratte 8y ago
  Depends on how they're defining leadership in TFA, as it is vaguely written such that it could mean managers or it could mean technical-leaders, e.g. a team lead / tech lead type. If I have an idea that I know is correct / am sure of, I would broach it with the concerned folks. If I couldn't get them onboard, and was still sure I was right, I would discuss it with the senior engineers to get the feedback. If, at that point, I was still sure the idea was right I would try to once again try to convince the team of the merits, with the available appeal to authority. At that point you either win, give up, or try to convince management to enforce the idea.
- BSVino 8y ago
  Hello. Article author here. You can do this and it might be the appropriate approach in some situations, but you run the risk of degrading your reputation with management. Putting aside the personal risk, I tend to think of maintaining your reputation with your teammates as more important in the long run than accomplishing something or being right about any particular issue, since it preserves your ability to persuade them in the future. Also I've found that if management is resistant to change they usually have good reasons, even if sometimes they can't or won't share them, so circumventing them can sometimes be counter-productive. Usually better to just be on the up-and-up.
  - phkahler 8y ago
    Perhaps it's a subtle point but how do you contrast your comment with this part of the article: >> When I explain this process to junior team members, an objection is often, "I don't feel like I have the authority to do this. This is a job for our leadership." They feel that a person must be empowered to make a change before they can venture to do so. That's not true. Team members become senior not because they are deemed senior and granted senior responsibilities, but rather because they show that they're capable of effectively taking and addressing senior responsibilities.
    - BSVino 8y ago
      You make a good point. The junior team members I'm thinking about felt they didn't have the authority and so didn't approach leadership with a plan. I'm not saying they should assume responsibilities without direction of leadership, but rather that they can follow step 1 in the article regardless of their level in the organization. Even a senior person must follow the direction of leadership, the difference is that the senior person knows that they can approach leadership with a plan.
kevmo314 8y ago
> You can't gain the trust and respect of the entire team at once. You must start in a small area of your team and work outwards. It's best to begin with yourself. After all, how can you convince others to adopt your tool if you don't use it yourself? This is great if your proposed change is a workflow tool, but if it requires any code changes whatsoever (eg a new framework), the code review process reintroduces those strong opinions and you're back at square one, no matter how small the change.
- v-yadli 8y ago
  If, in the language of the article, you can crowdfund leadership capital from a few of them, you will have a much larger amount of spendable LC.
  - kevmo314 8y ago
    Often times leadership will ask for a demo before being convinced, which results in a catch-22. At least in my experience.
peterkelly 8y ago
Totally missing from the article is any notion that the tool or thing you're trying to push might not actually be a great idea. The assumption seems to be that the author was Right (TM) and all that remained to address was the challenge of getting others to see the one true path. If you're trying to convince others to make a change, and they're pushing back, listen to those concerns and revisit whether or not the change you're advocating makes sense. Maybe it does and they will come to see that, but you should also be open to considering their points of view and might change your opinion once you do. It's a two-way thing.
- marmaduke 8y ago
  The article is predicated on the suitability of the tool to be adopted, in the first paragraph, so he omission seems fine. Obviously there are cases where the tool being pushed isn’t right, but that’s a completely different albeit important discussion.
  - watwut 8y ago
    The opposition might have good reason to opposing you, despite you being convinced you are right initially. As in, while you are pushing for that thing, be willing to listen to them, especially to those in roles different then your role, in case you are just about to cause them problems. You will just do more damage otherwise.
    - deleted 8y ago
      [deleted]
- ricardobeat 8y ago
  The article addresses that in the starting paragraphs: there was no real opposition, just an unwillingness to compromise on how to do it. > Everyone agreed we should have Figlets, but nobody agreed about its configuration.
  - humanrebar 8y ago
biocomputation 8y ago
I feel like personal credibility is the only real way to get teammates to follow your lead. And that involves things like following your teammates lead as well. Collaboration is an art form.
partycoder 8y ago
The goal should not be to have people follow your lead. The goal should be: get your team to follow good ideas, and not follow bad ideas. No matter who proposed them. Smart people often have good ideas, but they can have bad ideas as well and a team needs to be prepared to reject them. Likewise, the lowest ranking person in the organization can have a trillion dollar idea and your organization should be prepared to profit from it. Then, no consensus building approach has a bulletproof guarantee that a consensus will happen.
- BSVino 8y ago
  Hello. Article author here. I agree, people should only follow good ideas. I didn't explicitly mention this in the article, but I believe that a person in a healthy work environment who genuinely follows the process of feedback as outlines will eventually turn their bad or mediocre ideas into good ideas as they integrate feedback, or else the leadership won't approve their change and the team will refuse to adopt the idea. After all, it's tough to get people to voluntarily adopt a bad idea.
  - newfoundglory 8y ago
    Unfortunately I've seen people much more eager to adopt a bad idea that is easier in the short term than a good idea that involves hard or boring work - like "should we refactoring and build on our existing code or throw it out and start again?", where people vote for throwing it out because "I don't even understand this code!"
busted 8y ago
Certainly agree with most of this. It has a couple of underlying ideas that I've also noticed. 1. Use empathy to both overcome resistance and do the right thing. The strategy in Step 2 for reframing an interaction in a way that gets the person to understand that you're trying to help them, and also reminds you to remove your ego and that the goal is to improve things for everyone, is one I've used a lot. Not because people think you're trying to be difficult but because it overcomes defensive barriers and helps ease them into the context switch of thinking about the problem. 2. Get a foothold with iterative progress. The author did this by splitting adoption and (the process for) configuration. Especially with tools and processes, people will often try to jump to the final state and if they can find any holes or issues with the proposal as is they'll be inclined to throw it all out at the start. If you instead make it clear that we're a) trying something new that will b) be improved as we learn more about it and c) can always be reversed if we decide it was a bad idea, people are usually much more open to it. One thing the article mentions though is "spending" leadership capital. I like instead to think of it as "investing" capital. If the decision you invested it in ends up being bad, you lose it. If it ends up making people's lives better, you've gained more. Thinking about it this way also can get junior people, as mentioned in the article, to be more inclined to help with decision making. They don't have a lot of capital to spend but they can choose to invest the little capital they have in order to grow it.
flyinglizard 8y ago
The point about leadership capital is excellent and stands very true.
- monkeydust 8y ago
  Agree, it's the concept I will takeaway from this piece.
- some_account 8y ago
  I agree, the writer put this process into very nice wording. I've seen other people use this process to gain informal leadership but I never saw it described in quite this way. Very nice.
hevi_jos 8y ago
Good leaders know if you want others doing something to you, you come first. If you want others following your lead, first you follow the lead of great leaders, listen to them, learn from them what makes them so great. Then you could be a great leader. From my point of view, the article is egocentric. Ego is one of the biggest enemies of good work. It should never be about following the leader blindly, specially if you manage(or co-work) smart, educated and experienced people, their opinions are of more value than yours in their areas of experience. With ego over the table it is only about who wins the argument, and of course it is always the boss(who is up in the hierarchical level). Beware because this introduces resentment and procrastination on the team. The article promotes this method, but this is not leadership, it is subjugation.
codingdave 8y ago
Or... first get the team to acknowledge the problem and agree that a fix is needed. Then have everyone research solutions. Propose your tool while asking what other solutions have been found. As a team, talk about the pros/cons of each option, and facilitate those discussions. Build consensus by listening and understanding what your team has to say. Once you agree on the solution, talk through the configuration questions. Then talk through a deployment and adoption plan. Because if you just want the problem fixed, then it isn't an issue of manipulating corporate politics to support your lead... it is an issue of working together to come up with a shared solution.
- lkrubner 8y ago
  But my co-workers might have strong emotional attachments to answers that I know are wrong. I might have a co-worker who promotes their favorite technology as the answer to all problems. I might already know, from previous battles, that particular people are going to distort the conversation in particular ways. If I'm going to go into a situation without trying to push a particular agenda, I'd have to be willing to let the wrong choice be made.
  - euroclydon 8y ago
    Robert Moses would never have let any of that happen. There’s a lot of hierarchy in companies, naturally. The team constructs are artificially induced.
    - ricardobeat 8y ago
      Is that the guy who inspired generations of architects and engineers to build inhumane car-centric cities, and wanted a six-lane highway crossing through Manhattan? A good example of determined management, yes, but what about the outcomes?
    - tacostakohashi 8y ago
      Maybe we work in different kinds of companies. In my experience with large corporates, sure we have hierarchy in the form of an org chart, managers and job titles / levels, but management very rarely enforce outcomes or resolve day-to-day disputes. When it comes to getting coworkers or other teams on board with a new workflow or tool, it's really completely up to powers of persuasion, providing good examples, documenting, and letting people move at their own pace. It can be frustrating to work through, but it's probably for the best, in the sense that it probably is genuinely the best tool or workflow that will win out over time, instead of the favorite of some senior person that doesn't know all the details.
chiefalchemist 8y ago
To Further Reading I would add: The Influential Mind By Tali Sharot It was on FT's shortlist for Best Book of 2017. https://upliftconnect.com/tali-sharot-influential-mind/ https://upliftconnect.com/tali-sharot-influential-mind/ --- That aside, tools, I would think, are a function of culture; and culture a function of leadership and hiring. Whether a tool is good for any individual - as the author presented in this article - is irrelevant. Either it improves the end product and satisfies leadership's lead (and target ROI of adoption) or it does not. That's not to say it will make adoption easy. But the less clear that foundation is the more friction there's going to be.
wwarner 8y ago
The most persuasive argument is no argument at all. Quality, speed and accuracy don't need advocates. If the idea is really good, just mentioning it is enough for the team to adopt it. If I think someone should adopt my style, my tool, my configuration, my editor or anything else, the first thing I ask myself is how does it compare to the most important thing that the team needs to advance on? If it's the most important thing, then I'll cajole the team to adopt the idea. A recent example of that for me is a particular way of running integration tests. But if it's not the most important thing, well then I'm just distracting myself and everyone else with another thing to do, and I try to get back to whatever is really important to my own progress.
qznc 8y ago
I don't like the term leadership capital because the analogy misses an important aspect: If the change turns out good, the leadership capital of the technical director increases to more than she had before. So she did not really "spend" it, but rather invest/bet it in/on Figlet. Also, it is not a single value. For different people the technical director has a different amount of leadership capital. If Figlet turns out good for you, it increases. If you don't like Figlet you consider the technical directors capital as lower. So the amount of capital is actually specific to a relationship between two people.
- hliyan 8y ago
  I was initially taken up with the elegance of the idea, but did a double take after your comment. We haven't really established that trust is transactional...
- darkerside 8y ago
  At the end of the article, the author explains that leaders move slowly, more slowly than they otherwise could, to allow their small changes to pay off before asking for more, thereby earning them more leadership capital. Which I think makes your point. Perhaps your disagreement is purely around the term capital. You may not realize that, in finance, the term capital implies that it is there to be invested. Good point about differing levels of trust between individuals, as opposed to groups. It's a nuance the article doesn't really broach.
JumpCrisscross 8y ago
An often-overlooked political tool is the one-on-one meeting. If you need to push a difficult decision, speak to decision-makers (this can include teammates) and convince them one by one. When it comes up for a group discussion, you will already have a winning proposal.
- lkrubner 8y ago
  Thank you for saying this. You've managed to condense down a lot of what I was trying to say in "One-on-one meetings are underrated, whereas group meetings waste time" http://www.smashcompany.com/business/one-on-one-meetings-are-underrated-whereas-group-meetings-waste-time http://www.smashcompany.com/business/one-on-one-meetings-are...
- dxhdr 8y ago
  Isn't this just classic office politics? Imagine you're pushing for the opposite decision and some other person is going around having closed door meetings with everyone to convince them otherwise. Maybe it's effective but man I'd rather not participate in an environment like that.
  - jungturk 8y ago
    Ideally its more about preflighting - making sure you've acknowledged all the relevant concerns from the eventual attendees - but its also a way to leverage herd mentality for better or worse. In the eventual group meeting folks will look around and notice that some portion of the attendees are on board already so they may be more inclined to agree.
  - slededit 8y ago
    You aren't going to have time to resolve everyone's concerns in one large meeting. One on ones are better for hashing out the idea and looking for compromises. Usually there is not some other person you are directly competing against - if there is then it's worth looking at the bigger picture of why you are competing in the first place when ostensibly your on the same team.
deleted 8y ago
[deleted]
tboyd47 8y ago
> It's not your job to convince your coworkers that your tool should be configured one way or another. That decision is owned by the team. It's only your job to get them to adopt the tool... "But lo! Men have become the tools of their tools..." I feel the author has missed the concept of leadership and is still thinking of it like an engineer. The idea of your team's opinions as "dangerous," or as obstacles you need to overcome to get your way, is not indicative of a leader to me, nor is the concept of actions as just a way to earn your team's trust ("Leadership Capital") so you can order them around later. That's a pretty myopic view of leadership bordering on sociopathy IMO. What is the point of influencing people? So much effort into convincing people, but why do you need to convince them? If you do not have a clear answer, or if your answer describes something about you and your views, sorry but you aren't a leader - you are only an opinionated person.

186 points by BSVino 8y ago

Curious if anyone here has seen success with the first step, "Get Approval From Leadership". I tend to favor "ask for forgiveness, not permission". Nobody is more resistant to change than middle management, so I tend to jump straight to small-scale adoption and coalition building.

lgleason 8y ago
agreed!
mieseratte 8y ago
Depends on how they're defining leadership in TFA, as it is vaguely written such that it could mean managers or it could mean technical-leaders, e.g. a team lead / tech lead type. If I have an idea that I know is correct / am sure of, I would broach it with the concerned folks. If I couldn't get them onboard, and was still sure I was right, I would discuss it with the senior engineers to get the feedback. If, at that point, I was still sure the idea was right I would try to once again try to convince the team of the merits, with the available appeal to authority. At that point you either win, give up, or try to convince management to enforce the idea.
BSVino 8y ago
Hello. Article author here. You can do this and it might be the appropriate approach in some situations, but you run the risk of degrading your reputation with management. Putting aside the personal risk, I tend to think of maintaining your reputation with your teammates as more important in the long run than accomplishing something or being right about any particular issue, since it preserves your ability to persuade them in the future. Also I've found that if management is resistant to change they usually have good reasons, even if sometimes they can't or won't share them, so circumventing them can sometimes be counter-productive. Usually better to just be on the up-and-up.
- phkahler 8y ago
  Perhaps it's a subtle point but how do you contrast your comment with this part of the article: >> When I explain this process to junior team members, an objection is often, "I don't feel like I have the authority to do this. This is a job for our leadership." They feel that a person must be empowered to make a change before they can venture to do so. That's not true. Team members become senior not because they are deemed senior and granted senior responsibilities, but rather because they show that they're capable of effectively taking and addressing senior responsibilities.
  - BSVino 8y ago
    You make a good point. The junior team members I'm thinking about felt they didn't have the authority and so didn't approach leadership with a plan. I'm not saying they should assume responsibilities without direction of leadership, but rather that they can follow step 1 in the article regardless of their level in the organization. Even a senior person must follow the direction of leadership, the difference is that the senior person knows that they can approach leadership with a plan.

kevmo314 8y ago

> You can't gain the trust and respect of the entire team at once. You must start in a small area of your team and work outwards. It's best to begin with yourself. After all, how can you convince others to adopt your tool if you don't use it yourself? This is great if your proposed change is a workflow tool, but if it requires any code changes whatsoever (eg a new framework), the code review process reintroduces those strong opinions and you're back at square one, no matter how small the change.

v-yadli 8y ago
If, in the language of the article, you can crowdfund leadership capital from a few of them, you will have a much larger amount of spendable LC.
- kevmo314 8y ago
  Often times leadership will ask for a demo before being convinced, which results in a catch-22. At least in my experience.

peterkelly 8y ago

Totally missing from the article is any notion that the tool or thing you're trying to push might not actually be a great idea. The assumption seems to be that the author was Right (TM) and all that remained to address was the challenge of getting others to see the one true path. If you're trying to convince others to make a change, and they're pushing back, listen to those concerns and revisit whether or not the change you're advocating makes sense. Maybe it does and they will come to see that, but you should also be open to considering their points of view and might change your opinion once you do. It's a two-way thing.

marmaduke 8y ago
The article is predicated on the suitability of the tool to be adopted, in the first paragraph, so he omission seems fine. Obviously there are cases where the tool being pushed isn’t right, but that’s a completely different albeit important discussion.
- watwut 8y ago
  The opposition might have good reason to opposing you, despite you being convinced you are right initially. As in, while you are pushing for that thing, be willing to listen to them, especially to those in roles different then your role, in case you are just about to cause them problems. You will just do more damage otherwise.
  - deleted 8y ago
    [deleted]
ricardobeat 8y ago
The article addresses that in the starting paragraphs: there was no real opposition, just an unwillingness to compromise on how to do it. > Everyone agreed we should have Figlets, but nobody agreed about its configuration.
- humanrebar 8y ago

biocomputation 8y ago

I feel like personal credibility is the only real way to get teammates to follow your lead. And that involves things like following your teammates lead as well. Collaboration is an art form.

partycoder 8y ago

The goal should not be to have people follow your lead. The goal should be: get your team to follow good ideas, and not follow bad ideas. No matter who proposed them. Smart people often have good ideas, but they can have bad ideas as well and a team needs to be prepared to reject them. Likewise, the lowest ranking person in the organization can have a trillion dollar idea and your organization should be prepared to profit from it. Then, no consensus building approach has a bulletproof guarantee that a consensus will happen.

BSVino 8y ago
Hello. Article author here. I agree, people should only follow good ideas. I didn't explicitly mention this in the article, but I believe that a person in a healthy work environment who genuinely follows the process of feedback as outlines will eventually turn their bad or mediocre ideas into good ideas as they integrate feedback, or else the leadership won't approve their change and the team will refuse to adopt the idea. After all, it's tough to get people to voluntarily adopt a bad idea.
- newfoundglory 8y ago
  Unfortunately I've seen people much more eager to adopt a bad idea that is easier in the short term than a good idea that involves hard or boring work - like "should we refactoring and build on our existing code or throw it out and start again?", where people vote for throwing it out because "I don't even understand this code!"

busted 8y ago

Certainly agree with most of this. It has a couple of underlying ideas that I've also noticed. 1. Use empathy to both overcome resistance and do the right thing. The strategy in Step 2 for reframing an interaction in a way that gets the person to understand that you're trying to help them, and also reminds you to remove your ego and that the goal is to improve things for everyone, is one I've used a lot. Not because people think you're trying to be difficult but because it overcomes defensive barriers and helps ease them into the context switch of thinking about the problem. 2. Get a foothold with iterative progress. The author did this by splitting adoption and (the process for) configuration. Especially with tools and processes, people will often try to jump to the final state and if they can find any holes or issues with the proposal as is they'll be inclined to throw it all out at the start. If you instead make it clear that we're a) trying something new that will b) be improved as we learn more about it and c) can always be reversed if we decide it was a bad idea, people are usually much more open to it. One thing the article mentions though is "spending" leadership capital. I like instead to think of it as "investing" capital. If the decision you invested it in ends up being bad, you lose it. If it ends up making people's lives better, you've gained more. Thinking about it this way also can get junior people, as mentioned in the article, to be more inclined to help with decision making. They don't have a lot of capital to spend but they can choose to invest the little capital they have in order to grow it.

flyinglizard 8y ago

The point about leadership capital is excellent and stands very true.

monkeydust 8y ago
Agree, it's the concept I will takeaway from this piece.
some_account 8y ago
I agree, the writer put this process into very nice wording. I've seen other people use this process to gain informal leadership but I never saw it described in quite this way. Very nice.

hevi_jos 8y ago

Good leaders know if you want others doing something to you, you come first. If you want others following your lead, first you follow the lead of great leaders, listen to them, learn from them what makes them so great. Then you could be a great leader. From my point of view, the article is egocentric. Ego is one of the biggest enemies of good work. It should never be about following the leader blindly, specially if you manage(or co-work) smart, educated and experienced people, their opinions are of more value than yours in their areas of experience. With ego over the table it is only about who wins the argument, and of course it is always the boss(who is up in the hierarchical level). Beware because this introduces resentment and procrastination on the team. The article promotes this method, but this is not leadership, it is subjugation.

codingdave 8y ago

Or... first get the team to acknowledge the problem and agree that a fix is needed. Then have everyone research solutions. Propose your tool while asking what other solutions have been found. As a team, talk about the pros/cons of each option, and facilitate those discussions. Build consensus by listening and understanding what your team has to say. Once you agree on the solution, talk through the configuration questions. Then talk through a deployment and adoption plan. Because if you just want the problem fixed, then it isn't an issue of manipulating corporate politics to support your lead... it is an issue of working together to come up with a shared solution.

lkrubner 8y ago
But my co-workers might have strong emotional attachments to answers that I know are wrong. I might have a co-worker who promotes their favorite technology as the answer to all problems. I might already know, from previous battles, that particular people are going to distort the conversation in particular ways. If I'm going to go into a situation without trying to push a particular agenda, I'd have to be willing to let the wrong choice be made.
- euroclydon 8y ago
  Robert Moses would never have let any of that happen. There’s a lot of hierarchy in companies, naturally. The team constructs are artificially induced.
  - ricardobeat 8y ago
    Is that the guy who inspired generations of architects and engineers to build inhumane car-centric cities, and wanted a six-lane highway crossing through Manhattan? A good example of determined management, yes, but what about the outcomes?
  - tacostakohashi 8y ago
    Maybe we work in different kinds of companies. In my experience with large corporates, sure we have hierarchy in the form of an org chart, managers and job titles / levels, but management very rarely enforce outcomes or resolve day-to-day disputes. When it comes to getting coworkers or other teams on board with a new workflow or tool, it's really completely up to powers of persuasion, providing good examples, documenting, and letting people move at their own pace. It can be frustrating to work through, but it's probably for the best, in the sense that it probably is genuinely the best tool or workflow that will win out over time, instead of the favorite of some senior person that doesn't know all the details.

chiefalchemist 8y ago

To Further Reading I would add: The Influential Mind By Tali Sharot It was on FT's shortlist for Best Book of 2017. https://upliftconnect.com/tali-sharot-influential-mind/ https://upliftconnect.com/tali-sharot-influential-mind/ --- That aside, tools, I would think, are a function of culture; and culture a function of leadership and hiring. Whether a tool is good for any individual - as the author presented in this article - is irrelevant. Either it improves the end product and satisfies leadership's lead (and target ROI of adoption) or it does not. That's not to say it will make adoption easy. But the less clear that foundation is the more friction there's going to be.

wwarner 8y ago

The most persuasive argument is no argument at all. Quality, speed and accuracy don't need advocates. If the idea is really good, just mentioning it is enough for the team to adopt it. If I think someone should adopt my style, my tool, my configuration, my editor or anything else, the first thing I ask myself is how does it compare to the most important thing that the team needs to advance on? If it's the most important thing, then I'll cajole the team to adopt the idea. A recent example of that for me is a particular way of running integration tests. But if it's not the most important thing, well then I'm just distracting myself and everyone else with another thing to do, and I try to get back to whatever is really important to my own progress.

qznc 8y ago

I don't like the term leadership capital because the analogy misses an important aspect: If the change turns out good, the leadership capital of the technical director increases to more than she had before. So she did not really "spend" it, but rather invest/bet it in/on Figlet. Also, it is not a single value. For different people the technical director has a different amount of leadership capital. If Figlet turns out good for you, it increases. If you don't like Figlet you consider the technical directors capital as lower. So the amount of capital is actually specific to a relationship between two people.

hliyan 8y ago
I was initially taken up with the elegance of the idea, but did a double take after your comment. We haven't really established that trust is transactional...
darkerside 8y ago
At the end of the article, the author explains that leaders move slowly, more slowly than they otherwise could, to allow their small changes to pay off before asking for more, thereby earning them more leadership capital. Which I think makes your point. Perhaps your disagreement is purely around the term capital. You may not realize that, in finance, the term capital implies that it is there to be invested. Good point about differing levels of trust between individuals, as opposed to groups. It's a nuance the article doesn't really broach.

JumpCrisscross 8y ago

An often-overlooked political tool is the one-on-one meeting. If you need to push a difficult decision, speak to decision-makers (this can include teammates) and convince them one by one. When it comes up for a group discussion, you will already have a winning proposal.

lkrubner 8y ago
Thank you for saying this. You've managed to condense down a lot of what I was trying to say in "One-on-one meetings are underrated, whereas group meetings waste time" http://www.smashcompany.com/business/one-on-one-meetings-are-underrated-whereas-group-meetings-waste-time http://www.smashcompany.com/business/one-on-one-meetings-are...
dxhdr 8y ago
Isn't this just classic office politics? Imagine you're pushing for the opposite decision and some other person is going around having closed door meetings with everyone to convince them otherwise. Maybe it's effective but man I'd rather not participate in an environment like that.
- jungturk 8y ago
  Ideally its more about preflighting - making sure you've acknowledged all the relevant concerns from the eventual attendees - but its also a way to leverage herd mentality for better or worse. In the eventual group meeting folks will look around and notice that some portion of the attendees are on board already so they may be more inclined to agree.
- slededit 8y ago
  You aren't going to have time to resolve everyone's concerns in one large meeting. One on ones are better for hashing out the idea and looking for compromises. Usually there is not some other person you are directly competing against - if there is then it's worth looking at the bigger picture of why you are competing in the first place when ostensibly your on the same team.

deleted 8y ago

[deleted]

tboyd47 8y ago

> It's not your job to convince your coworkers that your tool should be configured one way or another. That decision is owned by the team. It's only your job to get them to adopt the tool... "But lo! Men have become the tools of their tools..." I feel the author has missed the concept of leadership and is still thinking of it like an engineer. The idea of your team's opinions as "dangerous," or as obstacles you need to overcome to get your way, is not indicative of a leader to me, nor is the concept of actions as just a way to earn your team's trust ("Leadership Capital") so you can order them around later. That's a pretty myopic view of leadership bordering on sociopathy IMO. What is the point of influencing people? So much effort into convincing people, but why do you need to convince them? If you do not have a clear answer, or if your answer describes something about you and your views, sorry but you aren't a leader - you are only an opinionated person.