Hacker News Reader

Comment by protocolture | Hacker News Reader

I cant work for someone who doesn't understand what I do.

An unused sword rusts in its sheathe.

I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building"

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.

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.

TBH one of my current clients produces hardware and software, medium to large enterprise with close to 200 staff. Their CEO can operate all their products, operate the machines that place chips on the circuit boards, operate the injection moulding machines, write SQL queries to pull data out of their CRM and write code. He tries his best not to do it, but he maintains the skills. That's the goal I reckon. Someone who understands the job all the way to the top.

View on HN

> I cant work for someone who doesn't understand what I do.

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?

Specifics sure. I dont expect them to understand the specifics. I dont want them across every task.

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

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

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.

Waste from their perspective. And TBH I would rather be doing technical work than reexplaining technical work.

>If your boss has a reasonably-sized team but is spending their day writing code

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

> they need to spend their nights and weekends making sure their skills dont rust.

Life is more than work

Yeah, theres also personal and professional development.

There's also maybe being an involved parent. Or a caretaker.

Thank you

So you want them to come to work and do their job, then go home and waste their nights and weekends doing a variation of your job?

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?

> waste their nights and weekends doing a variation of your job

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.

How are you a better EM because you code nights / weekends? Genuinely curious, as I have to choose managing or continuing as an engineer pretty soon

Code review, respect from engineers, directly feeling the pain points in our development process, I can commit small features strategically (like if a partner team isn't getting a lot of love but we're under-resourced), better partner pairing with engineers, balancing tech debt with new features, shipping directly to users builds empathy

>I can commit small features strategically (like if a partner team isn't getting a lot of love but we're under-resourced)

Like a 10X (cost) intern?

Not sure if I read this wrong.

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

Skill is irrelevant: the output is a small, low-priority feature.

Here’s some good food for thought on the engineer/manager decision, [0] and [1]. Good luck!

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

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

You just don't know how to manage your time yet. This is every manager's first few months. The totality of your work should be done at work, or you're actually pretty bad at your job, efficiency wise at least. You'll tell yourself you're doing more than others, but eh.

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.

We actually can't judge this without really looking at outcomes.

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?

I tend to agree with your assessment of this post, however as you rise up as a manager and possibly executive, one of the most highly valued behaviors is responsiveness. Knowing things and responding quickly, even after hours, can grease a lot of wheels in a large org.

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.

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

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.

For a lot of people, their job isn't 100% of their life and their weekends are reserved for... Life. I respect you though. I'm glad your job is something you enjoy to the extent you happily regularly extend it into your personal time.

> So you want them to come to work and do their job, then go home and waste their nights and weekends doing a variation of your job?

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.

If you get what you want you'll have a shitty Pull Request for you to review on Monday mornings with your eager boss waiting for your approval on the PR.

However the professional development is achieved is fine, as long as it is achieved. But most people I know do it outside of business hours.

Counterpoint: I don't want a boss who is so detached from the rest of life & society that they have copious free time on nights and weekends to practice coding.

Do you read books about management in your evenings?

No but I do take time in my afternoons to learn new skills.

For the sake of argument, a company could be structured such that your boss knows what you do and their boss knows what they do but not necessarily what you do.

There are a lot of jobs where the bosses bosses boss does know the job as that’s where they started.

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.

> jobs where the bosses bosses boss does know the job

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)

Hypothetically, those jobs could all be very similar if your company did more or less one thing lots, like managing a whole bunch of plumbing contractor teams.

This is pretty far from the original example though.

If you promote up, and you have 3 levels, then the CEO should have done the exact job of 3 people below him on his ascent.

Hard disagree. Would it be helpful? Sure. But a good boss just needs to know when to trust the judgement and opinions of his subordinates.

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

He didn't say your bosses boss is not allowed to know what you do, but that they _not necessarily_ know what you do. It's like abstractions: they can be leaky, but you'd better still know who's responsible for what.

While we're on the topic of abstractions, the summary of Bertrand Russell comes to mind:

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

> you already do

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.

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

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

> I cant work for someone who doesn't understand what I do.

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.

'Appreciating' is a very hard thing to do. I think it's an impossible task for one man. Not only do you oversee many people, but there are so many dimensions you can appreciate in someone.

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.

> I cant work for someone who doesn't understand what I do.

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

This really calls into question your meaning of the word "understand."

This really calls into question your understanding of the difference between the words "what" and "how". I know and understand what a marketing intern does, but I don't know how to specifically record a TikTok that will appeal to Gen Z with an IQ below 115. And I don't care, because I can measure the performance and fire or hire the intern.

