Remix.run Logo
fallinditch a day ago

> Most managers are terrible.

A sweeping statement indeed, but it does reflect my experience too.

Perhaps it's my ingrained deference to authority - when I start a new position I tend to believe that my manager has my best interests at heart. This is a mistake and I now believe it's better to maintain a kind of defensive attitude and to always be assertive in establishing, and if necessary negotiating, the responsibilities and expectations of your role and your relationship with the manager.

This may not necessarily be a personal failing on their part, this may just be a consequence of the operational management system you both work within.

mjr00 a day ago | parent | next [-]

> A sweeping statement indeed, but it does reflect my experience too.

IMO - managers are terrible at the same rate as ICs. But the damage a terrible IC can do is limited in most companies because there's guardrails like automated testing, pull requests, no access to the production database, etc. At worst they end up being a big timesuck for other team members until they get let go.

A terrible manager will sink a project or team single-handedly, though.

noirbot a day ago | parent [-]

There is no code-review process for management decisions. Management is essentially like writing code on the production server all the time. The stakes are maybe a little lower, it's a good bit harder to make disastrous mistakes, but there's no real roll-back or testing for if you're about to ruin your team.

lifeisstillgood a day ago | parent [-]

But why isn’t there a code review process for management decisions?

What if code was how decisions were recorded ?

What if companies were programmable ?

noirbot 18 hours ago | parent | next [-]

The most obvious reason, in my mind, is that merely proposing a decision is enough to be a problem. Suggesting we're killing a project a dev has spent months on, or moving someone to another team, or saying we'll miss a major KPI, or not promoting someone aren't things you can have a public full-team review on. Just knowing the manager was considering it is enough to upset people.

If someone writes code that has an error in it, you maybe think a bit worse of them, but it's a learning opportunity and that's what the review is for. If your manager suggests a course of action that you deeply disagree with, that's hard for them to come back from.

lifeisstillgood 11 hours ago | parent [-]

But thats politics. Look at every railway, roadway, power station - always supported or opposed by various factions. We think it’s actually healthy for our society, so why is it bad on the scale of companies - some of whom have larger GDP than some countries

Having political discussions out in the open is - I hold as an axiom - a positive on balance.

This who are “upset” about things - well they are adults in a political society - they can understand the issues. Do they feel exposed / vulnerable ? Maybe there is a political solution to thinking you have two weeks notice and that’s all the protection

I think it’s worth having decisions openly debated - otherwise we are blessing an elite and frankly hoping they will get it right.

The survival rate of companies suggests they might not be

lifeisstillgood 4 hours ago | parent [-]

I would also suggest that politics is how FOSS works - the only reason Linus was the "CEO" of the kernel was because people voted him in by sending him patches. And kept sending them. There was nothing preventing someone else being voted in except the politics of it all...

I would suggest that the first step in a concrete plan (see below) is that every line manager becomes the place where the next line manager does a git pull from.

Eventually you want to release code, the actual CEO needs to git pull and sign off.

AnimalMuppet a day ago | parent | prev [-]

What if there were no hypothetical questions?

That is, you can ask hypothetical what ifs all you like, but unless you have a concrete plan for getting there, you're just writing fantasies.

And, management decisions get reviewed before implementation all the time. It's just not a code review, precisely because management decisions are not code.

Why aren't they code? Because people aren't computers. If you're going to treat them like they are computers, then I don't want to work in your company.

noirbot 18 hours ago | parent | next [-]

It's also that a lot of management "decisions" happen in the moment. Is how they phrase something in a meeting or a one on one. It's how they respond or ignore questions. It's how strongly the push for someone to be promoted.

They're decisions, but often not something you can have sitting for review for days ahead, even if it's only seen by senior management. I've had plenty of times management announced something I agreed with, but the way they explained it was so rancid I came out of it upset.

At the end of the day, management, and in general all human interactions, are a glimpse into who you are. It can go amazingly well, or disastrously poorly. You can try to be very careful and say what's needed, but tone and timing and phrasing will almost always give things away.

lifeisstillgood 10 hours ago | parent | prev [-]

Look with a historical lens - democracy in USA. From the point of view of say Chartists in 1776 it is a good start, 80 years till slave males can vote, 80 years till women can vote and another forty till civil rights. In 1776 can we call that a “concrete plan”?

Or is the fantasy “votes for all” actually a plan?

Yeah we can have plans - get Zuckerberg to give up power and place it in the hands of employees? Maybe convert Meta to a co-operative?

But on the literacy point - at some point we ran everything with illiterate “managers” - but slowly developed organisations that use literacy. My, yes ok fantasy, is not only democracy but that everyone inna company is software literate and has access to (maybe not write access) the code base of the company.

So there is a concrete plan - a whole org test rig, a company that every IRL action has a virtual shadow, a codebase that directs this IRL actions day-to-day and everyone having access to the codebase and able to suggest / comment or even vote on pull requests.

Run the company through code - change the company through democratic politics

ptero a day ago | parent | prev | next [-]

Just as a personal data point, most managers I had in my now 25-year career in tech were good.

They set clear goals and expectations, provided honest feedback, both positive and negative, and quickly jumped to help re-plan when things did not work out.

They were also asking what I am optimizing for (for me at different times it was more money; promotion; interesting problems to work on; time to explore other long-term products) and as far as I could tell worked with their managers to move me in that direction, sometimes successfully, sometimes not.

