How to Get Your Teammates to Follow Your Lead | Hacker News Reader

How to Get Your Teammates to Follow Your Lead

workaguide.com

186 pointsBSVino49 comments

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.

My thoughts exactly. In particular, a lot of the reason for the best process (which is not too different from what the author lays out in this article) is not to enable adoption in the case that the change is a good one, but rather minimizing the damage in the case that it turns out not to be the case. Having a dictatorial leader issue directives that all turn out to be exactly correct is annoying, but not horrible, and probably will NOT actually result in rebellion, as they say. On the other hand, using that method for a decision that turns out to be the wrong one, at least for that team and that project, will maximize the damage. Getting the right process for minimizing the damage of a bad decision is much harder, and much more important, than the relatively simple one of enabling a good decision.

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.

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

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.

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.

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.

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.

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.

Catastrophic decisions are rarely as bad as they sound. You lose time and resources resolving them, maybe lose some customers, and possibly even data. Yes, this sucks. You also learn a valuable lesson. This makes your team stronger.

Much worse is a series of mediocre decisions that you can live with, but compound over time to slow you down. You never really learn what's going wrong, your team doesn't improve. Give me the former, painful though it may be in the moment.

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.

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.

> the effort of having the debate is much more time and resource-intensive than just accepting one of the solutions.

Man, have you ever seen bad code?

For an example, suppose someone comes up with the idea of making dozens of mini-modules with poorly defined interfaces, each one having no clue about what's going on globally, that should somehow contribute to solving a simple problem. Each interacts with each other through some sort of worm hole where you have only a vague idea what's on the other side.

Another possibility is to look at the requirements as a whole and write a single module that solves the problem in a straightforward way. Now, should one accept the first idea and write 3 or 4 times the amount of hard to code, the code being unmaintainable because the interactions between the many moving parts are very hard to understand? Just because everybody thinks that's how it should be done?

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.

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.

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.

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?

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.

If you have a high degree of confidence in your solution, then this seems like an unnecessary introduction of uncertainty, indicating a lack of leadership. Your team will start having the wrong discussion and invest their time in a fractured way, leading to frustration down the road. Why waste your team's time like this?

OTOH, if you don't trust the solution you have with a high degree of certainty, absolutely gather your team's input.

The corollary is, if you don't already know your team extremely well, how is it that your degree of certainty is high?

Sounds like design by committee...

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.

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.

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.

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.

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.

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.

agreed!

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

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

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.

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/

---

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.

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

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.

Often times leadership will ask for a demo before being convinced, which results in a catch-22. At least in my experience.

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

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.

Agree, it's the concept I will takeaway from this piece.

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.

Reply on news.ycombinator.com