How to Get Your Teammates to Follow Your Lead • Hacker News Board

Re: How to Get Your Teammates to Follow Your Lead

#41

Post by turingcompeteme » Sun, Jun 17, 2018, 3:07 PM UTC

lkrubner wrote: post #39

ozim wrote: post #29

Earlier quoted context omitted.

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 technica…

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…

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.

Re: How to Get Your Teammates to Follow Your Lead

#42

Post by dxhdr » Sun, Jun 17, 2018, 3:20 PM UTC

JumpCrisscross wrote: post #36

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.

Re: How to Get Your Teammates to Follow Your Lead

#43

Post by [deleted] » Sun, Jun 17, 2018, 3:25 PM UTC

[deleted]

Re: How to Get Your Teammates to Follow Your Lead

#44

Post by jungturk » Sun, Jun 17, 2018, 3:30 PM UTC

dxhdr wrote: post #42

JumpCrisscross wrote: post #36

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.

Re: How to Get Your Teammates to Follow Your Lead

#45

Post by kylequest » Sun, Jun 17, 2018, 4:22 PM UTC

codingdave wrote: post #20

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 quest…

Sounds like design by committee...

Re: How to Get Your Teammates to Follow Your Lead

#46

Post by kevmo314 » Sun, Jun 17, 2018, 4:49 PM UTC

v-yadli wrote: post #6

kevmo314 wrote: post #5

> 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 thos…

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.

Re: How to Get Your Teammates to Follow Your Lead

#47

Post by tboyd47 » Sun, Jun 17, 2018, 5:16 PM UTC

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

Re: How to Get Your Teammates to Follow Your Lead

#48

Post by lkrubner » Sun, Jun 17, 2018, 5:32 PM UTC

turingcompeteme wrote: post #41

lkrubner wrote: post #39

Earlier quoted context omitted.

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…

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-in…

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.

Re: How to Get Your Teammates to Follow Your Lead

#49

Post by ozim » Sun, Jun 17, 2018, 6:02 PM UTC

lkrubner wrote: post #48

turingcompeteme wrote: post #41

Earlier quoted context omitted.

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-in…

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 g…

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.

Re: How to Get Your Teammates to Follow Your Lead

#50

Post by jstimpfle » Sun, Jun 17, 2018, 6:13 PM UTC

turingcompeteme wrote: post #41

lkrubner wrote: post #39

Earlier quoted context omitted.

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…

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-in…

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