But you already do. Unless you're working for a tiny startup, your CEO or the Board probably doesn't understand the specifics of your code.

You can't run a large company by making every person super-involved in every detail. You have layers of abstraction that make it possible to reason about an org of hundreds or thousands of employees. The Board trusts the CTO to oversee technology. Your CTO trusts your director / VP / whatever to run a large chunk of it. That person delegates a smaller part of running the company to your boss.

The whole point of each layer is to abstract away some of the underlying messiness. They exercise professional judgment for day-to-day operations and provide a clean interface that provides health signals, requests resources as needed, etc. And I think what many folks miss is that it doesn't stop with their boss. It stops with you! Your boss generally trusts you to make design and implementation decisions and is expecting you to provide a reasonable interface to that. If your boss has a reasonably-sized team but is spending their day writing code, then honestly, why are they in a management position to begin with?

Your post has an authoritative tone but is too reductive and dismisses the real world often working in a completely opposite way, so I’m not sure it’s a credible argument.

What is work? Work is of two kinds: first, altering the position of matter at or near the earth's surface relatively to other such matter; second, telling other people to do so. The first one is unpleasant and ill paid; the second is pleasant and highly paid.

I can think of 2 patches: first, "matter" ("it") can be replaced by "bit"..

(What is the nature of the responsibilities that come with telling people what to do? Towards those who pay, who, if they did not inherit, must also have been highly paid? Towards the work/workers: it certainly helps to understand the work, but if it is neither unpleasant nor necessary, then perhaps "supplying the why" shouldn't be called a responsibility :)

Doesn't make sense.

With 7 - 10 reports per manager, that means the higher up boss or CEO should know how to do the jobs of 350 - 1000 different people. (7*7*7)

Trouble comes when they don’t understand the work, but make decisions as if they do.

This is pretty far from the original example though.

But I also dont want to (and currently dont have to) explain specific risks regarding what I do, I dont have to justify how long things take, because my management understands that. We speak the same language. Its glorious.

I mean just comparing my clients that have relevant technical knowledge, vs the ones that dont, the clients that dont have that knowledge need "meetings" and "catchups" and immense email threads in the order of 10 times the ones that do understand. Thats measurable (to me) waste.

Another observation of mine is that non technical people really have no ability to recruit and manage technical people. I have seen multiple businesses brought low because the "technical" person brought in to manage the "technical" side of the startup actually had NFI. Or when they do accidentally hire someone competant, their requests for resources or time are ignored, even when well justified. The non technical founder or CEO either has to trust someone (which fails a lot) or they dont trust someone (and thats even worse).

Which they pay you for? Otherwise why don’t you drop them as clients? I’m unclear how that’s “waste” from a business perspective.

Most of us rarely interact with these people so it doesn't matter. They're just the newest placeholder name in the emails I get every few months as they're shuffled around.

From what I understand, Elon Musk previously spent his time on the line in Tesla.

They dont need to spend all day writing code, they need to spend their nights and weekends making sure their skills dont rust.

How about, a proportion of their work day must be allocated to keeping up to date with the tools behind the thing they're attempting to manage?

No. This would be a person who already happens to spend their nights and weekends coding. There are plenty of people who like building things, whether it’s woodworking or software.

> How about, a proportion of their work day must be allocated to keeping up to date with the tools behind the thing they're attempting to manage?

Maybe, but it would need to be solving a real problem the team has, not just leetcode or some random thing. Part of sharpening the saw is the struggle, and subsequent overcoming, which requires solving a real problem.

But you also don’t want a manager owning a critical path project as the developer. Part of a manager’s effectiveness is being available. That doesn’t work in crunch time when a project needs head down coding all week to meet a deadline.

But if a manager is building a trading bot or chess engine on their own time, they will encounter all kinds of real world challenges.

Why is that a waste? I'm an EM and code both at work and on nights/weekends. During the work day, I spend most of my time helping other people directly (code review, talking through designs, 1:1s, xfn collab, etc.) To build larger things, I do them nights and weekends.

It's not a waste. I'm better as an EM because of it. And being a better EM gets me more of what I want (fixing healthcare).

Not everyone can do this—and at some point in my life maybe I can't either—but it absolutely makes me better at my job. I don't consider that a waste.

[0] https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...

[1] https://charity.wtf/2019/01/04/engineering-management-the-pe...

Like a 10X (cost) intern?

Are you making the assumption he, as an EM that codes, has the coding skills of an intern?

Please take care of your health. Humans need sleep, Even when you think you don't. Try to get enough sleep. Try to have at least some time during the day where you don't have any mental stress.

I have these videos that keep showing on my Instagram suggested reels that remind me that in a hundred or two after I am dead, literally nobody will have any clue I even existed. If hard work makes you happy, that's good. Keep working hard. However, definitely make time for sleep.

Controversial opinion: you shouldn't need drugs (caffeine) to help you wake up.

Anyway, people told me that and I scoffed as well, so it's useless to type this, it's the type of thing you adapt after going through it.

This is actually another argument against coding as a manager. There’s value in staying connected to the craft, and being able to navigate the code base and answer specific questions with facts has a good amount of value. However in a large technical organization with distributed system the hard problems are always people problems, and hence if you want to grow as a manager you need to orient primarily in that direction. It’s okay to spend some time “staying sharp”, but it can be career limiting if you don’t recognize the higher level problems that only a manager can solve.

If the parent leans on the hard earned skills to make better decisions that improves outcomes for their team and by extension the org, then it's entirely possible it makes them a better manager.

Where it gets complicated is questions non-related to this:

- Who and how is anyone measuring outcomes? This is often very difficult in abstract.

- Is the org actually setup to allow these teams to flourish? Will the measurement be fair, or is there effectively internal sabotage?

- What's the reward for being better? Would the parents life actually be materially better for making the effort?

Personally, I agree with the parent. On average, having good ICs making your IC decisions lead to better outcomes. Where there's grey areas is there's more than 1 way to structure this. Player managers are definitely valid. Better than non-technical managers with good soft skills making poor engineering decisions over and over.

Where I'd disagree is the continuous effort. Once you've reached a certain level, a lot of what happens below syntax. Occasionally you end up managing something you don't understand with contention in the team.

At this point, you either invest or defer. The problem with the latter, in my experience, is very few devs have experience with commercials, so most of the arguments are based on laziness, interests, or purism, rather than outcomes.

For the record, whilst there's managers we like working for, if they're not able to extract reward for business outcome for the few that chase that, are they actually any good?

Life is more than work

A better word might to 'appreciate' what you do. I'm mostly a manager/leader/vision person now and occasionally still code. Even though I've written a lot of code over the years, there's no way I could just drop in on a complicated project and understand all the intricacies without some ramp up right now. And that's ok. I appreciate the challenges everyone (engineering, customer support, operations, etc...) I manage faces and trust the people who do that work.

There is only so much time in the day, and if I'm tinkering with Node versions I'm not doing the work I need to get done.

The way I see it is that for a healthy office, you need to have peers who appreciate each other in a vocal way so that the managers/leads can hear it. Cause not everyone sees what you see. You notice someone is really good with something? See someone keeping up with the literature? Find a way to bring it up in group setting. It's not a given that everyone notices what you notice.

The thing about appreciation is that you can't just say it about yourselves. It always need someone else. You cannot say things about yourself other than your outputs cause it'd only look petty. Only when someone else says it, it's considered. Of course, be proper with it.

All I'm saying is appreciation is a shared responsibility. And if you do it right you might also become someone's favorite person.

Someone can understand what you do without being able to do it.

It requires honest appraisals of your own skills and weaknesses, which is tough. But when I give an estimate on programming projects, we hit my targets on time, on budget, because I know how to write a spec, how to manage a dev team, how to QA, and how to keep development running productively. I can code a little, but I'd be the worst coder on my team, but that's not how my time is best spent.

Language barrier can be quite high between JS, COBOL, and Haskell depending on what the situation is. With 25 years of experience, how have you not found the time to learn basically every language used in industry today?

Of course not, unless you were also an expert on making Tiktok content for the same audience and could definitively say what should and shouldn’t work.

Where folks get objectionable (myself included) is when those same managers conflate superior rank with superior knowledge. It's the CIO demanding we use a specific product suite without objective justification, or the SVP forcing a given architecture because it suits their political objectives rather than organizational ones. That's presently on the rise as tech companies (in particular) bring in "outside talent" (aka, the same failed-upwards managers and leaders of unrelated enterprises in their social circles) instead of promoting from within or hiring qualified candidates, and it results in a whole host of grievances and problems that can rot the org from the inside out.

The clue is the rise of these sorts of posts, trying to coach us on how to step into leadership roles and transition from Individual Contributors to People or Product Managers instead. The takeaway I got was less "managers shouldn't code", and more "managers should not assume their code is better or necessary just because they're managers"; in other words, to strike a balance.

And if they have no clue what the job is about they will inevitably appreciate/promote/give raises to people who talk the most random jargon in meetings rather than to people who actually work.

I don’t learn plumbing in order to hire a plumber.

Most top level legendary CEOs, could. Zuckerberg, Gates, Jack Welch, Edison, Larry Page, Sergey Brin all worked their way up from the floor to the corner office.

>>At certain points things need to be let go of if you want to keep growing.

This is how you arrive at the situation Boeing is currently. Im sorry but not all businesses have a cookie cut text book way of running things. In fact running any business worth its salt will require you to know the skills at the floor level in a very deep sense.

Sure but the tech CEOs success is an anomaly : most if not all the people you cited were able to get to the top because the context was highly exceptional (because personal computing and internet were a total greenfield).

(Also not to mention that, beyond those exceptional circumstances, most of them were already coming from pretty rich families)

Most companies in the world are not ran like this.

But even in that case you still have to be darn good at distribution, financials, marketing etc.

You can't exactly dictate things cluelessly at a abstract level like managers in software do.

But whoever the head of AWS is should definitely have a grasp of fundamentals.

All this involves understanding the product in a very deep way, and a good deal of technical details as well. Else your staff will play you like a violin.

Absolute hands off abstract management by words won't cut it anywhere.

> He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And then wandered off telling me he could definitely do the work if he wanted to.

Frankly, all this anecdote tells me is "don't behave like a condescending asshole". If he'd said the same thing but then managed to do some non-trivial aspect of your job for a few minutes, I think that would still have been a bad tactic. It's just as possible to have humility about skills you lack, and to lack humility about skills you've maintained.

The server stacks were well above his height.

He probably could have, in his day, wired up 20 odd desktops, got them going, and maybe shave 10 minutes off my batch time.

But he really had nfi with the servers, the stacks were 2ft higher than him already, they all had dual power supplies, lots of idrac ports. He absolutely would have shamed himself if he kept going. And the reason he hired me was the ability to reason and read vendor documentation.

They also take ages to boot compared to a desktop.

So yes I think ALSO dont behave like a condescending asshole, but if he understood what I was doing he wouldnt have needed to leave his office and make a fool of himself anyway.

Managers are responsible for maximizing what people they work with can achieve. This does not require them to be able to do what their team can do.

> I dont think a manager of software engineers needs to code the application he manages, but he should be continually coding something to remain sharp.

A counter to this is; a manager of software engineers needs to remove roadblocks impeding the success of the team.

Good managers enable their coworkers, micromanagers weigh in on or perform commits.

How do you performance manage employees if you dont understand what they do.

Roadblocks are almost exclusively a "people problem" - politics, identifying stakeholder needs, inter-team coordination, etc.

> How do you performance manage employees if you dont understand what they do.

By working to identify value added to the organization via quantifiable metrics and working with team members to define professional growth tasks relevant to both the person and the organization.

None of the above requires a manager to know how to do what the people hired can do.

>>I dont think a manager of software engineers needs to code the application he manages, but he should be continually coding something to remain sharp.

I'd even go to the extreme of saying the coding skills/brains fade by inverse cube law. Skill =~ 1/t^3 (t = time since last practiced the skill). Musicians are known to say something along similar lines, like as little as a day of missed practice and they can feel it.

I used to be quite good at calculus as a teenager, and today I could look at the easiest problems there are and go blank. Only a faint echo of those days remains.

I have long suspected that Doctors suffer similar decline in ability as years go by from Medical school, and you can be sure in as little 2 - 5 years, most managers would struggle to imagine what writing code could look like.

Managers of engineers should be the interface to the business and other units within the organization. That's a big enough job without requiring coding skills on top of it.

An engineering manager actually reads the output of the engineers and participates in having it applied to realise bigger projects. He makes higher level decisions about the engineering projects.

In terms of evaluating job performance, you've got peer reviews, deadlines met, contributions in meetings and so forth.

In other words, a manager should have their time filled with other things. Unless the team is really tiny (too many managers), there's plenty for the manager to be doing- planning with product / sales / design teams alone should be enough to keep them busy.

However, his story goes, one day he was asked to design a telephony solution for a tech support call centre.

He fell in love with the call centre. He very quickly gained a deep understanding of what they were trying to achieve with the telephony solution and pulled a bunch of critical data out into a dashboard for them after learning how they operated.

He asked for a job and they gave him one. He was an effective manager because he had a deep understanding of the role of the 200 staff he managed, and was able to effectively spot issues with staff based on their metrics.

He could have done my job, but understanding it gave him the exceptional ability to add value to 200 staff at once. Neither of us was redundant.

Then you will never work for any human being. None of them will know what you do as well as you, unless they're doing it with you, and if that's the case, they're not really someone you work for.

Bosses become bosses because they want to stop doing the work. They want more money, and more respect, and they want to make decisions without needing to clean up their bad decisions. Bosses become bosses because they don't want to do what they've been doing.

There is no such thing as an engineer who does real work who is paid as much as a manager. They just don't exist in any company I have ever worked for. All managers of any pay grade automatically make more than any engineer of any pay grade, which creates a ceiling for engineers. Bosses become bosses because people are penalized for remaining engineers.

Management simply does not care about the experience and knowledge gained by engineers, and they value it less than a manager who is fresh out of college and who has zero experience with anything.

No, bosses should not code; they chose their path. Fuck 'em.

Why would you put a limit on your own progress like that?

I do agree that it's important for a coder to keep coding but mostly for the manager itself as it's removes some of the old biases and it's a continuous learning process on something that, technically speaking, they should be passionate about. Plus it does help to have conversations with other developers and don't sound like a person who only listens to vivaldi at a dnb concert.