4 ms·

My best leaders have been those who "share their Legos", so to say. That don't hoard information, but instead step aside and let others take on more responsibil

My best leaders have been those who "share their Legos", so to say. That don't hoard information, but instead step aside and let others take on more responsibility. My first tech lead when I started working had a great reputation. Everyone in the company knew him. I looked up to him. He knew everything! Whatever feature I worked on and needed to ask details about our integration partner, he could answer. Only later did I realize it was more because he had put himself in the middle, than it actually being helpful. I was the one working on something, but he was the one going to all meetings and talking with others. It made it harder for me, never being directly involved. Maybe it made him feel more useful, enjoying being the goto-guy etc? Then I got a new tech lead, and she was the one that made me realize what a manager could be. She encouraged me to own the stuff I was working on completely, and joined meetings more as a backup for me but wanted me to be the main point of contact. Instead of being the middleman of everything, she instead enabled me and mentored me. So I've always aimed to be like her. Now that I'm at 10 yeo experience, can I enable those "under" me and let them learn by allowing them to take on some of my responsibility? It's a constant conscious decision, because the default is to keep feeling important.

ulnarkressty 2y ago
That's an interesting viewpoint, since the usual mantra is 'a good manager protects the engineer' by going to meetings and letting them do deep work without distraction. Maybe in your case she saw the potential of a future lead/manager and wanted to push you in that direction?
- small_scombrus 2y ago
  I imagine it depends on the type of meeting and how many pointless busywork meetings a company mandates
- PaulRobinson 2y ago
  (Good) meetings are deep work. Too many engineers think that engineering work is sat in front of the thing they're building, building it. You need to know what to build. You need feedback on how to build it (no matter how experienced you are, you want other perspectives to help improve your thinking). You need feedback on iterations. You need to discuss and get ideas on problems. These are all done with other people. The best way to discuss them with other people is not to swing by and have a chat. It's to block out some time. If you spend too much time in meetings, the balance is wrong. But so is too little. If your manager is going to the meetings, you're not being a good engineer, and they're not letting you be a good engineer. I'd recommend to try and block these up a bit, have meeting free days and the like, but if you're the kind of engineer who thinks meetings are not work, you're going to lose out to those engineers who want to collaborate and engage with colleagues, partners and other stakeholders.
  - hengheng 2y ago
    Love your point. > (Good) meetings are deep work Sadly not enough managers think that either. I've seen a hierarchy where managers only pay attention when their superiors are around. Day-to-day engineering meetings were not their moment to shine, so they took those meetings from the car driving in. The other option, railroading meetings with a strict slide deck, is also not the way to get engineers' minds to engage. Good meetings are deep work, but there are two sides to it, and it must be lived in the culture.
  - rvense 2y ago
    > You need to know what to build I like to refer to this as "the hardest problem in computer science." Several times over my ten-year career I've spent months building a thing to what we thought were the specs, only to have to throw most of it away because the specs change at the last minute, or somebody learned the hard way that details like are you paying for access to the thing, or access to the group the thing is in can actually matter a whole lot when you're building software. I would say I nearly always spend more time defining the problem than solving it.
    - 2OEH8eoCRo0 2y ago
      This was my work in defense. Weeks or months are spent in design and the code itself only takes a few days. Now at my company teams will spend no time planning, code like crazy, only to redo it multiple times. Illusion of progress. There must be a middle ground.
      - azemetre 2y ago
        Is this the core tenant of agile development? To release often and speak to stakeholders often? The hardest part is deciding when to do that first release I suppose.
        necovek 2y ago
        As soon as you've got something releasable. Though, you should break work up in a way to get to something releasable asap. The latter is where I think it's more art than science still, or at least I can't come up with a good written process on how you do it (other than the constant "where is the value in this" and "what's the smallest thing we can build" questioning), but I can always do it!
