How to Lead in a Room Full of Experts

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

Functions and handlers should not care where data comes from, just that they have data, and a queue is the abstraction of that very idea. Yes, you lose atomicity but atomicity is generally slow and more problematic has a high amount of coupling.

I don’t agree that being out of sync is the main downside of microservices; the main downside is that anything hitting the network is terrible. Latency is high, computers crash, you have to pay a cost of serialization and deserialization, libraries can be inconsistent, and zombie processes that screw up queues. Having stuff in-process being non-synchronized wouldn’t even hit my top five.

ETA:

I should be clear; obviously there are times where you want or need synchronization, and in those cases you should use some kind of synchronization mechanism, like a mutex (or mutex-backed store e.g. ConcurrentHashMap) for in-process stuff or a SQL DB for distributed stuff, but I fundamentally disagree with the idea that this should be the default, and if you design your application around the idea of data flow, then explicit synchronization is the exception.

Championing collaboration in a team environment where members are employed for their skills is to acknowledge the value of those members. How you equate this to "a massive god-complex" is a mystery to me.

> If you think your job is to second guess your manager's knowledge and experience, why are you working under them?

Again, collaboration is not "second guessing." It is an effective technique used to identify and pursue an optimal approach given the information known at the time.

> You should be working as a manager somewhere else.

Don't "should" on me. "Should" in the bathroom and wash your hands afterward.

> You are not a peer, you're part of a team reporting into a person that company has entrusted to lead the team.

Management is a personnel role, not a subject matter expert role. Many excellent managers do not possess the skills or domain expertise of those they manage. The great managers I have had the pleasure to work with would freely admit this if asked.

That you imply an organization chart reflects the ability to make informed expert decisions based on where one resides in same confirms to me a myopic understanding of management in general, let alone "how to lead in a room full of experts."

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.