8 ms·

How to Lead in a Room Full of Experts

459 points by jnord 1y ago

readthenotes1 1y ago
I recommend _Becoming a Technical Leader_ by Weinberg for a deeper take. The software examples are dated, but the wetware observations and advice stands. https://www.amazon.com/Becoming-Technical-Leader-Gerald-Weinberg-ebook/dp/B004J4VV3I?adgrpid=168226348068&dib=eyJ2IjoiMSJ9.sga-KWcXDoUlZwD_arEqDOsKUiy-uFb3W48As9ypNaR2tTYQEbfnuthQdHr06E4xv0eheQwKyGamd-BefPYnlI5uDm9HshO9QMLMzM-or42PwrFFvts83SNjtEvzcKq9n9IEMx7-d5FhEw_Fzq4EDdxPgTX-BKMeAOEaDYWCstsxXmPYh-Y0VVCiYZt5wCsrnMU_kiTSX6CEr9a9P8uqDA.3IIJ2zkv39La1ny2dXDaGGHf8k9JfD81tkPsn10gDMg&dib_tag=se&hvadid=692991596066&hvdev=m&hvexpln=68&hvlocphy=9026903&hvnetw=g&hvocijid=8863768339482205152--&hvqmt=e&hvrand=8863768339482205152&hvtargid=kwd-301019296031&hydadcr=15806_13521449&keywords=becoming+a+technical+leader&mcid=3e31625d999f3ff387331e5c128dd5da&qid=1758723421&s=books&sr=1-1 https://www.amazon.com/Becoming-Technical-Leader-Gerald-Wein...
jamiecurle 1y ago
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.
- bluGill 1y ago
  Probably better to say "because it is a bikeshed not worth debate". Often there isn't a right answer but a decision is needed.
  - potato3732842 1y ago
    I like to use something along the lines of "anyone in this room is capable of handling the minutia satisfactorily, there is no need to waste time on the details".
ahmedfromtunis 1y ago
"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.
- Aurornis 1y ago
  This is a lesson I learned the hard way. When I was a first time manager I had the naive idea that I was going to build consensus for everything and get everyone to come to an agreement naturally. It worked at first with a good team. Then later I inherited a fragment of another team with some older know-it-all engineers who thought everything modern was garbage and we should be doing everything like they did 25 years ago. I wasted too much time letting them stonewall everything while thinking we’d eventually reach a consensus. Then at some point you realize you have to put your foot down and pick a direction after they’ve had a chance to state their position.
  - wahnfrieden 1y ago
    You could learn from consent based decision making, a hallmark of sociocratic worker coops that is underrated and can be applied elsewhere. Hierarchy and coercion isn't necessary for avoiding decision paralysis in organizations. It appears to be the practical route but has all sorts of harmful and counterproductive consequences. https://www.sociocracyforall.org/consent-decision-making/ https://www.sociocracyforall.org/consent-decision-making/
    - AnimalMuppet 1y ago
      Interesting. For that to work, though, it has to be true consent, not "it's the boss's idea and I don't dare to object out loud". But I guess, if that's the environment you're in, then you're stuck with autocratic leadership (no matter what label it claims for itself), and your only choice is to leave or not.
wavemode 1y ago
> 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.
- everdrive 1y ago
  This is a difficult lesson to swallow, but must be understood. I do still retain some frustration that there does not seem to be more effort to correct for this problem locally. For instance, in general you must speak to your audience and make emotional appeals. But me, your boss, should understand how to look past that and work with the facts, at least to the degree possible. I don't see much of that.
  - tux3 1y ago
    There are places that have this norm, but it's exceedingly rare, and it's not some perfect utopia. We're all susceptible to emotional appeals to different degrees, and emotions aren't some inconvenience that you should try to eliminate in favor of pure cold calculations, they also have a place and a reason to be. People care about different things, so trying to focus just on facts can end up with people talking past each other, because they have different goals, value systems, or other fuzzy human feelings that can't be graphed in an Excel spreadsheet and compared numerically. I'm not saying that emotional appeals and sophistry are fine, but I find that often when people accept an emotional appeal over a cold purely factual argument, it's because the factual argument is missing the point. A more important part of the discussion is understanding what other people actually care about to make sure we're not all talking past each other, or spending hours arguing details that won't matter in the end.
