How to Lead in a Room Full of Experts

https://idiallo.com/blog/how-to-lead-in-a-room-full-of-experts

by jnord • 10 months ago

459 137 10 months ago

idiallo.com

readthenotes1• 10 months 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-Wein...

jamiecurle• 10 months 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• 10 months 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• 10 months 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• 10 months 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• 10 months 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.

wahnfrieden3• 10 months 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/

tracerbulletx• 10 months ago

You can build consensus around the decision making process and build a culture where the outcome of that process is widely accepted. As long as people have the time and pathways to make their case and input, and understand there will be some verdict that may or may not align completely with their opinion. Then its just the decision makers duty to synthesize things in good faith but probably has bought themselves some leeway.

YZF• 10 months ago

What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good.

That's not to say that consensus always works. But it does mean the group needs to understand the objections and make decisions the team can live with. The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes.

Sometimes there is time pressure or difficult people but the base assumption should be that people actually want to make the right decision, being difficult generally makes your life harder. Who would be responsible for executing on the decision and who would be responsible for the outcome? What are the consequences of strong arming the team into solutions they don't agree with?

smrtinsert2• 10 months ago

The know it all engs were probably right though and you just added the self imposed productivity, performance, and TCO tax that everyone else adds by default

dmos62• 10 months ago

Steve Jobs was also known to lock teams in a room until they arrived at a common vision. It's a difficult task, to align everyone, but in my limited experience not doing it resulted in extremely inefficient execution. What's more, people feel belittled and rejected if you disregard their viewpoints. Sometimes you need to get things done regardless of what people feel or think, but you can't sustain that for a long time.

SoftTalker2• 10 months ago

This is what we do with juries, so there's something to be said for it.

mathattack• 10 months ago

Very good point. There’s a big difference between “everyone gets heard” and “everyone gets a veto.”

Breaking ties is part of the leader’s job.

Of course if every issue requires the leader to break the tie, then perhaps there’s either a management issue, and incentive issue, or people don’t understand the strategy.

hinkley• 10 months ago

It took a while to emerge but a couple years into my F50 gig we ran into a situation where we had a bus number if 3 in a domain, we all knew that solution A sounds good on paper but is a shitshow in practice, but the rest of the team was still enamored of it and our reasoned explanations just weren’t being persuasive enough.

The popular vote was going to load us up with little emergencies that were going to slow several divisions down and we ended up talking to the bosses and ignoring the vote.

In trying to smooth this over, I realized that the problem is that the people who would be dealing with the consequences of a decision wanted solution C and everyone else wanted solution A. And I think it’s something worth remembering for future indecisions, that the people with skin in the game need to be able to veto a popular vote. If you don’t want the project to lose momentum.

Generally on a large project you will have a bunch of leads all dealing with different domains, and they will reach quorum on major architectural decisions, particularly cross cutting concerns and interfaces between Conway’s Law modularizations. The boss only needs to break ties when a consensus does not emerge. And I mean NEEDS. Second worst boss I ever had refused to break ties and we had an even number of leads, so it happened half a dozen times. We wasted hours every month venting to each other about what we hated about him and one of the regular attendees just about wanted to murder him for that, and have us help him hide the body.

9rx9• 10 months ago

"I'm the lead, and we are going to do it this way"

"Okay. Let me know when you are done with that."

roughly• 10 months ago

Make sure people understand why you're making the tradeoff you're making, and also make sure they know you're taking the fire for it if you were wrong and they were right, not them.

delusional• 10 months ago

I like that a lot. My favourite leaders haven't sought out my opinions much, but they made their intentions and basis clear. If I wanted to change something in their plan, I could do the work of making an argument from their basis. Most people aren't going to do the work of actually making an argument, so they get brushed aside. The few people who do bother to make an argument are the ones with a lot of conviction and motivation toovercome the new obstacles.

afro88• 10 months ago

100%. I worked for a brilliant lead, he had a team of excellent engineers. But he was stuck on the socratic method, determined to lead by asking thoughtful questions and letting us sort it out. Important discussions would go in circles a lot, frustratingly so. Sometimes you have to be the decision maker.

beachy• 10 months ago

Humans sometimes yearn for the leader to put their foot down.

The quiet ones may want the yapping voices silenced so progress can be made.

And sometimes the yapping ones get out ahead of their own skis and don't know a graceful way to back down so they're happyish to be closed down, even if they're primed to come back with an "I told you so" if the leader gets it wrong.

AznHisoka• 10 months ago

“If you want to make everyone happy, don't be a leader.”

This is the most important line. You shouldnt be afraid to hurt some peoples feelings (though not intentionally and as kindly as you can of course). Absolutely nothing will get done if you want everyone to be happy

ori_b2• 10 months ago

Alternatively, my preferred method: "You're the one doing the work. Tell me what your decision is."

Your job as a leader isn't necessarily to make the decision, just to be sure that the decision was made.

dotancohen• 10 months ago

Also, to ensure that the decision made is based on logic and reason. Insofar as that is even possible.

oncallthrow2• 10 months ago

In my opinion this advice is quite fatuous, because it skips over the actual difficult bit, which is figuring out what to do when you have a problem that can't simply be decided by the person directly responsible for the the work, either due to complexity/scale of the problem, or because that person is not capable of making the decision.

AdieuToLogic6• 10 months 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.

Taking this approach with skilled people paid to think can easily be interpreted as being dictatorial and often stifles future contributions.

Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice.