- roenxi 2y ago
  It depends a lot on the meeting. If the meeting is scoping work (and with a clear agenda), important/rare context or honest feedback then the developer being involved will increase the likelihood of the project succeeding. If the meeting is status reports or other requests for information then maybe block them from going. The issue is that the person developing needs access to as much real data as possible (which may be found in a meeting) but as much shielding from the scar tissue of bureaucracy as possible. Bureaucrats should spend time talking to team leads, developers should spend time talking to people with real problems that need solving. The dividing line between those two things involves judgement. And some projects developer productivity is guaranteed to be low from the get go and their meeting attendance barely matters (eg, how developers spent their time prior to the project being re-scoped isn't so impactful).
- golly_ned 2y ago
  I had an inexperienced manager who followed this tack of protecting me from meetings, over my objections. What ended up happens was I lost crucial context. I think he just didn’t know how to be useful as a manager. He’s now a staff engineer elsewhere. Good for him.
dakiol 2y ago
I never understood the “encourage others to take ownership” manager thing. I mean, I can do the same and encourage others to do things and that would let me with very little actual work to do. Like, why would I even be necessary as “manager that encourage things” if we have to begin with engineers that are paid to take on ownership from the very beginning?
- apsurd 2y ago
  There's a good and bad way to be the manager that encourages taking ownership. You're skeptical of the lazy type. it's masked also as "delegation". ICs tasked with doing literally everything, and yes it can get ridiculous, but even then the ICs do learn outsized skills. The good kind is in medium to large companies there's definitely middle management needs that must be done. A good manager is doing and shielding you from those things. The ownership is about domain, skill, and project expertise. People closest should be in positions of ownership. A manager is the grease in the machine.
- ghaff 2y ago
  There's taking ownership of a project without being micro-managed and there's having to deal with everything from above and sideways in a large organization. I have certainly been in roles where I got insulated from a lot even if I had a lot of day-to-day autonomy.
- idiotsecant 2y ago
  A manager should be intercepting requests for your time and prioritizing your work. There are always more things that need doing than there are hours for you to do them in. They should know what is important, and steer the ship appropriately while you're out gathering requirements, analyzing, building, and iterating based on feedback. They should also, depending on the engineer, periodically be checking in to make sure that you're on track and not spinning your wheels.
stuckindoors 2y ago
This. We need to stop admiring flashiness. We need to start admiring people that bring out the best in others. Our brains instantly turn to the glitteriest/loudest/fanciest object in the room. It is hardwired for some reason - unfortunately in this day and age that will no longer help us in the long run. Turning to sports, Nikola Jokic is one of these people...you can see his quite leadership everyday. He is selfless on the court, bringing out the best in his teammates, he hates the lime light. He celebrates his rivals. This is such a poor example compared to that wonderful article linked, I but I truly hope my kids internalize some of the value that he demostrates especially in this day and age of awfulness elsewhere.
TechDebtDevin 2y ago
There's a lot of people that just aren't capable of releasing control like that.
- tayo42 2y ago
  I think it's a sign of a non toxic environment to work in too. Somewhere that does t require political games and you can trust your leaders. Now we have endless and repeated layoffs and executives telling us we'll be replaced by computers. Gotta hold on to everything.
caminante 2y ago
> Only later did I realize it was more because he had put himself in the middle, than it actually being helpful. It doesn't feel good at first, but you just have to re-frame it. I've found that many people who complain about this are really not about that life of political games and constant, low effort interruptions on MSFT Teams. For self-aware individuals, the resentful/villain narrative dissipates and individuals embrace the benefits of a buffer. The layers can mean a much more leisurely pace for a paycheck.
ryandvm 2y ago
Wild. I would have loved your first manager and hated your second. I want to build and I have zero interest haggling with stakeholders over minutiae. I'll take a good buffer manager that understands the problem space any day.
- azemetre 2y ago
  It is interesting to think about. Someone like the first manager is actually very valuable at a company where people leave very quickly, especially in an industry where most of your coworkers will have been at the company for less than 5 years. How much can you truly know about the system if you're going to leave the job in a year or two? How much would you invest? The only issue with the first manager, IMO, is that they weren't willing to share knowledge or help elevate others. You can understand as much as them and still encourage others and help people grow. No reason why the first manager and second manager couldn't be a single person.
  - matsemann 2y ago
    But what if the first manager leaves? He's made himself too important.
    - necovek 2y ago
      Someone might think so, but ultimately, nobody is (too important).
- matsemann 2y ago
  I think you're reading things into it I never stated. Like, those meetings weren't "haggling minutiae with stakeholders", he wasn't a good buffer. I couldn't "build" when I didn't know what to build.

ulnarkressty 2y ago

That's an interesting viewpoint, since the usual mantra is 'a good manager protects the engineer' by going to meetings and letting them do deep work without distraction. Maybe in your case she saw the potential of a future lead/manager and wanted to push you in that direction?

small_scombrus 2y ago
I imagine it depends on the type of meeting and how many pointless busywork meetings a company mandates
PaulRobinson 2y ago
(Good) meetings are deep work. Too many engineers think that engineering work is sat in front of the thing they're building, building it. You need to know what to build. You need feedback on how to build it (no matter how experienced you are, you want other perspectives to help improve your thinking). You need feedback on iterations. You need to discuss and get ideas on problems. These are all done with other people. The best way to discuss them with other people is not to swing by and have a chat. It's to block out some time. If you spend too much time in meetings, the balance is wrong. But so is too little. If your manager is going to the meetings, you're not being a good engineer, and they're not letting you be a good engineer. I'd recommend to try and block these up a bit, have meeting free days and the like, but if you're the kind of engineer who thinks meetings are not work, you're going to lose out to those engineers who want to collaborate and engage with colleagues, partners and other stakeholders.
- hengheng 2y ago
  Love your point. > (Good) meetings are deep work Sadly not enough managers think that either. I've seen a hierarchy where managers only pay attention when their superiors are around. Day-to-day engineering meetings were not their moment to shine, so they took those meetings from the car driving in. The other option, railroading meetings with a strict slide deck, is also not the way to get engineers' minds to engage. Good meetings are deep work, but there are two sides to it, and it must be lived in the culture.
- rvense 2y ago
  > You need to know what to build I like to refer to this as "the hardest problem in computer science." Several times over my ten-year career I've spent months building a thing to what we thought were the specs, only to have to throw most of it away because the specs change at the last minute, or somebody learned the hard way that details like are you paying for access to the thing, or access to the group the thing is in can actually matter a whole lot when you're building software. I would say I nearly always spend more time defining the problem than solving it.
  - 2OEH8eoCRo0 2y ago
    This was my work in defense. Weeks or months are spent in design and the code itself only takes a few days. Now at my company teams will spend no time planning, code like crazy, only to redo it multiple times. Illusion of progress. There must be a middle ground.
    - azemetre 2y ago
      Is this the core tenant of agile development? To release often and speak to stakeholders often? The hardest part is deciding when to do that first release I suppose.
      - necovek 2y ago
        As soon as you've got something releasable. Though, you should break work up in a way to get to something releasable asap. The latter is where I think it's more art than science still, or at least I can't come up with a good written process on how you do it (other than the constant "where is the value in this" and "what's the smallest thing we can build" questioning), but I can always do it!
roenxi 2y ago
It depends a lot on the meeting. If the meeting is scoping work (and with a clear agenda), important/rare context or honest feedback then the developer being involved will increase the likelihood of the project succeeding. If the meeting is status reports or other requests for information then maybe block them from going. The issue is that the person developing needs access to as much real data as possible (which may be found in a meeting) but as much shielding from the scar tissue of bureaucracy as possible. Bureaucrats should spend time talking to team leads, developers should spend time talking to people with real problems that need solving. The dividing line between those two things involves judgement. And some projects developer productivity is guaranteed to be low from the get go and their meeting attendance barely matters (eg, how developers spent their time prior to the project being re-scoped isn't so impactful).
golly_ned 2y ago
I had an inexperienced manager who followed this tack of protecting me from meetings, over my objections. What ended up happens was I lost crucial context. I think he just didn’t know how to be useful as a manager. He’s now a staff engineer elsewhere. Good for him.

dakiol 2y ago

I never understood the “encourage others to take ownership” manager thing. I mean, I can do the same and encourage others to do things and that would let me with very little actual work to do. Like, why would I even be necessary as “manager that encourage things” if we have to begin with engineers that are paid to take on ownership from the very beginning?

apsurd 2y ago
There's a good and bad way to be the manager that encourages taking ownership. You're skeptical of the lazy type. it's masked also as "delegation". ICs tasked with doing literally everything, and yes it can get ridiculous, but even then the ICs do learn outsized skills. The good kind is in medium to large companies there's definitely middle management needs that must be done. A good manager is doing and shielding you from those things. The ownership is about domain, skill, and project expertise. People closest should be in positions of ownership. A manager is the grease in the machine.
ghaff 2y ago
There's taking ownership of a project without being micro-managed and there's having to deal with everything from above and sideways in a large organization. I have certainly been in roles where I got insulated from a lot even if I had a lot of day-to-day autonomy.
idiotsecant 2y ago
A manager should be intercepting requests for your time and prioritizing your work. There are always more things that need doing than there are hours for you to do them in. They should know what is important, and steer the ship appropriately while you're out gathering requirements, analyzing, building, and iterating based on feedback. They should also, depending on the engineer, periodically be checking in to make sure that you're on track and not spinning your wheels.

stuckindoors 2y ago

This. We need to stop admiring flashiness. We need to start admiring people that bring out the best in others. Our brains instantly turn to the glitteriest/loudest/fanciest object in the room. It is hardwired for some reason - unfortunately in this day and age that will no longer help us in the long run. Turning to sports, Nikola Jokic is one of these people...you can see his quite leadership everyday. He is selfless on the court, bringing out the best in his teammates, he hates the lime light. He celebrates his rivals. This is such a poor example compared to that wonderful article linked, I but I truly hope my kids internalize some of the value that he demostrates especially in this day and age of awfulness elsewhere.

TechDebtDevin 2y ago

There's a lot of people that just aren't capable of releasing control like that.

tayo42 2y ago
I think it's a sign of a non toxic environment to work in too. Somewhere that does t require political games and you can trust your leaders. Now we have endless and repeated layoffs and executives telling us we'll be replaced by computers. Gotta hold on to everything.

caminante 2y ago

> Only later did I realize it was more because he had put himself in the middle, than it actually being helpful. It doesn't feel good at first, but you just have to re-frame it. I've found that many people who complain about this are really not about that life of political games and constant, low effort interruptions on MSFT Teams. For self-aware individuals, the resentful/villain narrative dissipates and individuals embrace the benefits of a buffer. The layers can mean a much more leisurely pace for a paycheck.

ryandvm 2y ago

Wild. I would have loved your first manager and hated your second. I want to build and I have zero interest haggling with stakeholders over minutiae. I'll take a good buffer manager that understands the problem space any day.

azemetre 2y ago
It is interesting to think about. Someone like the first manager is actually very valuable at a company where people leave very quickly, especially in an industry where most of your coworkers will have been at the company for less than 5 years. How much can you truly know about the system if you're going to leave the job in a year or two? How much would you invest? The only issue with the first manager, IMO, is that they weren't willing to share knowledge or help elevate others. You can understand as much as them and still encourage others and help people grow. No reason why the first manager and second manager couldn't be a single person.
- matsemann 2y ago
  But what if the first manager leaves? He's made himself too important.
  - necovek 2y ago
    Someone might think so, but ultimately, nobody is (too important).
matsemann 2y ago
I think you're reading things into it I never stated. Like, those meetings weren't "haggling minutiae with stakeholders", he wasn't a good buffer. I couldn't "build" when I didn't know what to build.