- Herring 1y ago
  You need to get a better audience. I recently met a good developer who still thinks Covid was a hoax. Doing my best to avoid him. You think you can just politely work around him -- that's how you get vaccine skeptics dismantling the CDC.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
bilsbie 1y ago
“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.
- malshe 1y ago
  100% agree. I would further add that occasionally being perceived as an expert can be bad. When I sense this type of crowd, I take Norm Macdonald's approach and pretend that I barely know anything.
SoftTalker 1y ago
I thought the new way was to just say "You're absolutely right" to any objection and then rephrase your original proposal without really changing it.
- gwbas1c 1y ago
  That just makes you sound like a weasel and destroys your trust.
  - illusive4080 1y ago
    It was a joke about how AI loves to tell you that you’re right but then it regurgitates its prior plan verbatim.
physicsguy 1y ago
> When the product team requests a "simple" feature, I'm thinking about the 3 teams that need to be involved to update the necessary microservices. God I hate modern web sometimes
- fladrif 1y ago
  What's the alternative?
  - moffkalast 1y ago
    Macroservices, or several megaliths instead of one monolith, if you will.
    - Rendello 1y ago
      What about going the other way and Unix-piping together hundreds of thousands of nano-services?
      - sally_glance 1y ago
        I think it's called serverless or FaaS today? But why choose, just do all three at the same time! Actually you don't even have to choose, it will naturally happen when transitions are never fully completed... So before you know it you're stuck with a partially integrated legacy monolith which talks to a legion of half-baked microservices and emits events processed by arcane workflow engines orchestrating lambda execution.
  - mrngm 1y ago
    https://news.ycombinator.com/item?id=43925892 https://news.ycombinator.com/item?id=43925892 "Microservices are a tax your startup probably can't afford" (310 points, 263 comments). First build the thing that works, and only if it's really necessary, split it up in separate (networked) parts. You won't have to deal with unreliable network communication, or coordinate on a breaking API change with several teams when a simple search/replace on several function definitions and calls suffices.
csbrooks 1y ago
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.
- 3abiton 1y ago
  At the end of the day that's the end goal of technical leadership: trust in the team ability and educated decision making
Illniyar 1y ago
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.
- gwbas1c 1y ago
  In the aerospace world, it's called a "systems engineer." The lead: 1: Understands the whole system, but not necessarily every detail. 2: Plans the whole project. Edit: Sometimes in the software world, the title is "architect." This is rarely the "manager," except in organizations that have a hard-on for hierarchy and artificial promotion for "career advancement." Managers are usually concerned with people, schedules, and resources; but don't go very deep into technical issues. That being said, the lead/manager may fill in for each other when one is on vacation, sick, quits, ect.
- kenhwang 1y ago
  The lead developer is the person assigned to the lead developer role. I know it's cheeky but it really could be anyone. It's usually at least a senior-level individual contributor (IC). It's not uncommon for it to be a manager (that hopefully used to be an IC). The lead's authority also tends to be varied in scope. They could be the lead of the feature, project, repo, team, initiative, or org. Depending on the context, their hierarchy might not always be the same. So really, a lead is someone that is in or uses leadership within their scope and with others in the same position. Alternatively referred to as "politics". In this context, they're handing the politics of development issues with the goal of getting features done.
pac0 1y ago
I think this nails down the job perfectly in my experience. And the most valuable trait it's being a good translator, and not just for this job but almost anyone.
w10-1 1y ago
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.)
senshan 1y ago
It has all been described in detail over two decades ago by Michael Lopp: Managing Humans: Biting and Humorous Tales of a Software Engineering Manager
LostInTheWoods 1y ago
"You are not going to convince anyone with facts." ... Lost me here. What kind of organization doesn't run on facts?
- kj4211cash 1y ago
  Most?
