> uncover blockers that people haven’t surfaced on their own

I constantly reiterate to people, whether they're reporting to me or not, that they need to speak up when there's a blocker. I feel its a very telling skill of engineers whether or not they can communicate issues in an effective manner urgently and figure out the best course of action to unblock.

I've heard tales of 300k/yr engineers that just sit there and wait for a manager to ask if they're blocked, or just sit there until they're told what to do.

> But I do need 1:1s to check on progress, uncover blockers that people haven’t surfaced on their own.

That's why historically having managers being strong IC contributors remove that need because they already KNOW the progress and issues on the field.

Modern BigTech created that artificial layer of managers that need to know about all the blockers and progress, just to report it to another layer of managers. That layer is so big that they need 8 hours of meetings to sync with each other. This is purely an organizational issue.

I'm saying a lot of the managerial work is busywork that got pushed as a need by BigTech need to empire building.

all your "progress updates" are in Jira and Git. Go and check. Ask questions if needed.

It is possible to move most of that discussion to required but intentional async communication.

They're not completely different fields. Staff engineer and above is unobtainable without some of the leadership skills a manager needs. There's a lot of soft skill overlap between high impact ICs and management.

I like to think of it as a manager isn't required to have technical expertise, it can help, I can hurt, but they have to be a leader. Junior and mid career are required to have technical expertise, but not required to have leadership, though it would certainly help them be high impact and thought leaders in their space.

The more senior I get, the more like a manager I am. Less hands on, more coaching, guiding, teaching and setting direction. Meetings and docs become my tools less than code. When I'm writing code I'm only increasing the output of one person, me. Everything else is force multiplication. I just don't have to do the bullshit performance management.

The best manager role I ever worked with wasn't incredibly technical, although he was loosely working on getting some IT certifications at the time. He wasn't even the person I really reported to, he was just a project manager that was really on the ball. I knew if I needed something, I could go ask him real quick and he'd make it happen. If I didn't have the full specs, he'd go chase down the other teams and get them sorted leaving me to stay busy with the technical work. I knew if he threw a meeting my way we'd have a good agenda with real issues to work through, and I knew I'd get minutes sent out after the meeting to keep track of what was decided.

I haven't had many excellent experiences with project managers, but dang was he good at keeping me unblocked.

I wonder how the best manager was not qualified to understand what his team is doing, if they do it right or not and was also not able to help them in case there was a technical challenge. This is not how successful companies operated when they became successful, before getting bloated.

As one of those supposedly higher level ICs, I agree entirely with the assessment.

A decade or so ago, the high level ICs I interacted with were much more technical.

They were the kind who would perhaps not invent truly novel things--but plenty did in the right companies--but they had mastered their domains and genuinely solved thorny problems that others struggled with.

Nowadays, they are more political and less involved. I have met many that do not code or barely code. I've been in months of meetings to decide to do something fairly obvious just to ensure "alignment" even though no parties actually disagreed, just wanted to nitpick minor details that could just be a comment on a PR.

That was true for the old school hard tech companies (Hardware chips, Intel, IBM, etc)

Google and other adtechs are not hard tech, that's why they have so many managers)

An underappreciated reason for this is empire building: Someone needs to be promoted to Senior Director and one way to do this is to add a layer of management: Adding 5 headcounts that essentially do busywork makes it easier to advocate for why your org is very important and why you should be promoted.

A majority of the big corporations I've worked at this was the typical developer track.

- entry level dev

- senior dev (start being groomed for management)

- senior dev/leader (take on 25% management duties)

- manager - management track.

Once you're on a management track, you essentially are taken off of any dev work and then depending on how well you've networked determines how fast you move up the management chain. Some companies like Target, they groom and move anybody up relatively fast who they see any potential in.

The only exceptions I've seen in my career are either startups or medium sized companies where there is no management track. You're a developer from the day you're hired until you either get fired, laid off or leave the company.

When I was an entry level dev, I left three companies because they wanted to start grooming me to move up into management. I was way more into being a developer and writing code then managing people.

I was a technical team lead/line manager and I watched my team casually ask about what I did all day and then 10 minutes later call me up to spend an hour debugging their code for them. And then the next one called me up to work on theirs... :-)

