
How to Get Your Teammates to Follow Your Lead - BSVino
https://www.workaguide.com/blog/2018/6/15/how-to-get-your-teammates-to-follow-your-lead
======
peterkelly
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.

~~~
ricardobeat
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
Then Figlets was not a solution by itself. Just an implementation detail. By
analogy, you can't say "we need a graph data structure", agree on python as a
language, then consider the actual computer science an implementation detail
that is being bickered over.

For a code review tool, "details" like CI integration, approval process,
deployment integration, etc. _are_ the solution. Figlets is just a shortcut
for a big piece of that. Figlets could even be a blocker for certain features
(like being to review code without a VPN connection).

------
codingdave
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
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.

~~~
ozim
Yes and the biggest possible win you can make is to let go off your own "good
solution". Beeing humble and dealing with problems later in lieu of beeing
always right is correct choice.

You have to prevent only catastrophic decisions.

If you are working on CRUD web platform most decisions will not be
catastrophic. Maybe inconvenient, maybe eat more budget but probably company
will not go under because of some technical decision.

~~~
lkrubner
Your answer is idealistic in a very limited way. You are suggesting that their
is moral value in being humble and accepting the input of other people. I'll
point out that it is even more moral to fight for what you know is right, and
it is not moral to retreat from the fight simply because it is exhausting or
tedious or repetitive or badly managed or the odds are lopsided. Over the last
20 years I've run into people with your attitude many times. I believe I
understand your argument -- that sometimes we have to accept outcomes that we
disagree with. However, what my life has taught me is that their is no valor
in being passive while bad decisions are made. When I'm hired, I've been hired
as an experienced professional whose advice is valuable, therefore I have an
ethical obligation to fight as hard as I possibly can to be sure what I've
learned over the years ends up benefiting the company. That is what I'm paid
for. Passive acceptance of bad outcomes is neither ethical nor moral. We each
have an obligation to fight as much as we can for what we know to be right. In
the professional context, that is what we are being paid for.

As a practical matter, "be humble and accept the input of others" quickly
shades over into "be lazy and allow stupid people to dominate the meeting,
because letting them dominate the meeting is easier than fighting them." I
agree it is easier, but it is unethical to accept money while allowing bad
decisions to be made.

~~~
turingcompeteme
You seem to be focusing on a situation where there is a proposed solution with
an obvious bad outcome, and somehow you are the only one smart enough to
realize it will lead to a bad outcome.

In my experience this is very rarely the actual case. Usually there are
multiple viewpoints, multiple solutions, and while some may be slightly better
than others, the effort of having the debate is much more time and resource-
intensive than just accepting one of the solutions.

~~~
lkrubner
By definition the answer you think best is the answer that all of your skills
and all of your experiences guide you to. I’m saying you have an obligation to
fight for what you know is the right answer. There is nothing ethical about
allowing people to make decisions that you believe will be catastrophic. You
are being paid for your expertise — don’t accept money if you are not willing
to do what you can to ensure a good outcome.

This has nothing to do with having a debate in a meeting, indeed, often the
best strategy is to avoid the meeting altogether.

~~~
ozim
Yes, agreed but that is what I also wrote, you should prevent catastrophic
outcomes. I did not wrote anything what you implied in previous comment. I
only implied that there is many technical decisions which are nowhere near to
catastrophic.

Like picking tabs vs spaces, I am not going to fight about it, it is not a
decision that will make any difference for product.

------
busted
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.

------
TinyBig
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.

~~~
BSVino
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
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
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.

------
JumpCrisscross
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.

~~~
dxhdr
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
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.

------
partycoder
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
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
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!"

------
tboyd47
> 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.

------
hevi_jos
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.

------
qznc
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.

~~~
darkerside
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.

------
wwarner
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.

------
chiefalchemist
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.

------
kevmo314
> 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
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
Often times leadership will ask for a demo before being convinced, which
results in a catch-22. At least in my experience.

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

~~~
some_account
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.

------
biocomputation
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.