cgio 1y ago
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.
- AdieuToLogic 1y ago
  I believe what you describe is what I have learned to be known as Servant Leadership[0]. I could be totally wrong in my interpretation of your experience and admittingly may be projecting a leadership approach I quite fancy. Thanks for sharing your experience. EDIT: Removed unnecessary qualification in the last sentence. 0 - https://en.wikipedia.org/wiki/Servant_leadership https://en.wikipedia.org/wiki/Servant_leadership
  - cgio 1y ago
    Kind of, but with a different motivation at inception at least. In a perverse bike shedding variation, in a room of experts, disagreement will tend to root in bringing every matter under the lense of individual expertise. No one wins there, as before addressing the problem, the disagreements tend to focus on context. There is a certain art in giving ownership on the subject matter expertise, while drawing the lines on the overlaps, where argumentation is focused and productive rather than a tug of war to pull the subject in a comfort zone.
    - cgio 1y ago
shalmanese 1y ago
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.
zby 1y ago
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.
al_be_back 1y ago
Excuse me, but I am a Tech Lead, not a people lead - now let me lead some technology, please! What in the actual ...
TimByte 1y ago
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
- alkoves 1y ago
  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.)
virajk_31 1y ago
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.
pastapliiats 1y ago
The author has read the audio for the article themselves?! Amazing
- RankingMember 1y ago
  Nice! Sites should highlight when the audio is a real human reading it like that (By default I ignore "Listen to this article" functions on sites like this because they're almost always AI-generated weirdness).
benchly 1y ago
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.
- fuzzfactor 1y ago
  You've said it very well and it can be experience that applies to non-software too. >Technical leadership in expert environments is less about command and control, and more about connection and context. You're not the conductor trying to play every instrument. You're the one helping the orchestra understand what song they're playing together. I think that's the money shot. Some people have decades of analogies of business compared with musical organizations and I'm one of them. Lots of other analogies too but it's the real thing that I really like to implement. Analogs only go so far. Now for the commercial chem lab, instrumentation has a similar role to an orchestra and it works pretty good when you think about it. Different teams like horns or strings for instance encompass various levels of outstanding professional talent and there is natural self-selection to an extent even if there is also fair competition for a "first chair" or lead position on a team. To be "anointed" by the conductor. Ideally to universal praise, but we know no organization is ideal, and it's the leader who has to well-focus enough effort to compensate. Everybody's judging everybody artistically to get an idea if they are bringing to the table what is needed from their role, including the conductor. Pro musicians can realize early when it's not coming together, and lots of fingers can point at a leader, whether it's first chair, conductor, or even "guest conductor" who just pops in as a "stranger" unexpectedly sometimes. Responsibility for leadership deficiency must be acknowledged and accepted before it can be turned into respect. Some members can play more than one kind of instrument but mostly that's not a requirement. Then there's things like a harp or tympani which if it's even there you won't see more than one player, and they may step in from another role and/or instrument to only do it for a few minutes. Or they may just stand by silently until needed, either way can work, conductor's choice. Any doubt in the leader's ability should have a fair way to overcome, so the truly desired hierarchy can function the way it's supposed to. People know when that's not happening. Now this is technical too not just art. Sometimes the best route forward is for the lead to demonstrate their own technical proficiency a little bit on their chosen traditional instrument. This can make all the difference, and it doesn't have to reach the level of somebody who has actually been rehearsing every day like the rest of them, just the clear sign of a well-practiced equivalent. Not even the same material. In person it just has to demonstrate inspiring, exemplary competence, which combined with the natural leadership qualities well-received by the group, puts it over the top in respect earned, the way it works best. This only needs to be done infrequently, but sometimes regularly. It can almost be like an OK to the conductor, please get back to the podium and don't show us how to do it in the pit, we know you had the instrument talent if you need it, we won't complain so easy when we don't think the conductor is not perfect next time either. When people need to shut up and get back to their rat-killin' sometimes the only way to do it is with respect that is earned, and it really works compared to when it is ordained or thoughtlessly enforced. If every fiddle player has their nose to the grindstone every day, that's what's expected because that's the everyday technical requirement it takes to earn their place. And pull their weight like they're supposed to do. If the ultimate leader is not putting in equal everyday effort just plain doing whatever it takes to earn legitimate respect, it will show. They're the only one that doesn't have their hands full rehearing all the time, so talented people naturally expect them to be making the most of it. Otherwise people begin to wonder if a leader is really technically qualified to begin with, and the doubt can be equally bad whether it is true or not. Now the orchestra can seem sophisticated compared to the hard rockers and country & western bands encountered more often, some of whom can have somewhat "redneck" tendencies. Either way, my advice to some executives who think they're so cool is "don't try to be a bandleader". There's drummers and bass players who will support every thing you do from back there, but if you fail to showcase their talent they will easily become disgruntled, and if you're a complete failure likely to rip you a new one. Even if it's not a jazz band, if you're going to herd cats, you need to be a cat yourself, a badger or a skunk won't fool everybody.
jmpeax 1y ago
> 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.
bumseltagbaerbi 1y ago
[dead]
MomsAVoxell 1y ago
Apropos the impact of AI/ML on our industry - I have found that you need to treat AI like a junior dev, but also need to treat junior devs as soon-to-be senior devs. AI is a junior dev who will do anything you tell it to, no matter how stupid. Junior devs want to be senior devs - and we all know you do that by not doing stupid things. I’ve brought junior devs up to senior level by having them shoulder-surf my productive interactions with AI. AI makes it much easier to become a senior dev, as should be the case. But a junior devs working alone with AI is always going to be less effective than a senior dev. Onboard human junior devs with AI and you will not just have the AI force multiplier operating in your organization, you’ll have, suddenly, a ton more senior devs. Of course all of this depends on the humans being honest about their abilities and working to sharpen and refine their skills. AI is the lodestone upon which that can occur - it is also a blunt force instrument that will lead to loss of consciousness if you’re not careful. The tricky part about this is, of course, that if you don’t treat AI like a junior devs and review every single thing it provides you, it will rapidly transform the senior devs to junior… In short, it’s the humans that make the difference, even still today. AI is just another tool - and no tool is effective without proper methodology in place to prevent its weaponization against its users.

459 points by jnord 1y ago

I recommend _Becoming a Technical Leader_ by Weinberg for a deeper take. The software examples are dated, but the wetware observations and advice stands. https://www.amazon.com/Becoming-Technical-Leader-Gerald-Weinberg-ebook/dp/B004J4VV3I?adgrpid=168226348068&dib=eyJ2IjoiMSJ9.sga-KWcXDoUlZwD_arEqDOsKUiy-uFb3W48As9ypNaR2tTYQEbfnuthQdHr06E4xv0eheQwKyGamd-BefPYnlI5uDm9HshO9QMLMzM-or42PwrFFvts83SNjtEvzcKq9n9IEMx7-d5FhEw_Fzq4EDdxPgTX-BKMeAOEaDYWCstsxXmPYh-Y0VVCiYZt5wCsrnMU_kiTSX6CEr9a9P8uqDA.3IIJ2zkv39La1ny2dXDaGGHf8k9JfD81tkPsn10gDMg&dib_tag=se&hvadid=692991596066&hvdev=m&hvexpln=68&hvlocphy=9026903&hvnetw=g&hvocijid=8863768339482205152--&hvqmt=e&hvrand=8863768339482205152&hvtargid=kwd-301019296031&hydadcr=15806_13521449&keywords=becoming+a+technical+leader&mcid=3e31625d999f3ff387331e5c128dd5da&qid=1758723421&s=books&sr=1-1 https://www.amazon.com/Becoming-Technical-Leader-Gerald-Wein...

jamiecurle 1y ago

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.

bluGill 1y ago
Probably better to say "because it is a bikeshed not worth debate". Often there isn't a right answer but a decision is needed.
- potato3732842 1y ago
  I like to use something along the lines of "anyone in this room is capable of handling the minutia satisfactorily, there is no need to waste time on the details".

ahmedfromtunis 1y ago

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

Aurornis 1y ago
This is a lesson I learned the hard way. When I was a first time manager I had the naive idea that I was going to build consensus for everything and get everyone to come to an agreement naturally. It worked at first with a good team. Then later I inherited a fragment of another team with some older know-it-all engineers who thought everything modern was garbage and we should be doing everything like they did 25 years ago. I wasted too much time letting them stonewall everything while thinking we’d eventually reach a consensus. Then at some point you realize you have to put your foot down and pick a direction after they’ve had a chance to state their position.
- wahnfrieden 1y ago
  You could learn from consent based decision making, a hallmark of sociocratic worker coops that is underrated and can be applied elsewhere. Hierarchy and coercion isn't necessary for avoiding decision paralysis in organizations. It appears to be the practical route but has all sorts of harmful and counterproductive consequences. https://www.sociocracyforall.org/consent-decision-making/ https://www.sociocracyforall.org/consent-decision-making/
  - AnimalMuppet 1y ago
    Interesting. For that to work, though, it has to be true consent, not "it's the boss's idea and I don't dare to object out loud". But I guess, if that's the environment you're in, then you're stuck with autocratic leadership (no matter what label it claims for itself), and your only choice is to leave or not.

wavemode 1y ago

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

everdrive 1y ago
This is a difficult lesson to swallow, but must be understood. I do still retain some frustration that there does not seem to be more effort to correct for this problem locally. For instance, in general you must speak to your audience and make emotional appeals. But me, your boss, should understand how to look past that and work with the facts, at least to the degree possible. I don't see much of that.
- tux3 1y ago
  There are places that have this norm, but it's exceedingly rare, and it's not some perfect utopia. We're all susceptible to emotional appeals to different degrees, and emotions aren't some inconvenience that you should try to eliminate in favor of pure cold calculations, they also have a place and a reason to be. People care about different things, so trying to focus just on facts can end up with people talking past each other, because they have different goals, value systems, or other fuzzy human feelings that can't be graphed in an Excel spreadsheet and compared numerically. I'm not saying that emotional appeals and sophistry are fine, but I find that often when people accept an emotional appeal over a cold purely factual argument, it's because the factual argument is missing the point. A more important part of the discussion is understanding what other people actually care about to make sure we're not all talking past each other, or spending hours arguing details that won't matter in the end.
Herring 1y ago
You need to get a better audience. I recently met a good developer who still thinks Covid was a hoax. Doing my best to avoid him. You think you can just politely work around him -- that's how you get vaccine skeptics dismantling the CDC.

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

bilsbie 1y ago

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

malshe 1y ago
100% agree. I would further add that occasionally being perceived as an expert can be bad. When I sense this type of crowd, I take Norm Macdonald's approach and pretend that I barely know anything.

SoftTalker 1y ago

I thought the new way was to just say "You're absolutely right" to any objection and then rephrase your original proposal without really changing it.

gwbas1c 1y ago
That just makes you sound like a weasel and destroys your trust.
- illusive4080 1y ago
  It was a joke about how AI loves to tell you that you’re right but then it regurgitates its prior plan verbatim.

physicsguy 1y ago

> When the product team requests a "simple" feature, I'm thinking about the 3 teams that need to be involved to update the necessary microservices. God I hate modern web sometimes

fladrif 1y ago
What's the alternative?
- moffkalast 1y ago
  Macroservices, or several megaliths instead of one monolith, if you will.
  - Rendello 1y ago
    What about going the other way and Unix-piping together hundreds of thousands of nano-services?
    - sally_glance 1y ago
      I think it's called serverless or FaaS today? But why choose, just do all three at the same time! Actually you don't even have to choose, it will naturally happen when transitions are never fully completed... So before you know it you're stuck with a partially integrated legacy monolith which talks to a legion of half-baked microservices and emits events processed by arcane workflow engines orchestrating lambda execution.
- mrngm 1y ago
  https://news.ycombinator.com/item?id=43925892 https://news.ycombinator.com/item?id=43925892 "Microservices are a tax your startup probably can't afford" (310 points, 263 comments). First build the thing that works, and only if it's really necessary, split it up in separate (networked) parts. You won't have to deal with unreliable network communication, or coordinate on a breaking API change with several teams when a simple search/replace on several function definitions and calls suffices.

csbrooks 1y ago

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.

3abiton 1y ago
At the end of the day that's the end goal of technical leadership: trust in the team ability and educated decision making

Illniyar 1y ago

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.

gwbas1c 1y ago
In the aerospace world, it's called a "systems engineer." The lead: 1: Understands the whole system, but not necessarily every detail. 2: Plans the whole project. Edit: Sometimes in the software world, the title is "architect." This is rarely the "manager," except in organizations that have a hard-on for hierarchy and artificial promotion for "career advancement." Managers are usually concerned with people, schedules, and resources; but don't go very deep into technical issues. That being said, the lead/manager may fill in for each other when one is on vacation, sick, quits, ect.
kenhwang 1y ago
The lead developer is the person assigned to the lead developer role. I know it's cheeky but it really could be anyone. It's usually at least a senior-level individual contributor (IC). It's not uncommon for it to be a manager (that hopefully used to be an IC). The lead's authority also tends to be varied in scope. They could be the lead of the feature, project, repo, team, initiative, or org. Depending on the context, their hierarchy might not always be the same. So really, a lead is someone that is in or uses leadership within their scope and with others in the same position. Alternatively referred to as "politics". In this context, they're handing the politics of development issues with the goal of getting features done.

pac0 1y ago

I think this nails down the job perfectly in my experience. And the most valuable trait it's being a good translator, and not just for this job but almost anyone.

w10-1 1y ago

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

senshan 1y ago

It has all been described in detail over two decades ago by Michael Lopp: Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

LostInTheWoods 1y ago

"You are not going to convince anyone with facts." ... Lost me here. What kind of organization doesn't run on facts?

kj4211cash 1y ago
Most?

cgio 1y ago

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.

AdieuToLogic 1y ago
I believe what you describe is what I have learned to be known as Servant Leadership[0]. I could be totally wrong in my interpretation of your experience and admittingly may be projecting a leadership approach I quite fancy. Thanks for sharing your experience. EDIT: Removed unnecessary qualification in the last sentence. 0 - https://en.wikipedia.org/wiki/Servant_leadership https://en.wikipedia.org/wiki/Servant_leadership
- cgio 1y ago
  Kind of, but with a different motivation at inception at least. In a perverse bike shedding variation, in a room of experts, disagreement will tend to root in bringing every matter under the lense of individual expertise. No one wins there, as before addressing the problem, the disagreements tend to focus on context. There is a certain art in giving ownership on the subject matter expertise, while drawing the lines on the overlaps, where argumentation is focused and productive rather than a tug of war to pull the subject in a comfort zone.
  - cgio 1y ago

shalmanese 1y ago

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.

zby 1y ago

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.

al_be_back 1y ago

Excuse me, but I am a Tech Lead, not a people lead - now let me lead some technology, please! What in the actual ...

TimByte 1y ago

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

alkoves 1y ago
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.)

