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
How to Lead in a Room Full of Experts
101–110 of 146 posts
Re: How to Lead in a Room Full of Experts
#102Earlier quoted context omitted.
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…
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.
Re: How to Lead in a Room Full of Experts
#103"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…
There's a difference between defaulting to authority and resorting to it when needed. Consensus is great until it turns into paralysis
Re: How to Lead in a Room Full of Experts
#104I 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…
It takes real confidence (and restraint) to let strong engineers run with their ideas without feeling the need to course-correct every detail
Re: How to Lead in a Room Full of Experts
#105Thank 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.
Re: How to Lead in a Room Full of Experts
#106Earlier quoted context omitted.
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…
>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.
Re: How to Lead in a Room Full of Experts
#107The author has read the audio for the article themselves?! Amazing
Re: How to Lead in a Room Full of Experts
#108Earlier 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…
> 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)
Re: How to Lead in a Room Full of Experts
#109Earlier quoted context omitted.
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…
> 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.…
>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)
Re: How to Lead in a Room Full of Experts
#110Earlier quoted context omitted.
> 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.…
> 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?