On the other hand I've had managers just the same - cannot understand why anything is difficult and certainly wouldn't waste their time trying to help you.

It's just people, they're sympathetic or not. Determined or not. They care about the outcome for more than themselves or not.

Nobody is blaming the middle or frontline managers here. Those people are driven and genuinely want to do a good job

But what we are saying here is that they are essentially an artificial layer of busywork that adds very little value. This is what decades of empire building and organizational issues have created.

It's slowly changing and people are realizing a lot of the manager work is self-created and sustained.

My prediction is that most tech companies will go through flattening cycles now that we start realizing that adding managers adds a similar amount of busywork.

You're describing frontline management, not middle management. My 2 cents is that frontline management is the worst job in engineering, for the reasons you describe and more.

I was a manager of others who were also called "managers" (they were Project Managers and App Managers) and I was still writing code when needed. These days most managers in IT in my company are non-technical to the point they cannot write a single line of code in any language. Their managers are so non-technical they don't understand SDLC or anything related to what their people are supposed to do. Times changed, what is a manager today changed.

Exactly my experience as well.

I worked in several BigTech that had managers excellent at talking and posturing in meetings but doing no or negative works.

The issue is that managers are hired and judged by other managers, not IC, not producers. This creates that managerial class that make themselves self-important.

The confounding factor here is the size of the company. You are saying, more than "I like managers who contribute technically (whatever that means)", that you like working for small companies.

It's as if people are saying they want a direct democracy in which every issue is voted on directly by the participants, with just one layer between the people and the "prime minister." Good luck with that when the group size exceeds 50 people, and one realizes that people don't want to vote on every issue affecting a larger society or organization.

How old are you and how long have you worked in tech?

I have been employed before the 2000s and that was the norm before AdTech started to empire building around managers.

> Why would you wait until a weekly scheduled meeting to bring something up?

The dirty secret is that most employees in the software field are not capable of that level of maturity and forwardness.

I’ve had employees like that and our 1:1s switched to monthly cadence and were frequently skipped if they felt like there was nothing to talk about.

For the majority of the others they had some level of anxiety about discussing problems and needed the structure of a scheduled meeting to feel safe enough to bring up issues.

I see comments in this thread being dismissive about discussing feelings and I assume they would be terrible managers who couldn’t handle the first time they had a direct report break down in tears in front of them while struggling with some task and feeling worthless.

I make it a point to have 5-10 minute ad-hoc conversations with my directs 1-2 times a week, feels a lot more natural than a scheduled 1-on-1. Twice a year we have a company-sanctioned formal sit-down about perf.

As a result, people pop in my office regularly to start these conversations, which I prefer because it leads me to believe I am approachable, which is by far one of the most important things a manager should be.

I used to have many ad-hoc chats with my team every day so that 1-1 time was redundant and we just spent it debugging things or discussing some problem.

My own boss seemed to see the time as an opportunity to apply pressure so of course I utterly hated them and wanted them to end ASAP. I didn't want it to be like that for my team. I thought I should be a source of help.

You can both be right. It depends on company culture, which depends on the experience, maturity, and attitude of senior management.

The two extremes of company culture are status cultures and service cultures.

In a status culture the product is the internal status hierarchy. External products are largely incidental goals, and customers and markets are only valued to the extent they create metrics that can be exploited by status seekers. Likewise employees.

In a service culture the goal is customer service through high quality output and employee development.

US corps lean far more to status culture than service culture. This is excellent for short termism, but the culture often becomes dysfunctional, if not outright abusive, and sooner or later it implodes, because status cultures aren't good at accepting reality, or at accurately reading it when they do accept it.

And status cultures tend to cargo cult management, where the C-suite is comparing its status to other C-suites, and copying apparent status-raising actions without thinking them through.

In good times a status culture will overhire, because hiring more employees looks like growth. In bad times status cultures will overfire because "cutting the slack" is lowest common denominator status management.

AI is the same on steroids. You get the promise of more growth with fewer employees, and that's hard to resist, even though it's entirely speculative and could easily be catastrophic. (Company results, and especially lasting company results, are orthogonal to whether some employees get good results with AI, because what actually affects results is how predictable the improvements are, whether there are likely downsides, and whether they're structurally in the right places.)

Whether managers should also be ICs is a side issue.