Common Mistakes of New Engineering Managers

It certainly makes the job of a manager harder when you are forced to reckon with the fact that you can't just throw out coding without it undermining your ability to be a good manager. In practice, I would try to ebb-and-flow with the teams' needs - it's a dynamic, challenging process.

Also, there's a tricky issue of, as a report, being able to identify what is intentional vs unintentional. Your manager is probably failing you, but there's also a chance they are forcing you to grow by disengaging a bit and letting you fall into a few ditches. Sometimes a good coach will just shut up and let you make mistakes. Until you see the net effect of their behavior on you over an extended period, you can't know if you have a good coach who is pushing you in a way that you can't see, or a bad coach who is just failing you. A lot of people with good coaches resent them in the early days for being too hard, too disengaged, or other things, which forces them to push themselves harder.

So Plato's Republic describes how this comes about since ancient times, I wrote something a bit more detailed[1] about it.

But here's the TL;DR - the punishment is that he who refuses to rule is liable to be ruled by one who is worse than himself. And the fear of this, induces the good to take office, not because they would, but because they cannot help ... because they are not able to commit the task of ruling to any one who is better than themselves, or indeed as good.

Some are pulled into management because of the existing mastery and a looming management vacuum.

This isn't something new in tech - it has always been that competent people leave their mastery work to do management (rather politics of ensuring funding), because they see no other choice.

Until I found a manager who was better than I was (and once I understood how they did it and what they did all day), I did think in very similar lines, a little bit aided by the "I'm a smart guy" ego clouding my judgement.

[1] - http://notmysock.org/blog/philosophy/leading-up?h=1

Not sure whether you actually understand the issue raised by him/her -- the process of defining, designing and architecting a solution is very much something that an junior engineer would aspire to be able to take responsibility for one day. But under your working model, only one person (you) would be mainly responsible for doing that, and other people could only prove their worth by doing their piecemeal work (the small and isolated "projects") faster.

Not saying that this is actually true, and from your original comment it seems that it might not be completely true, but that's what the the gp commenter wanted to say. And you seem to confirm it in this comment -- you praise people who work fast but haven't seen you mention about their code quality or "taste" in architecture or design.

... and I haven't mentioned the retaliatory vitriol. Seriously, talk about jumping to conclusions...

Personally, I would wonder how you assess "delivered value", given that this is basically one of the hardest problems to solve involving questions about asthetics, ethics, business management, leadership, capitalism and even the worth of a person's time... but I'd jump to my own conclusions and will assume you think you have figured it all out :)

I entirely agree with you here - I disagree with the notion that "managers" (should) like those meetings any more than other folks. Most large block meetings are ineffective, the more effective ones have a strict agenda and someone moderating them with that agenda in mind. They can be useful for announcements or large-scale alignment, but most of them should be struck from the calendar with no replacement - and good managers recognize this and strive to do so.

> Effective meetings don't come from an individual transforming normally ineffective ones into effective ones by some form of wizardry over everyone else in the room, they come from a culture where everyone makes them effective together through shared values.

The person leading a meeting can make a substantial impact - being prepared, making an agenda and a plan, setting a clear goal for the meeting, deliberately limiting the number of people attending, requiring others to come prepared and enforcing that (possible adjourning the meeting if it turns out to be ineffective), time boxing. There's no magic place where all meetings are effective or feel effective for everyone, but there are places that try to improve and there are techniques that make improvement possible.