virajk_31 1y ago

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.

pastapliiats 1y ago

The author has read the audio for the article themselves?! Amazing

RankingMember 1y ago
Nice! Sites should highlight when the audio is a real human reading it like that (By default I ignore "Listen to this article" functions on sites like this because they're almost always AI-generated weirdness).

benchly 1y ago

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.

fuzzfactor 1y ago
You've said it very well and it can be experience that applies to non-software too. >Technical leadership in expert environments is less about command and control, and more about connection and context. You're not the conductor trying to play every instrument. You're the one helping the orchestra understand what song they're playing together. I think that's the money shot. Some people have decades of analogies of business compared with musical organizations and I'm one of them. Lots of other analogies too but it's the real thing that I really like to implement. Analogs only go so far. Now for the commercial chem lab, instrumentation has a similar role to an orchestra and it works pretty good when you think about it. Different teams like horns or strings for instance encompass various levels of outstanding professional talent and there is natural self-selection to an extent even if there is also fair competition for a "first chair" or lead position on a team. To be "anointed" by the conductor. Ideally to universal praise, but we know no organization is ideal, and it's the leader who has to well-focus enough effort to compensate. Everybody's judging everybody artistically to get an idea if they are bringing to the table what is needed from their role, including the conductor. Pro musicians can realize early when it's not coming together, and lots of fingers can point at a leader, whether it's first chair, conductor, or even "guest conductor" who just pops in as a "stranger" unexpectedly sometimes. Responsibility for leadership deficiency must be acknowledged and accepted before it can be turned into respect. Some members can play more than one kind of instrument but mostly that's not a requirement. Then there's things like a harp or tympani which if it's even there you won't see more than one player, and they may step in from another role and/or instrument to only do it for a few minutes. Or they may just stand by silently until needed, either way can work, conductor's choice. Any doubt in the leader's ability should have a fair way to overcome, so the truly desired hierarchy can function the way it's supposed to. People know when that's not happening. Now this is technical too not just art. Sometimes the best route forward is for the lead to demonstrate their own technical proficiency a little bit on their chosen traditional instrument. This can make all the difference, and it doesn't have to reach the level of somebody who has actually been rehearsing every day like the rest of them, just the clear sign of a well-practiced equivalent. Not even the same material. In person it just has to demonstrate inspiring, exemplary competence, which combined with the natural leadership qualities well-received by the group, puts it over the top in respect earned, the way it works best. This only needs to be done infrequently, but sometimes regularly. It can almost be like an OK to the conductor, please get back to the podium and don't show us how to do it in the pit, we know you had the instrument talent if you need it, we won't complain so easy when we don't think the conductor is not perfect next time either. When people need to shut up and get back to their rat-killin' sometimes the only way to do it is with respect that is earned, and it really works compared to when it is ordained or thoughtlessly enforced. If every fiddle player has their nose to the grindstone every day, that's what's expected because that's the everyday technical requirement it takes to earn their place. And pull their weight like they're supposed to do. If the ultimate leader is not putting in equal everyday effort just plain doing whatever it takes to earn legitimate respect, it will show. They're the only one that doesn't have their hands full rehearing all the time, so talented people naturally expect them to be making the most of it. Otherwise people begin to wonder if a leader is really technically qualified to begin with, and the doubt can be equally bad whether it is true or not. Now the orchestra can seem sophisticated compared to the hard rockers and country & western bands encountered more often, some of whom can have somewhat "redneck" tendencies. Either way, my advice to some executives who think they're so cool is "don't try to be a bandleader". There's drummers and bass players who will support every thing you do from back there, but if you fail to showcase their talent they will easily become disgruntled, and if you're a complete failure likely to rip you a new one. Even if it's not a jazz band, if you're going to herd cats, you need to be a cat yourself, a badger or a skunk won't fool everybody.

jmpeax 1y ago

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

bumseltagbaerbi 1y ago

[dead]

MomsAVoxell 1y ago

Apropos the impact of AI/ML on our industry - I have found that you need to treat AI like a junior dev, but also need to treat junior devs as soon-to-be senior devs. AI is a junior dev who will do anything you tell it to, no matter how stupid. Junior devs want to be senior devs - and we all know you do that by not doing stupid things. I’ve brought junior devs up to senior level by having them shoulder-surf my productive interactions with AI. AI makes it much easier to become a senior dev, as should be the case. But a junior devs working alone with AI is always going to be less effective than a senior dev. Onboard human junior devs with AI and you will not just have the AI force multiplier operating in your organization, you’ll have, suddenly, a ton more senior devs. Of course all of this depends on the humans being honest about their abilities and working to sharpen and refine their skills. AI is the lodestone upon which that can occur - it is also a blunt force instrument that will lead to loss of consciousness if you’re not careful. The tricky part about this is, of course, that if you don’t treat AI like a junior devs and review every single thing it provides you, it will rapidly transform the senior devs to junior… In short, it’s the humans that make the difference, even still today. AI is just another tool - and no tool is effective without proper methodology in place to prevent its weaponization against its users.