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'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.
In my most recent role I only pulled rank twice in more than 3 years. Both times, reluctantly and deliberately. I agree you want to build a LOT of trust and legitimacy before you do this and you can still build concensus once you've dictated a direction or path. Lead, don't micro-manage.
> 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.
“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.
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.
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.
There's both less and more to making decisions than ensuring they get made.
First: get others to actually decide. Jean-Louis Gassee at Apple (componentized mac's in the late 1980's) said that when dueling managers brought him a decision to make, he would always come up with a decision both of them hated, so they would scurry away and work together with an alternative they could live with.
Second: be sure to get everyone really on board - you first. This is really hard for managers who are following the wind. Law students are often careful and analytical, hedging every evaluation, but lawyers have to be assertive. Although they understand the precariousness of the legal position, it only works if you convince everyone (on your side and theirs) that this is how it will be. That transition is typically what weeds out new attorneys, and distinguishes partners from associates.
(Before you object to the attorney analogy: it's nice when you achieve collegial scientific consensus, but it can be a luxury. Then you have to figure out how to compel people do want they don't want to do, without straining authority. Usually it works to focus on picking a customer, or a definite time for results to appear; a more concrete objective/goal explains the decision and focuses follow-through.)
I have my claim to a minute expertise in this domain. Was assigned to lead an initiative for something that was not achieved in 3 prior attempts. I was given the 6 strongest, most genius engineers from 6 different teams. Everyone, including me, was quite opinionated and with a great explanation for their opinion. It was not an explicit credo, but I made it my position to leverage the mirror of the saying “don’t interrupt your enemy when they make a mistake”. For us it would be, “don’t interrupt your friend when they make something great” with the corollary “do something else, and make it great”. There were other important parts to that like finding the organic separation of duties and teasing or nudging directions, accepting suboptimal valleys in places, etc. But it worked, and I am as proud as I can be for being lucky. Rooms of geniuses are challenging but also such a great opportunity to learn from each other and learn how to collectively optimise the boundaries to focus on disagreement only where it makes sense.
When I'm a decision maker, I tell people there are two types of conversations we could be having and it's absolutely essential that we're both clear which one we both think we're having:
1. There's a piece of information you know which, you believe, if I knew it, it would cause me to change my decision
2. We are operating from the same world of facts but if you were in my shoes, you would choose to make a different decision because of a different in priorities/values/attitude/etc.
I think "disagree and commit" has been abused to excuse a litany of absolutely heinous behaviors in tech but my most charitable interpretation of that philosophy is that if we're both in agreement that we're having conversation #2, then the only actionable steps forward are to either agree to change who the decision maker is in the moment (which should only ever be done in the rarest of circumstances) or you need to acknowledge that you've been heard, I disagree and you need to commit.
IMO, one of the more toxic but often under addressed traits for someone in the team is them wanting all of the power of a decision maker with none of the responsibility. They will spend their time endlessly dissecting how "bone headed" the choices by management are and how we're "obviously ruled by incompetents" but when asked to take on any of the mantle of responsibility to fix any of the issues they see, they instinctively shy away because they're afraid of being judged as harshly by others as they judge.
My more radical belief is that the easiest default path for any team to go down is to say that it's the leader's job to make sure everybody on the team is ok with the decision but that this is an anti-pattern and it's actually up to the subordinates to develop the emotional maturity to understand that decisions will sometimes not go their way and the course charted might be completely baffling or insane to them but if you want that never to happen, then you should be the decision maker.
But the root of making this a successful culture has to be a consistent and mature retro process which is astonishingly hard to pull off which is why it's so rare. The retro is the proper time to judge whether decision making ability is being placed in the right hands or not:
* Did the decision meet, exceed or fall short of our expectations?
* Did it fall short because something within the control of the company/team or outside of the control?
* If inside the control, was there some piece of missing information, which, when revealed in retrospect, would have changed the decision?
* Was the information obtainable at the time? Why didn't we obtain it? Are there changes to the process we should make to learn from this for next time?
The best we can hope for is not perfect decision makers, it's people who can run an effective retro process, learn from their mistakes and steadily increase the quality of their decisions over time. Inability to do that should be the primary reasons someone is removed from their decision making role.
The root problem is not misunderstanding but not trusting each other. When the team implementing something says it is two weeks while the other team believes it should be just a day - in a world with full trust the second team would just accept that the first team has more expertise. But why should the teams trust each other? There is always the option that the estimation is not based on the real work required - but just an attempt to get some slack.
With translation you can show that there is a depth of arguments for that or that position - this is improving the trust.
The shift from "expert with answers" to "facilitator of clarity" is something a lot of leads struggle with, especially when they get promoted because they were the smartest dev on the team
Stealing the terms "expert with answers" and "facilitator of clarity." Those are brilliant ways to distinguish those roles. (Complicated by the fact that sometimes you have to switch between these constantly within the same role.)
Thank you for the post. I was promoted to lead developer and its been year now.
I couldn't figure out my exact role and responsibility but I've been aligned with many things you mentioned in your post, that's a relief.
Coincidentally, I went through that post about "How I, a non-developer, read the tutorial" few days ago and we share the same thoughts. Hopefully am on the right direction.
I've been part of three software-adjacent product development teams where the Lead did exactly this and it did not go well all three times.
Having been team lead a few times myself now, I have learned that I am not there to be a field marshal. I'm there to act as a hub or conduit for all the other parts of the team. When they clash, I help resolve the conflict. When they question, I help assuage concerns. When they have ideas, I help evaluate the value of implementation. When they need resources, I approach the right people and do what I can. When they fuck up, I take the heat and rally them to help fix the problem.
It took me over a decade to learn this. I'm not the best. My name is unrecognized, for the most part, outside of some very specific circles. But I find that being part of the team rather than some imaginary demagogue to them yields consistently good results with significantly lower risk of talent loss and helps avoid over-promising/under-delivering.
The article does a nice job of pointing a few things out that I find essential in good leadership, but one thing in particular is saying "I don't know, but let's figure it out." Not only does it give your experts permission to be uncertain and helps avoid the trappings of getting defensive, as the author mentions, but it also reminds them they are not alone in this fight. That's powerful.
I'm sure many of you reading this have felt unsupported by your leaders in the past, a cog in a machine that will stress you to the point of breaking and simply replace you with another when that inevitably happens. Maybe my experience as a tech/troubleshooter colors my view here, but people, just like machines, need to be cared for if you want them to keep operating at a level that allows them to make a meaningful contribution to the team.
> Leadership in technical environments isn't about being the smartest person in the room. It's about being the most effective translator.
Only if you don't make the final decision, but if you do, you better be the smartest person in the room by far. Otherwise, you're not a leader but a post turtle.
30 comments
[ 2.9 ms ] story [ 67.6 ms ] threadThe software examples are dated, but the wetware observations and advice stands.
https://www.amazon.com/Becoming-Technical-Leader-Gerald-Wein...
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.
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.
God I hate modern web sometimes
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.
And the most valuable trait it's being a good translator, and not just for this job but almost anyone.
First: get others to actually decide. Jean-Louis Gassee at Apple (componentized mac's in the late 1980's) said that when dueling managers brought him a decision to make, he would always come up with a decision both of them hated, so they would scurry away and work together with an alternative they could live with.
Second: be sure to get everyone really on board - you first. This is really hard for managers who are following the wind. Law students are often careful and analytical, hedging every evaluation, but lawyers have to be assertive. Although they understand the precariousness of the legal position, it only works if you convince everyone (on your side and theirs) that this is how it will be. That transition is typically what weeds out new attorneys, and distinguishes partners from associates.
(Before you object to the attorney analogy: it's nice when you achieve collegial scientific consensus, but it can be a luxury. Then you have to figure out how to compel people do want they don't want to do, without straining authority. Usually it works to focus on picking a customer, or a definite time for results to appear; a more concrete objective/goal explains the decision and focuses follow-through.)
1. There's a piece of information you know which, you believe, if I knew it, it would cause me to change my decision
2. We are operating from the same world of facts but if you were in my shoes, you would choose to make a different decision because of a different in priorities/values/attitude/etc.
I think "disagree and commit" has been abused to excuse a litany of absolutely heinous behaviors in tech but my most charitable interpretation of that philosophy is that if we're both in agreement that we're having conversation #2, then the only actionable steps forward are to either agree to change who the decision maker is in the moment (which should only ever be done in the rarest of circumstances) or you need to acknowledge that you've been heard, I disagree and you need to commit.
IMO, one of the more toxic but often under addressed traits for someone in the team is them wanting all of the power of a decision maker with none of the responsibility. They will spend their time endlessly dissecting how "bone headed" the choices by management are and how we're "obviously ruled by incompetents" but when asked to take on any of the mantle of responsibility to fix any of the issues they see, they instinctively shy away because they're afraid of being judged as harshly by others as they judge.
My more radical belief is that the easiest default path for any team to go down is to say that it's the leader's job to make sure everybody on the team is ok with the decision but that this is an anti-pattern and it's actually up to the subordinates to develop the emotional maturity to understand that decisions will sometimes not go their way and the course charted might be completely baffling or insane to them but if you want that never to happen, then you should be the decision maker.
But the root of making this a successful culture has to be a consistent and mature retro process which is astonishingly hard to pull off which is why it's so rare. The retro is the proper time to judge whether decision making ability is being placed in the right hands or not:
* Did the decision meet, exceed or fall short of our expectations?
* Did it fall short because something within the control of the company/team or outside of the control?
* If inside the control, was there some piece of missing information, which, when revealed in retrospect, would have changed the decision?
* Was the information obtainable at the time? Why didn't we obtain it? Are there changes to the process we should make to learn from this for next time?
The best we can hope for is not perfect decision makers, it's people who can run an effective retro process, learn from their mistakes and steadily increase the quality of their decisions over time. Inability to do that should be the primary reasons someone is removed from their decision making role.
With translation you can show that there is a depth of arguments for that or that position - this is improving the trust.
I couldn't figure out my exact role and responsibility but I've been aligned with many things you mentioned in your post, that's a relief.
Coincidentally, I went through that post about "How I, a non-developer, read the tutorial" few days ago and we share the same thoughts. Hopefully am on the right direction.
Having been team lead a few times myself now, I have learned that I am not there to be a field marshal. I'm there to act as a hub or conduit for all the other parts of the team. When they clash, I help resolve the conflict. When they question, I help assuage concerns. When they have ideas, I help evaluate the value of implementation. When they need resources, I approach the right people and do what I can. When they fuck up, I take the heat and rally them to help fix the problem.
It took me over a decade to learn this. I'm not the best. My name is unrecognized, for the most part, outside of some very specific circles. But I find that being part of the team rather than some imaginary demagogue to them yields consistently good results with significantly lower risk of talent loss and helps avoid over-promising/under-delivering.
The article does a nice job of pointing a few things out that I find essential in good leadership, but one thing in particular is saying "I don't know, but let's figure it out." Not only does it give your experts permission to be uncertain and helps avoid the trappings of getting defensive, as the author mentions, but it also reminds them they are not alone in this fight. That's powerful.
I'm sure many of you reading this have felt unsupported by your leaders in the past, a cog in a machine that will stress you to the point of breaking and simply replace you with another when that inevitably happens. Maybe my experience as a tech/troubleshooter colors my view here, but people, just like machines, need to be cared for if you want them to keep operating at a level that allows them to make a meaningful contribution to the team.
Only if you don't make the final decision, but if you do, you better be the smartest person in the room by far. Otherwise, you're not a leader but a post turtle.