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.

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

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.

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.

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!

If you want a successful example in a traditional engineering industry, you don't need to look further than SpaceX vs Boeing and their rocket development (one got a smaller budget and blew up a number of rockets and has been earning money for 4+ years, the other got twice the grant and wasn't trusted to bring astronauts back from ISS a few months ago).

Figure it out and get over yourselves (myself included).

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

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.

They should also, depending on the engineer, periodically be checking in to make sure that you're on track and not spinning your wheels.

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.

Now we have endless and repeated layoffs and executives telling us we'll be replaced by computers. Gotta hold on to everything.

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.

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.