71–80 of 146 posts
“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.
Earlier quoted context omitted.
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…
>> 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.
"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 dut…
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…
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?
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 inter…
Thanks for sharing your experience.
EDIT:
Removed unnecessary qualification in the last sentence.
"You are not going to convince anyone with facts." ... Lost me here. What kind of organization doesn't run on facts?
Earlier quoted context omitted.
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…
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…
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 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.
Earlier quoted context omitted.
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 defi…
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.
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 inter…
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
> 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.
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.
Earlier quoted context omitted.
> 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…
> 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 hoa…
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.