I did not assume any of my managers had my best interest in heart, but one of my first managers gave me some lessons on "how to manage your managers, myself included". It took a few iterations, but he convinced me that by far the #1 thing most managers want is for me to deliver things on time; not cut a few days off the project timeline. And if I learn to do that, they will advocate for my interests, shield me from corporate BS, etc.

Some specific advice from that manager was (in his words) "never promise something in 2 weeks unless you could demonstrate it today" and "do not sit quietly when you are given unrealistic timelines; counter with specific subtasks you see and how long you expect each will take". That general advice worked very well for me and helped build symbiosis with direct managers.

I did dislike a few managers, but those were generally good ICs stuck into a management role they did not like (or at least did not know how to do) and kept both sticking their fingers into what their team was doing and start timeline discussions with "it would take me one day to do this, I will give you two; go-build-this-now".

Again, just a personal data point; not claiming that most of the world works this way. I may have been just lucky.

yodsanklai a day ago | parent [-]

> Some specific advice from that manager was (in his words) "never promise something in 2 weeks unless you could demonstrate it today" and "do not sit quietly when you are given unrealistic timelines; counter with specific subtasks you see and how long you expect each will take".

Thanks these are good advice.

> most managers I had in my now 25-year career in tech were good.

I didn't have tons of managers, but my experience as well. Of course, they have their own interest in mind, rather than mine, but in my case at least, our interests were more or less aligned (completing projects, not burning out or leaving the team, working on things that matter to the company, avoid conflicts...).

kstrauser a day ago | parent | prev | next [-]

I think that’s largely due to the weird notion that engineers will eventually “upgrade” to management, as though one is the advanced version of the other.

There are whole degree programs dedicated to managing and organizing people, but we’re like, “nah, Joe’s a good programmer so we should talk him into stopping that so he can supervise people instead”.

Fact is, there’s little relation between the two. A person may happen to be good at both, but expertise in one does not imply adequacy in the other.

cocoto a day ago | parent [-]

Not every programmer can be a good manager, but no non-programmer can be a good manager on a programming project.

kstrauser a day ago | parent [-]

This is objectively and demonstrably untrue. I’ve had very good non-technical managers. Part of the requirement is them knowing they’re non-technical so they can stay out of the way and concentrate on the PM bits, rather than micro-managing.

andrewaylett a day ago | parent | prev | next [-]

We train people in their technical role, but we (generally) don't train people to manage -- and years of poor experience don't count.

I'm not a manager, and I don't want to be. But I'm quite happy with the manager training that my employer puts people through before giving them direct reports.

One should always be negotiating expectations, though, even when one considers management to have our best interests in mind. And also remember that your manager is learning how to manage from you. You get to shape their experience of being a manager, and you get (to an extent) to guide them in how they grow as a manager.

BurningFrog a day ago | parent | prev | next [-]

OTOH, this can be a case of the "if everyone around you is a jerk, the jerk is really you" rule.

If you can't work well with any manager the common denominator is you. It's also the only thing you can change.

noirbot a day ago | parent | next [-]

The difficulty is the small sample size. Most people won't have a ton of different managers in their career and you'll change over time and your role will change over time and want/need different things from your manager.

There's also a lot of selection bias. What many people point out in these threads is that the sort of people who desire to be in management, and the sort of skills selected for in managers often don't align to what more ICs would actually want out of their managers. Managers are often hired by other managers and not by the managed, so the skills that get you the job often aren't aligned to what would make them good to work for.

dbish a day ago | parent | prev [-]

This. I’ve known many an engineer who thinks their manager is bad because they don’t do what this IC (who has never been a manager or knows that is happening at the company above them) would do. The kind of people who think Elon is a bad CEO. Results are what matters first and foremost in tech

K0HAX a day ago | parent [-]

An employee not knowing what's happening at the company above them is a fault of the manager. There are some things that need to be kept secret, but if it's not one of those things, secrets are not a good thing.

dbish a day ago | parent [-]

It’s not that straight forward. It’s not the ICs job to know everything that is happening nor is it their job to make decisions based on pass through data, especially not a junior/mid career engineer.

Transparency and keeping people informed, yes. Sharing a bunch of info and letting every IC make their own strategy and prioritization decisions, no.

SoftTalker a day ago | parent | prev | next [-]

People rise to their level of incompetence[1]. This simple principle explains most managers completely.

[1] https://en.wikipedia.org/wiki/Peter_principle

tonyedgecombe a day ago | parent | prev | next [-]

My first manager was really good so it came as quite a shock when the next one turned out to be a lying, conniving bastard. Given enough experience you get hardened to it. Of course it would be better if you didn't need to.

cheema33 20 hours ago | parent | prev | next [-]

> it's better to maintain a kind of defensive attitude

As a manager/developer, I do sometimes see this attitude in some devs. I try very hard to help them find a different job where they are not working for me.

hobs a day ago | parent | prev [-]

As a person whose done it all, independent stuff, senior ic stuff, management stuff, the main thing that makes management terrible is simply that most companies have no support for middle managers.

You are a good IC? Sure let's promote you to management, but in 95% of cases, we're not even going to pair you with anyone or have a senior manager help you understand, build and grow - we're going to throw you in the deep end and have you sink or swim.

This often ends up with stressed out people used to doing well now approaching an entirely new problem with slow feedback loops and entirely different protocols than before, and the amount of burned out shitty middle managers I see is off the charts.