"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.
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.
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?
> What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good.
I would say that they are pretty average.
First I am not sure what you mean by "know-it-all", specifically if this is a positive trait or not. Let's say that it is positive.
In that case age does not matter much because you can have extremely good practices that are simply outdated. Yes they work. Yes, they are stable. But they may not be adapted to the current needs.
So age is not a good differentiator for me.
Now, if you drop "older" I agree with you (with the assumption of a positive meaning for know-it-all)
>> The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes.
Disagree. This can be very bad, but the worst situation I had was a very experienced developer with poor social skills making decisions for the team without a complete understanding of the entire picture
Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't updated my judgement since, despite the world having changed a lot".
The problem is that unless you really know things inside out or know the hard held opinions of your older collegue well, it can be hard to tell the two apart. In that case it only helps to talk about it in more detail and try to get to the root of where the judgement comes from. Then it could come to light that the warning to use PHP comes from a bad experience with PHP version <1.0 or that there is a number of bad experienced that are really useful for deciding the direction of a project.
In the end many decisions are about taste. And nothing is as good as a way to keep arguing than matters of taste. Weigh all the pros/cons and make a choice.
I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today.
For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently.
Like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field.
All those habits proved to be bad in the long run. And today memory (and disk space) are abundant. But these old habits are hard to break.
And that's before we talk about "modern" techniques, like version control etc.
Experience is great. I'm a fan. But all too often experience is also "there was a bug I windows 95, so that API call is unreliable ".
>many older folk...like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field. All those habits proved to be bad in the long run.
I'll bet you the people inventing these modern new architectures are among the more experienced engineers at the companies
who I would criticize by saying, we used to think it was a good idea to code around the limitations of old architectures and now we're accused of coding for PDP-11s and processors aren't PDP-11s any more. so what we should do now I'm told is code very specifically around the idiosyncracies of the new PDP-11,000's and that is what marks progress. Caches were invented to invisibly and silently make things faster, and that was a brilliant idea. Now new cache designers analyze what we used to do to insist we change how we code so they can cache what they want to cache not what we want to do, and all younger programmers talk about these days is coding for the cache (which itself is a cache of a cache of a cache). this is not progress, it's coding for the timing of the modern storage drum.
You can still obtain a ton of performance by minimizing the size of right things, processor caches are relatively small still. Stuff like the order of columns in a postgres database can still at worst multiply your table size
Yes, but we went from a time where these optimizations were absolutely unavoidable (so unavoidable that programmers would sacrifice any other thing for it) to one where the optimizations may be a nice to have, but for most organizations the maintainability of the code is much more crucial.
As mentioned before there are exceptions, like embedded programming, anything that needs to be finished within predictable time (game code, graphics, DSP code, etc). But even if you write a thing for a company website today I wouldn't dare to answer if making the code 10% less readable to make it use memory 10% less memory is a good trade off. Not that redability and memory use are necessarily mutually exclusive goals, but if you highly optimize code for one dimension, others will suffer at some point. And if you come from a generation where memory usage was king, it could be that you make these trade offs out of habit or principle despite them maybe no longer aligning with the goals of the project you're working on.
Anybosy who is good at their craft will choose how to deal with trade offs depending on the needs of the project and not based on remembered tradition.
With 20 years of experience in website development, I have led various site speed optimization teams. From my background, I pay particular attention to assets, JS profiling, and related aspects whenever I work on a web app. These practices are so ingrained that I perform them automatically and transparently, as they have been part of my process ever since.
The same thing might happen to these engineers when working on existing or new projects and writing C/C++ code; these optimizations will be part of their process.
I was born in the 90s so memory has been plenty for me during my programmers journey. Until I started doing more embedded signal peocessing stuff.
It is good to know how to use memory efficiently, even today. But it is also important to know that if you optimize for memory usage or speed you may be paying in another dimension. And in my experience a certain type of old programmer can have a total lack of awareness that e.g. in some cases readability, maintainability, ease of use for developers, display latency etc. can be dimensions that are priorized over another for really good reasons.
The admin equivalent of that is somebody who provisions the same hard disk space for a server today as they did in the 2000s and then have the machine run out of memory on every fourth kernel upgrade. It is good to only use the necessary resources, but not if you can't/won't handle the ugly consequences that may come with it.
It still has a cost though, which needs to be taken into account in many situations. At our company the cost of compute, RAM, and storage are some of the biggest ongoing concerns, which can make the difference between profitability and bankruptcy, and we’ve done a lot of work on it.
That would mean you're not on one page with the others about what the project is meant to achieve and what not.
E.g. let's say one library is more privacy friendly and the other allows more data collection, depending on the project both could be pro or con. I respect developers who value privacy, but if you don't know whether a program is meant to collect data by the point you discuss library choices that eindicates either bad project planning, bad communication or both.
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.
I don’t think that is a practical framework for situations where people aren’t already very closely aligned.
What happens when a few people are very vocal (and firm) in opposition to basically every change? Having dissenting views is valuable, but not when they have veto power.
Additionally, I think that framework is vulnerable to what I refer to as “death by yes but” - when everyone is just piling on amendments and precursor conditions, oftentimes conflicting, that result in a decision taking months (maybe even years) to make or scuttle.
I’m basing these comments out of experience - one example is a workgroup/committee operating under a similar model that was completely unable to do anything due to decision paralysis. The committee grew significantly more effective when we reformed the decision making process to have a small group of owners to handle pitching and (potentially) implementing the decision, then had approval be a simple yes/no majority vote.
>> 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.
> I don’t think that is a practical framework for situations where people aren’t already very closely aligned.
Putting aside the concept of Sociocracy for the purpose of discussing engineering team leadership philosophies, one which I have observed to be very effective when working with experts is Servant Leadership[0]. From the Wiki page:
A servant leader shares power, puts the needs of the
employees first and helps people develop and perform as
highly as possible. Instead of the people working to serve
the leader, the leader exists to serve the people.
While Servant Leadership[0] might initially raise concerns resembling the problems you rightly identify with a sociocratic approach, it has the benefits of peer collaboration combined with accountability of the decisions made by leadership.
Yes it only works when participants have a shared aim
In full sociocracy, it...
> honors the circle’s ability to freely make decisions within its domain. This is key for the organization to remain effective. But it comes at the cost of members not having “consent rights” to every decision the organization makes. Each member will only have those rights for the circles they are a part of.
So it's not necessary to allow people outside that working group to veto or require compulsory followup through objection
There's no perfect solution to organization, everything is a tradeoff. I've also been part of working groups (made of people whose job description is to manage the scope of changes they're proposing) where everyone and the workers impacted by the decisions are in agreement and no impact on cost etc., but the exec decides no change can be made due to personal preference despite disastrous consequence. Or where an exec who abstains from checking in on a working group's efforts nonetheless counters it with shifting and contradictory demands whenever it comes time to take action, requiring going back to the drawing board repeatedly until people simply give up or leave the organization. Or where the exec asks for more data for a proposal, and then doesn't evaluate the data once gathered, leaving no recourse but to give up or leave the organization. We all have stories like this. Hierarchical organizations are also susceptible to paralysis.
I've often taken inspiration from RFC 2418, "IETF Working Group Guidelines and Procedures" [1], a rare RFC that defines a human protocol ("rough consensus") rather than a technical one.
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.
Right, and some people’s role is to organize people and orient the group’s efforts by taking in big-picture problems and outputting direction.
There’s rarely a single correct answer— lots of good solutions have trade-offs— but there are often various wrong answers. Do the best you can to avoid the wrong answers, and when you inevitably run into the business end of one of your trade-offs, take comfort in knowing the other good options probably also had trade-offs, and tell the smug know-it-alls to cram it.
People working effectively towards a non-optimal solution is far more useful than sitting around arguing about the best way to do it.
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.
One thing I like to do with sr+ engineers who will feel burned by a decision - esp. those very publicly against it - is to lead with some sort of concession... maybe a project they expressed interest in, greenlight for a week to research some POC.
Whatever it is, it tends to be considerably less value to the business than the decision itself, but it directly acknowledges their discontent and allows them to get something out of the process besides platitudes, (perceived) public embarrassment, and frustration.
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
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.
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.
locking people in sure achieves at least one thing, but then so does adding two zeros. Jobs locked staff in, at Google when you a book meeting room, the wifi and lights cuts off at the end - a kill-switch approach [1].
personally, I think those hacks are cute and handy, but once you recruit well, reward and empower your staff, leading becomes much easier. At google, that approach probably helped more with their ESG policies than staff productivity. In Jobs' case, probably helped "him" stay focused rather than his staff, a meditation technique of sorts lol
Re: Juries. wasn't the main reason to prevent the world outside the court from influencing their decision?
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.
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.
If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
If they're not getting the same inputs to their decisions as you are, why are you hamstringing them?
And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?
> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
This doesn’t seem realistic to me. Division of labor also implies division of decisions. Mature individuals and teams will acknowledge when there are decisions they’re not able to make, and will refer them to the relevant teams.
An obvious example of this is legal: it hardly ever makes sense to leave a legal decision to a software developer or development team. But similar logic can apply to product management decisions, customer success, security, etc.
How is that an example? Legal is just an input. A mature individual is going to heed the advice from legal, most certainly, but legal isn't making the final decision. Legal doesn't know anything about all of the other constraints, like customer need and technical need. If they did, they wouldn't be working as legal council, they'd be doing the job we're talking about.
So, we're right back at the previous comment:
- If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
- If they're not getting the same inputs to their decisions as you are, why are you hamstringing them?
- And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?
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.
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.
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.
“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
> "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.
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.
> I've worked with engineers like this, who have a massive god-complex.
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."
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.
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.
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.
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.
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.
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.
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.
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.
I agree, though well designed software, even big monoliths, can be written in a way that isn't too hard to distribute later.
For example, if you utilize asynchronous queues everywhere, instead of something like a shared-memory mutex, it's relatively straightforward to turn that into some kind of networked queue system if you need to. Pretty much every language has a decent enough queue implementation available.
Asynchronous queues make your data out of sync (hence the name) and inconsistent one of the main downsides of microservices. Their use should be minimized to cases where they are really necessary. A functional transactional layer like postgres is the solution to make your state of truth accessed in a synchronized, atomic, consistent way.
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.
I'll agree that the network layer adds more problems to microservices, but even with a perfect network, they are problematic. Everything being out of sync, (if they are stateful microservices which queues imply), is one big issue. Things being interconnected in broad global scopes instead of more locally scoped is the other big issue.
The more you have globally interconnected and out of sync states, the less predictable your system is.
The solution is to be as hierarchical, as tightly scoped, as functional and as transactional as you can.
To add to this. There's fundamental theoretical reasons why microservices or bad. They increase the entropy of code (https://benoitessiambre.com/entropy.html) by increasing globally scoped dependencies. They are the global variables or architecture. Having lots of interconnected global variables makes for an unpredictable chaotic system.
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.
Yes, in practice you very well might end up there, but then you are not providing microservices and would not call it as such. But it remains that microservices is the solution. Fair to say that it is the solution like not eating too many calories is the solution to losing weight — as in it is not exactly fun to have to put yourself through it, and thus most with the problem will never try to fix it/give up — but the solution all the same.
Or even, someone leaves and you end up with a mess of maintaining multiple services that aren't coherently seperate at all, but have no time to refactor them together to make sense. That's been my experience.
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.
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.
I love the phrase "It's because that's why". For anyone interested in this kind of subject I've benefited a lot from Vanessa Van Edwards books which essentially boil down to signalling warmth and competence in the right ways for a given context. Of course, it's a giant field and no one person has all the answers, but for me it's yielded some wins.
I 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".
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.
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.
> 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.
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.
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.
There's both less and more to making decisions than ensuring they get made.
First: get others to actually decide. Jean-Louis Gassee at Apple (componentized mac's in the late 1980's) said that when dueling managers brought him a decision to make, he would always come up with a decision both of them hated, so they would scurry away and work together with an alternative they could live with.
Second: be sure to get everyone really on board - you first. This is really hard for managers who are following the wind. Law students are often careful and analytical, hedging every evaluation, but lawyers have to be assertive. Although they understand the precariousness of the legal position, it only works if you convince everyone (on your side and theirs) that this is how it will be. That transition is typically what weeds out new attorneys, and distinguishes partners from associates.
(Before you object to the attorney analogy: it's nice when you achieve collegial scientific consensus, but it can be a luxury. Then you have to figure out how to compel people do want they don't want to do, without straining authority. Usually it works to focus on picking a customer, or a definite time for results to appear; a more concrete objective/goal explains the decision and focuses follow-through.)
> I 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.
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.
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.
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.
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.
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.
> 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.
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?
In my experience that's usually just the tip of the iceberg. You've heard the expression "All happy families are alike; each unhappy family is unhappy in its own way"? It's like a link broke in a chain, and usually it's many links correlated. Maybe they just distrust expertise, well I have a phd and I assure you it'll come up later. Maybe he's an immigrant from Russia and he just distrusts everything to do with the news, well that's not really fixable except maybe with many years of therapy. And yes it will come up later too. I'm not a professional, I didn't want to ask the specifics or get into the weeds, I just have a developed nose for these things. My brother is into conspiracy theories.
> I have a phd and I assure you it'll come up later.
Will it? One would have to dig pretty deep into one's personal life to learn about that. Someone who thinks COVID was a hoax isn't going to be one to dig deep. And, well, if he really did somehow dig deep enough to find that information, you can just laugh it off as a hoax.
> Someone who thinks COVID was a hoax isn't going to be one to dig deep.
This is kind of a side point, but people with fringe beliefs tend to dig a lot deeper to validate those opinions than those with a mainstream view.
You can bet that someone who thinks that the moon landing was a hoax to the point that they would tell someone about it will know more about the moon landing than a random person who believes it was real.
It often takes an expert in something to shoot down the arguments.
> but people with fringe beliefs tend to dig a lot deeper
Do they actually, though? Or do they just look for endless superficial surface claims?
I mean, if they actually dug deep they're going to encounter all kinds of information that would indicate that the moon landing was real. Which, then, if they still maintain that it was a hoax in light of that then they have to believe that the deep information is also a hoax. So if someone really was digging deep into personal details of your life, then what they read about you must also be a hoax, naturally.
Which, given the concern, one may as well solidify by putting fake information out there about themself. No sane person is going to be searching high and low for details about your personal life anyway. A moon landing hoax believer isn't going to buy into a published academic paper or whatever breadcrumb you accidentally left as a source of truth to prove that you have a PhD when a random website with a Geocities-style design says that you never went to college!
There is an infinite supply of people spouting bullshit and validation of that bullshit on the internet. You can spend a lifetime reading through that bullshit, and certainly feel like you're "doing research".
I am utterly fascinated by the flat earth movement, not because I believe in a flat earth, but because it's so plainly idiotic and yet people will claim they've done experiments and research and dug deep, primarily because they either don't know how to read a paper or how to interpret an experiment or simply don't know how lenses work. It's incredible.
> You can spend a lifetime reading through that bullshit, and certainly feel like you're "doing research".
I'm not sure broad and deep are the same thing, but maybe we're just getting caught up in semantics?
> It's incredible.
Does anyone truly believe in a flat earth, though, or is it just an entertaining ruse? I hate to say it, but it can actually be pretty funny watching people nonsensically fall over themselves to try and prove you wrong. I get why someone would pretend.
> I'm not sure broad and deep are the same thing, but maybe we're just getting caught up in semantics?
They’re not the same thing but I think they’re still going “deep” in that they will focus very heavily on one subject in their conspiracy rabbit hole.
> Does anyone truly believe in a flat earth, though, or is it just an entertaining ruse?
I think that a lot of people are faking, but I am pretty convinced that at least some people believe it. There was that dude a few years ago who was trying to build a rocket to “see if he could see the curve”, for example.
I have seen some fairly convincing vlogs where the people at least seem to really believe it.
> I think they’re still going “deep” in that they will focus very heavily on one subject in their conspiracy rabbit hole.*
Which is totally fair, but may not be what I imagined when I said "deep".
> There was that dude a few years ago who was trying to build a rocket to “see if he could see the curve”, for example.
Building a rocket sounds like fun, to be honest. If you are also of the proclivity that you are entertained by claiming to believe in a flat earth, combining your hobbies seems like a pretty good idea.
> I have seen some fairly convincing vlogs where the people at least seem to really believe it.
At the same time people don't normally talk about the things they (feel they) truly understand. It is why we don't sit around talking about 1+1=2 all day, every day. Humans crave novelty. It is agonizing having to listen to what you already know. As such, one needs to be heavily skeptical of someone speaking about a subject they claim to understand well without financial incentive to overcome the boredom of having to talk about something they know well. And where there is financial incentive, you still need to be skeptical that someone isn't just making shit up for profit.
When someone is speaking causally about something, you can be certain that either: 1) They recognize that they don't have a solid understanding and are looking to learn more through conversation. 2) Are making shit up for attention.
There is no good way to know how many flat earthers never speak of it, I suppose, but as far as the vocal ones go I don't suppose they are really looking to learn more...
Linkedin is editable, no? Maybe he could still find it in a cache if he digs deep enough, but I mean, really, it is highly unlikely that anyone is going to put in that much effort unless they are on a mission. Nobody casually cares.
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).
The shift from "expert with answers" to "facilitator of clarity" is something a lot of leads struggle with, especially when they get promoted because they were the smartest dev on the team
Stealing the terms "expert with answers" and "facilitator of clarity." Those are brilliant ways to distinguish those roles. (Complicated by the fact that sometimes you have to switch between these constantly within the same role.)
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.
“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.
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.
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.
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.
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.
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.
"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.
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.
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?
> What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good.
I would say that they are pretty average.
First I am not sure what you mean by "know-it-all", specifically if this is a positive trait or not. Let's say that it is positive.
In that case age does not matter much because you can have extremely good practices that are simply outdated. Yes they work. Yes, they are stable. But they may not be adapted to the current needs.
So age is not a good differentiator for me.
Now, if you drop "older" I agree with you (with the assumption of a positive meaning for know-it-all)
>First I am not sure what you mean by "know-it-all"...if you drop "older"
good lord, in those phrases he was quoting the wording in the comment he was replying to.
I don't know if you are young or old, but I'd like to teach you about threading (and we won't stop till you get it or your eyebrows are gone)
I have no idea what you are talking about. Could you please rephrase this in simple words adapted to my age?
The post that this thread is replying to uses the phrase "know it all" and it's pretty obvious what OP meant.
The person kvetching at you about not understanding threading is making a joke because there's also a process called "eyebrow threading."
HN is supposed to be high quality discourse and you have to be on your toes if you want to participate!
Missing context, and missing references, and doubling down when you're called out is NOT the optimal strategy.
> HN is supposed to be high quality discourse and you have to be on your toes if you want to participate!
I am so sorry not to be at the correct level and, as a non English speaker, not to know all the references.
I feel so ashamed, fortunately you enlightened me about the high quality discourse I was missing.
Thank you very much for your kindness.
>> The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes.
Disagree. This can be very bad, but the worst situation I had was a very experienced developer with poor social skills making decisions for the team without a complete understanding of the entire picture
Chances based on my experience? 50:50
Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't updated my judgement since, despite the world having changed a lot".
The problem is that unless you really know things inside out or know the hard held opinions of your older collegue well, it can be hard to tell the two apart. In that case it only helps to talk about it in more detail and try to get to the root of where the judgement comes from. Then it could come to light that the warning to use PHP comes from a bad experience with PHP version <1.0 or that there is a number of bad experienced that are really useful for deciding the direction of a project.
In the end many decisions are about taste. And nothing is as good as a way to keep arguing than matters of taste. Weigh all the pros/cons and make a choice.
I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today.
For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently.
Like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field.
All those habits proved to be bad in the long run. And today memory (and disk space) are abundant. But these old habits are hard to break.
And that's before we talk about "modern" techniques, like version control etc.
Experience is great. I'm a fan. But all too often experience is also "there was a bug I windows 95, so that API call is unreliable ".
>many older folk...like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field. All those habits proved to be bad in the long run.
I'll bet you the people inventing these modern new architectures are among the more experienced engineers at the companies
who I would criticize by saying, we used to think it was a good idea to code around the limitations of old architectures and now we're accused of coding for PDP-11s and processors aren't PDP-11s any more. so what we should do now I'm told is code very specifically around the idiosyncracies of the new PDP-11,000's and that is what marks progress. Caches were invented to invisibly and silently make things faster, and that was a brilliant idea. Now new cache designers analyze what we used to do to insist we change how we code so they can cache what they want to cache not what we want to do, and all younger programmers talk about these days is coding for the cache (which itself is a cache of a cache of a cache). this is not progress, it's coding for the timing of the modern storage drum.
You can still obtain a ton of performance by minimizing the size of right things, processor caches are relatively small still. Stuff like the order of columns in a postgres database can still at worst multiply your table size
Yes, but we went from a time where these optimizations were absolutely unavoidable (so unavoidable that programmers would sacrifice any other thing for it) to one where the optimizations may be a nice to have, but for most organizations the maintainability of the code is much more crucial.
As mentioned before there are exceptions, like embedded programming, anything that needs to be finished within predictable time (game code, graphics, DSP code, etc). But even if you write a thing for a company website today I wouldn't dare to answer if making the code 10% less readable to make it use memory 10% less memory is a good trade off. Not that redability and memory use are necessarily mutually exclusive goals, but if you highly optimize code for one dimension, others will suffer at some point. And if you come from a generation where memory usage was king, it could be that you make these trade offs out of habit or principle despite them maybe no longer aligning with the goals of the project you're working on.
Anybosy who is good at their craft will choose how to deal with trade offs depending on the needs of the project and not based on remembered tradition.
With 20 years of experience in website development, I have led various site speed optimization teams. From my background, I pay particular attention to assets, JS profiling, and related aspects whenever I work on a web app. These practices are so ingrained that I perform them automatically and transparently, as they have been part of my process ever since.
The same thing might happen to these engineers when working on existing or new projects and writing C/C++ code; these optimizations will be part of their process.
Until the cost of storage is 0, this is all still a thing.
I was born in the 90s so memory has been plenty for me during my programmers journey. Until I started doing more embedded signal peocessing stuff.
It is good to know how to use memory efficiently, even today. But it is also important to know that if you optimize for memory usage or speed you may be paying in another dimension. And in my experience a certain type of old programmer can have a total lack of awareness that e.g. in some cases readability, maintainability, ease of use for developers, display latency etc. can be dimensions that are priorized over another for really good reasons.
The admin equivalent of that is somebody who provisions the same hard disk space for a server today as they did in the 2000s and then have the machine run out of memory on every fourth kernel upgrade. It is good to only use the necessary resources, but not if you can't/won't handle the ugly consequences that may come with it.
> today memory (and disk space) are abundant.
It still has a cost though, which needs to be taken into account in many situations. At our company the cost of compute, RAM, and storage are some of the biggest ongoing concerns, which can make the difference between profitability and bankruptcy, and we’ve done a lot of work on it.
Especially in the cloud, where RAM is extremely expensive, and you're encouraged to go for very ram-inefficient horizontal scaling architectures.
>Weigh all the pros/cons and make a choice.
This is sound advice when people agree on which column things belong to :)
That would mean you're not on one page with the others about what the project is meant to achieve and what not.
E.g. let's say one library is more privacy friendly and the other allows more data collection, depending on the project both could be pro or con. I respect developers who value privacy, but if you don't know whether a program is meant to collect data by the point you discuss library choices that eindicates either bad project planning, bad communication or both.
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/
I don’t think that is a practical framework for situations where people aren’t already very closely aligned. What happens when a few people are very vocal (and firm) in opposition to basically every change? Having dissenting views is valuable, but not when they have veto power. Additionally, I think that framework is vulnerable to what I refer to as “death by yes but” - when everyone is just piling on amendments and precursor conditions, oftentimes conflicting, that result in a decision taking months (maybe even years) to make or scuttle.
I’m basing these comments out of experience - one example is a workgroup/committee operating under a similar model that was completely unable to do anything due to decision paralysis. The committee grew significantly more effective when we reformed the decision making process to have a small group of owners to handle pitching and (potentially) implementing the decision, then had approval be a simple yes/no majority vote.
>> 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.
> I don’t think that is a practical framework for situations where people aren’t already very closely aligned.
Putting aside the concept of Sociocracy for the purpose of discussing engineering team leadership philosophies, one which I have observed to be very effective when working with experts is Servant Leadership[0]. From the Wiki page:
While Servant Leadership[0] might initially raise concerns resembling the problems you rightly identify with a sociocratic approach, it has the benefits of peer collaboration combined with accountability of the decisions made by leadership.0 - https://en.wikipedia.org/wiki/Servant_leadership
Yes it only works when participants have a shared aim
In full sociocracy, it...
> honors the circle’s ability to freely make decisions within its domain. This is key for the organization to remain effective. But it comes at the cost of members not having “consent rights” to every decision the organization makes. Each member will only have those rights for the circles they are a part of.
So it's not necessary to allow people outside that working group to veto or require compulsory followup through objection
There's no perfect solution to organization, everything is a tradeoff. I've also been part of working groups (made of people whose job description is to manage the scope of changes they're proposing) where everyone and the workers impacted by the decisions are in agreement and no impact on cost etc., but the exec decides no change can be made due to personal preference despite disastrous consequence. Or where an exec who abstains from checking in on a working group's efforts nonetheless counters it with shifting and contradictory demands whenever it comes time to take action, requiring going back to the drawing board repeatedly until people simply give up or leave the organization. Or where the exec asks for more data for a proposal, and then doesn't evaluate the data once gathered, leaving no recourse but to give up or leave the organization. We all have stories like this. Hierarchical organizations are also susceptible to paralysis.
I've often taken inspiration from RFC 2418, "IETF Working Group Guidelines and Procedures" [1], a rare RFC that defines a human protocol ("rough consensus") rather than a technical one.
[1] https://www.rfc-editor.org/rfc/rfc2418.html
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.
You can also try to organize your peers in those environments (or even from the outside if so inclined)
It's not autocratic, it's not a form of government at all.
Each role is a module to take in inputs, process them, and produce outputs. it is effectively a program.
Define your roles, and expectations of each role, then run the program and edit as needed.
Right, and some people’s role is to organize people and orient the group’s efforts by taking in big-picture problems and outputting direction.
There’s rarely a single correct answer— lots of good solutions have trade-offs— but there are often various wrong answers. Do the best you can to avoid the wrong answers, and when you inevitably run into the business end of one of your trade-offs, take comfort in knowing the other good options probably also had trade-offs, and tell the smug know-it-alls to cram it.
People working effectively towards a non-optimal solution is far more useful than sitting around arguing about the best way to do it.
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.
One thing I like to do with sr+ engineers who will feel burned by a decision - esp. those very publicly against it - is to lead with some sort of concession... maybe a project they expressed interest in, greenlight for a week to research some POC.
Whatever it is, it tends to be considerably less value to the business than the decision itself, but it directly acknowledges their discontent and allows them to get something out of the process besides platitudes, (perceived) public embarrassment, and frustration.
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
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.
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.
This is what we do with juries, so there's something to be said for it.
locking people in sure achieves at least one thing, but then so does adding two zeros. Jobs locked staff in, at Google when you a book meeting room, the wifi and lights cuts off at the end - a kill-switch approach [1].
personally, I think those hacks are cute and handy, but once you recruit well, reward and empower your staff, leading becomes much easier. At google, that approach probably helped more with their ESG policies than staff productivity. In Jobs' case, probably helped "him" stay focused rather than his staff, a meditation technique of sorts lol
Re: Juries. wasn't the main reason to prevent the world outside the court from influencing their decision?
[1] I think it's on How Google Works
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.
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.
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.
If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
If they're not getting the same inputs to their decisions as you are, why are you hamstringing them?
And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?
> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
This doesn’t seem realistic to me. Division of labor also implies division of decisions. Mature individuals and teams will acknowledge when there are decisions they’re not able to make, and will refer them to the relevant teams.
An obvious example of this is legal: it hardly ever makes sense to leave a legal decision to a software developer or development team. But similar logic can apply to product management decisions, customer success, security, etc.
> An obvious example of this is legal
How is that an example? Legal is just an input. A mature individual is going to heed the advice from legal, most certainly, but legal isn't making the final decision. Legal doesn't know anything about all of the other constraints, like customer need and technical need. If they did, they wouldn't be working as legal council, they'd be doing the job we're talking about.
So, we're right back at the previous comment:
- If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
- If they're not getting the same inputs to their decisions as you are, why are you hamstringing them?
- And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?
Also, to ensure that the decision made is based on logic and reason. Insofar as that is even possible.
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.
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.
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.
“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
There's a difference between defaulting to authority and resorting to it when needed. Consensus is great until it turns into paralysis
> "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.
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.
> I've worked with engineers like this, who have a massive god-complex.
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."
> "I'm the lead, and we are going to do it this way"
"Okay. Let me know when you are done with that."
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.
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.
Unrelated: So your name is Ahmed from Tunisia living in the Capital :)
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.
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.
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.
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
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.
And to be honest, the real leader was not even in the room, it was the one who brought us together and threw us in a room to do it.
> And to be honest, the real leader was not even in the room, it was the one who brought us together and threw us in a room to do it.
If this is not a fantastic exemplar of servant leadership, then I have never heard of one.
It takes real confidence (and restraint) to let strong engineers run with their ideas without feeling the need to course-correct every detail
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...
> 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
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.
What's the alternative?
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.
I agree, though well designed software, even big monoliths, can be written in a way that isn't too hard to distribute later.
For example, if you utilize asynchronous queues everywhere, instead of something like a shared-memory mutex, it's relatively straightforward to turn that into some kind of networked queue system if you need to. Pretty much every language has a decent enough queue implementation available.
Asynchronous queues make your data out of sync (hence the name) and inconsistent one of the main downsides of microservices. Their use should be minimized to cases where they are really necessary. A functional transactional layer like postgres is the solution to make your state of truth accessed in a synchronized, atomic, consistent way.
No, I disagree with that completely actually.
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.
I'll agree that the network layer adds more problems to microservices, but even with a perfect network, they are problematic. Everything being out of sync, (if they are stateful microservices which queues imply), is one big issue. Things being interconnected in broad global scopes instead of more locally scoped is the other big issue.
The more you have globally interconnected and out of sync states, the less predictable your system is.
The solution is to be as hierarchical, as tightly scoped, as functional and as transactional as you can.
That's how you tackle complexity and create intelligent systems: https://benoitessiambre.com/entropy.html
I think we are at a fundamental disagreement on this.
You can make asynchronous code predictable if you utilize something like TLA+, or treat the code as a protocol system.
To add to this. There's fundamental theoretical reasons why microservices or bad. They increase the entropy of code (https://benoitessiambre.com/entropy.html) by increasing globally scoped dependencies. They are the global variables or architecture. Having lots of interconnected global variables makes for an unpredictable chaotic system.
This doesn't actually answer the question in any way though. Say you've already built the thing that works and then split it up, then what?
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.
Except you totally do wind up coordinating with them in practice when it's not google but a small team within your org.
Yes, in practice you very well might end up there, but then you are not providing microservices and would not call it as such. But it remains that microservices is the solution. Fair to say that it is the solution like not eating too many calories is the solution to losing weight — as in it is not exactly fun to have to put yourself through it, and thus most with the problem will never try to fix it/give up — but the solution all the same.
Or even, someone leaves and you end up with a mess of maintaining multiple services that aren't coherently seperate at all, but have no time to refactor them together to make sense. That's been my experience.
Macroservices, or several megaliths instead of one monolith, if you will.
What about going the other way and Unix-piping together hundreds of thousands of nano-services?
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.
I love the distribution of answers to this.
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.
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.
Probably better to say "because it is a bikeshed not worth debate". Often there isn't a right answer but a decision is needed.
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".
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.
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.
> 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.
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.
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.
There's both less and more to making decisions than ensuring they get made.
First: get others to actually decide. Jean-Louis Gassee at Apple (componentized mac's in the late 1980's) said that when dueling managers brought him a decision to make, he would always come up with a decision both of them hated, so they would scurry away and work together with an alternative they could live with.
Second: be sure to get everyone really on board - you first. This is really hard for managers who are following the wind. Law students are often careful and analytical, hedging every evaluation, but lawyers have to be assertive. Although they understand the precariousness of the legal position, it only works if you convince everyone (on your side and theirs) that this is how it will be. That transition is typically what weeds out new attorneys, and distinguishes partners from associates.
(Before you object to the attorney analogy: it's nice when you achieve collegial scientific consensus, but it can be a luxury. Then you have to figure out how to compel people do want they don't want to do, without straining authority. Usually it works to focus on picking a customer, or a definite time for results to appear; a more concrete objective/goal explains the decision and focuses follow-through.)
> I 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.
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.
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.
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.
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.
Need ethos, logos and pathos. Not just the logos.
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.
> 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.
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.
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?
In my experience that's usually just the tip of the iceberg. You've heard the expression "All happy families are alike; each unhappy family is unhappy in its own way"? It's like a link broke in a chain, and usually it's many links correlated. Maybe they just distrust expertise, well I have a phd and I assure you it'll come up later. Maybe he's an immigrant from Russia and he just distrusts everything to do with the news, well that's not really fixable except maybe with many years of therapy. And yes it will come up later too. I'm not a professional, I didn't want to ask the specifics or get into the weeds, I just have a developed nose for these things. My brother is into conspiracy theories.
> I have a phd and I assure you it'll come up later.
Will it? One would have to dig pretty deep into one's personal life to learn about that. Someone who thinks COVID was a hoax isn't going to be one to dig deep. And, well, if he really did somehow dig deep enough to find that information, you can just laugh it off as a hoax.
> Someone who thinks COVID was a hoax isn't going to be one to dig deep.
This is kind of a side point, but people with fringe beliefs tend to dig a lot deeper to validate those opinions than those with a mainstream view.
You can bet that someone who thinks that the moon landing was a hoax to the point that they would tell someone about it will know more about the moon landing than a random person who believes it was real.
It often takes an expert in something to shoot down the arguments.
> but people with fringe beliefs tend to dig a lot deeper
Do they actually, though? Or do they just look for endless superficial surface claims?
I mean, if they actually dug deep they're going to encounter all kinds of information that would indicate that the moon landing was real. Which, then, if they still maintain that it was a hoax in light of that then they have to believe that the deep information is also a hoax. So if someone really was digging deep into personal details of your life, then what they read about you must also be a hoax, naturally.
Which, given the concern, one may as well solidify by putting fake information out there about themself. No sane person is going to be searching high and low for details about your personal life anyway. A moon landing hoax believer isn't going to buy into a published academic paper or whatever breadcrumb you accidentally left as a source of truth to prove that you have a PhD when a random website with a Geocities-style design says that you never went to college!
There is an infinite supply of people spouting bullshit and validation of that bullshit on the internet. You can spend a lifetime reading through that bullshit, and certainly feel like you're "doing research".
I am utterly fascinated by the flat earth movement, not because I believe in a flat earth, but because it's so plainly idiotic and yet people will claim they've done experiments and research and dug deep, primarily because they either don't know how to read a paper or how to interpret an experiment or simply don't know how lenses work. It's incredible.
> You can spend a lifetime reading through that bullshit, and certainly feel like you're "doing research".
I'm not sure broad and deep are the same thing, but maybe we're just getting caught up in semantics?
> It's incredible.
Does anyone truly believe in a flat earth, though, or is it just an entertaining ruse? I hate to say it, but it can actually be pretty funny watching people nonsensically fall over themselves to try and prove you wrong. I get why someone would pretend.
> I'm not sure broad and deep are the same thing, but maybe we're just getting caught up in semantics?
They’re not the same thing but I think they’re still going “deep” in that they will focus very heavily on one subject in their conspiracy rabbit hole.
> Does anyone truly believe in a flat earth, though, or is it just an entertaining ruse?
I think that a lot of people are faking, but I am pretty convinced that at least some people believe it. There was that dude a few years ago who was trying to build a rocket to “see if he could see the curve”, for example.
I have seen some fairly convincing vlogs where the people at least seem to really believe it.
> I think they’re still going “deep” in that they will focus very heavily on one subject in their conspiracy rabbit hole.*
Which is totally fair, but may not be what I imagined when I said "deep".
> There was that dude a few years ago who was trying to build a rocket to “see if he could see the curve”, for example.
Building a rocket sounds like fun, to be honest. If you are also of the proclivity that you are entertained by claiming to believe in a flat earth, combining your hobbies seems like a pretty good idea.
> I have seen some fairly convincing vlogs where the people at least seem to really believe it.
At the same time people don't normally talk about the things they (feel they) truly understand. It is why we don't sit around talking about 1+1=2 all day, every day. Humans crave novelty. It is agonizing having to listen to what you already know. As such, one needs to be heavily skeptical of someone speaking about a subject they claim to understand well without financial incentive to overcome the boredom of having to talk about something they know well. And where there is financial incentive, you still need to be skeptical that someone isn't just making shit up for profit.
When someone is speaking causally about something, you can be certain that either: 1) They recognize that they don't have a solid understanding and are looking to learn more through conversation. 2) Are making shit up for attention.
There is no good way to know how many flat earthers never speak of it, I suppose, but as far as the vocal ones go I don't suppose they are really looking to learn more...
It's right on my linkedin, and I'm joining their team as a specialist/consultant.
Linkedin is editable, no? Maybe he could still find it in a cache if he digs deep enough, but I mean, really, it is highly unlikely that anyone is going to put in that much effort unless they are on a mission. Nobody casually cares.
[dead]
The author has read the audio for the article themselves?! Amazing
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).
The shift from "expert with answers" to "facilitator of clarity" is something a lot of leads struggle with, especially when they get promoted because they were the smartest dev on the team
Stealing the terms "expert with answers" and "facilitator of clarity." Those are brilliant ways to distinguish those roles. (Complicated by the fact that sometimes you have to switch between these constantly within the same role.)
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.
“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.
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.
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.
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.
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.
Excuse me, but I am a Tech Lead, not a people lead - now let me lead some technology, please! What in the actual ...
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
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.
"You are not going to convince anyone with facts." ... Lost me here. What kind of organization doesn't run on facts?
Most?
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.
That just makes you sound like a weasel and destroys your trust.
It was a joke about how AI loves to tell you that you’re right but then it regurgitates its prior plan verbatim.
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.
[dead]