Can you measure the performance and accurately separate it from things like how well Tiktok as a platform is doing, the general economy, and public sentiment about your company?

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.

It's like a pianist thinking that his doctor can't operate on his hand because he can't read music.

I have 25+ years of dev experience, and currently work as an engineering manager for teams who write code in a language I've never used (but in a domain I understand well). What do you think I'm missing?

You haven’t provided enough information to say for sure. If all your reports are happy, then probably nothing, but that’s a big “if.”

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?

True, but not in the way I think you might be inferring. A construction planning/quoting engineer can give incredibly well detailed and highly accurate plans and timelines for building a building, road, bridge, etc. They don't know how to make the steel, or how to weld properly, or how to mix the concrete, or how to measure slump, or a thousand other tasks the construction workers know by heart. I don't need to know exactly how my developer does XYZ, but I can have a strong enough understanding to know if it's the right approach, how long it will take, what problems to expect, how to work around them, etc. I have an on-staff developer who is brilliant, and even though I don't know SQL very well, nor the language our EMR is written in, he comes to me sometimes for technical advice because I understand what is happening internally, and even come up with ideas on how to solve problems without being able to implement the fix myself.

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.

I guess I don't get what's objectionable about working for someone who doesn't understand how you do what you do. Isn't what matters being appreciated? I certainly can't work for someone who doesn't value what I do, but I can care less whether they actually understand how I do it.

I guess it depends on the perspective, and the attitudes of those above you towards your work. If people and product managers are showing deference to your team's expertise in this knowledge domain (whatever it may be), then that's good, and I don't think anyone here is going to complain about that working relationship.

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.

> Isn't what matters being appreciated?

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.

A lot of the reason you hire someone is specifically because you don’t understand the skill required to do a thing.

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

I don’t know man. Can Bezos code? Can he operate a forklift? Would he still even recognize Powerpoint if you opened it for him? At certain points things need to be let go of if you want to keep growing. Some managers might keep technical skills sharp, but I’m not sure they’re much better managers for it.

Groups of companies, like Amazon, dont really make sense to me in abstract so I cant really comment.

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

I'm pretty sure the CEO of AWS can't do any engineering work anywhere in AWS. He's an MBA and an Industrial Engineer (whatever that is). He used to be a product manager.

You still need to understand what you are selling, like in a very deep sense. Even if not at the technical levels, you need to understand how the financials of it all works, how to take product and sales roadmap forward. How to hire, fire, how to spend and on what to spend.

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.

And industrial engineer is basically an MBA but called "engineer" for no reason whatsoever.

On the flip side - I find it very understandable that one might not want to have ever worked at Amazon even in its early days and instead would prefer to work (or have worked) at a much smaller, engineering focused organization.

>>I don’t know man. Can Bezos code? Can he operate a forklift?

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.

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

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.

I mean if you are selling detergent, paint or soap its a different argument there.

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.

> I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building"

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

Normally I would have 12 or so desktops there.

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.

> I cant work for someone who doesn't understand what I do.

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 know what roadblocks are valid to remove if you dont understand what they do.

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

> How do you know what roadblocks are valid to remove 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.

"Hey we need money for tools for reasons" Is a pretty common roadblock.

>>An unused sword rusts in its sheathe.

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

If your boss can do your job, one of you is redundant.

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.

If your boss can do your job, he can understand what you're doing and correctly determine how you perform. One of you is only redundant if the manager doesn't have his time filled with other things.

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.

You don't really want your senior and staff engineers bogged down with career management, hr disciplinary implementation, team salary budgeting, and all the miscellaneous other duties of a manager. You want them thinking deeply about the code, the business problems, and how the two meet.

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.

I think that's the crux though, for some reason companies think that a team of 3-5 engineers needs a full time people manager. Unless you are dealing with all juniors or a bunch of primadonnas I don't see how every team needs their own people manager.

Hence, my original point. Some of these people are, in fact, redundant within the org.

Uh no? There is another limiting factor which is time. And there's is yet another which is having a substitute in case you're sick or whatever.

Time is solved by having other engineers.

I used to work for this guy. He was a network engineer by trade, and I understand a very good one.

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.

> I can't work for someone who doesn't understand what I do.

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.

I cant work for someone who doesn't understand what I do.

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

What do you mean? Figuring this out has been the best thing for my career. Jettisoning jobs where I spend all my time managing upwards is career building.

If one was a coder once, they don't need to keep coding to understand what a coder does. Plus it's a bit hard to be a manager of different profiles and different stacks and understand what everyone does from a coding point of view (different stack, different frameworks and abstractions etc) especially while time passes and tech changes so much, so quickly.

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.

Reply on news.ycombinator.com