This implies a rigid hierarchical structure, one lacking collaboration. Again, this approach might work with assembly line workers but won't fly more than once or twice with people paid to solve problems.

In that case, it's your duty as the leader to play the dictator and impose order.

And it will be soon your duty to find people to backfill those who have better opportunities to pursue.

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.

There is no "re-establishing trust with your team" when this form of "leadership" is employed. Once trust is broken, the only employees who remain are those with no better options.

liquid_thyme3• 10 months ago

I've worked with engineers like this, who have a massive god-complex. If you think your job is to second guess your manager's knowledge and experience, why are you working under them? You should be working as a manager somewhere else. You are not a peer, you're part of a team reporting into a person that company has entrusted to lead the team.

nvegater• 10 months ago

Yes, and there is one trick I’ve learned instead of explicitly pulling the ‘I’m the lead’ card (which is valid, but not always the best move).

Present the decision in terms of its consequences — consequences that fall on you as the leader, not on others. You want to make clear that the accountability for the outcome rest with you and that others are "safe".

What usually happens when I do this is that the team defers to me to make the decision cause they recognize my point.

That way, you preserve alignment and authority without eroding trust, because the team sees it’s not about wielding power, but about owning the consequences no one else should or can carry.

7bit• 10 months ago

Steve Jobs was an awful human being and people like him would say anything to justify their toxic behaviour. Quoting gim was the worst possible choice. You can be a leader and a decent human being. For example Gabe Newell, to name just one.

TimByte3• 10 months ago

There's a difference between defaulting to authority and resorting to it when needed. Consensus is great until it turns into paralysis

skeeter20202• 10 months ago

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.

redbell• 10 months ago

Unrelated: So your name is Ahmed from Tunisia living in the Capital :)

wavemode• 10 months 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• 10 months 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• 10 months 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.

Herring3• 10 months 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.

floydnoel• 10 months ago

Why? Are they insufferable otherwise? Or is it more that you find it unbearable to tolerate a different opinion? I'm so curious, about both of you. What part does he think was a hoax?

DangitBobby• 10 months ago

It's directionally correct but not entirely accurate IMO. It would be more accurate to say, your audience does not have the experience and context necessary to turn the facts into a decision criteria. You need to translate your "raw data facts" into "refined facts" ready for consumption by the audience. That's what a good communicator does. The original phrasing makes it almost sound like the decisions are not fact-based or emotional, which should elicit eye-rolls.

oncallthrow2• 10 months ago

It would be more accurate to say, your audience does not have the experience and context necessary to turn the facts into a decision criteria.

I don't agree. Humans are fundamentally social and illogical creatures, and in many cases regardless of the experience or context they have, they will make decisions based on social factors regardless of hard logic.

watwut• 10 months ago

I think it does deserve eye roll, because it is huge oversimplification on itself. The situations in which you convince people with facts are not exactly rare.

That person is getting an eye roll, because they are just repeating popular phrase that is not even particularly useful.

tombert6• 10 months ago

I was about to say, I've definitely had my mind changed mid-meeting by facts, even if the person trying to convince me was being an asshole. It might not happen as often as it should, but I think it's somewhere between "reductive" and "untrue" to say that you're not going to convince educated people with facts sometimes.

racl101• 10 months ago

Need ethos, logos and pathos. Not just the logos.

bilsbie• 10 months 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• 10 months 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.

SoftTalker2• 10 months 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.

gwbas1c2• 10 months ago

That just makes you sound like a weasel and destroys your trust.

illusive4080• 10 months ago

It was a joke about how AI loves to tell you that you’re right but then it regurgitates its prior plan verbatim.

physicsguy2• 10 months 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• 10 months ago

What's the alternative?

moffkalast• 10 months ago

Macroservices, or several megaliths instead of one monolith, if you will.

mrngm• 10 months ago

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.

9rx9• 10 months ago

Funnily enough, microservices. In the macro economy you don't have to have such strict coordination with Microsoft, or OpenAI, or Google, or whomever you interface with. You just figure out how to make your solution work within the confines of the service they give you. Like it or not.

Microservices is exactly the same concept except in the micro economy of a single organization. Each team is like Microsoft, OpenAI, Google, etc. You don't coordinate with them, you deal with what they give you. Like it or not.

I expect the earlier statement confused microservices with a multi-process application.

stuartaxelowen• 10 months ago

I love the distribution of answers to this.

deviation• 10 months ago

Is the problem here the modern web? Or that this "simple" feature had its dependencies split amongst 3 microservices, instead of 1?

Seems more a system design failure to me.

csbrooks• 10 months 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• 10 months 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• 10 months 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.

gwbas1c2• 10 months 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• 10 months 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• 10 months 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• 10 months 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• 10 months 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• 10 months ago

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

kj4211cash• 10 months ago

Most?

cgio3• 10 months 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.

AdieuToLogic6• 10 months 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

cgio3• 10 months 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.

TimByte3• 10 months ago

It takes real confidence (and restraint) to let strong engineers run with their ideas without feeling the need to course-correct every detail

shalmanese• 10 months 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• 10 months 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_back2• 10 months ago

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

TimByte3• 10 months 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• 10 months 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• 10 months 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• 10 months ago

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

RankingMember• 10 months 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• 10 months 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• 10 months 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• 10 months 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.

MomsAVoxell• 10 months 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.

How to Lead in a Room Full of Experts

Related Stories