> Leaders will own much more, with as many as 15+ direct reports. [...] Every leader at Coinbase must also be a strong and active individual contributor. Managers should be like player-coaches, getting their hands dirty alongside their teams.
Oof. So not only are they giving their remaining managers more reports, but those managers will be expected to do lots of other, non-management work.
Sure, nothing can go wrong there... Even if they didn't have non-managerial work to do, 15+ direct reports is just too many. They're not going to get to spend enough time meeting each report's needs, not a chance.
I think as layoffs emails go, it's a pretty good one (as the current top comment points out[0]), but boy, I would not want to be working at a company like what Coinbase is turning into. Non-technical teams shipping code to prod? No thanks. "AI-native pods"? No thanks. I do like the idea of one-person teams; I was at my most productive when I was in that kind of role (though I'm not sure my experience generalizes). I get that companies are still struggling to figure out how to adapt to LLMs, but... damn.
Pretty solid severance package for the folks being laid off, though.
Or maybe we should go back to what it was before Google and big $$$ tech decided that if you were a "manager" you shouldn't contribute technically.
Being a manager now means a bunch of busy work talking to other managers and weekly 1:1s. There is a ton that has been written about the managerial class. Producing nothing, but for sure making themselves look self-important.
Before that the manager was essentially the best engineer in the team (or the one that wanted to get promoted). Being a manger meant you were respected directly for your skills and you were expected to still be a full time contributor. Directors meant you were one of the best ICs out there.
Now, being a manager or a director means you sometimes did an MBA in an unrelated field. This brought a ton of politics, nonsense meetings (because the most visible output for managers is more meetings where they can posture).
Let's go back to what it used to be. We don't need weekly 1:1s to check on feelings. We don't need a full layer of managers syncing with each others and taking political decisions that will mainly advance them. We don't need another layer of gatekeepers.
I'm not saying all managers are bad, but this charade has been pushed a bit too far.
As a manager that does weekly 1:1s, I agree with that statement. But I do need 1:1s to check on progress, uncover blockers that people haven’t surfaced on their own, make continuous small decisions, offer support, assess performance, collect status information for my manager, and last but not least give employees the opportunity to share feelings frequently. They do, and it’s not very often, but it’s important to have a dedicated place for it otherwise devs often don’t share until damage is being done.
I’ve also watched devs who didn’t have weekly check-ins go pretty far off the rails. One dev I remember would go off by himself for weeks designing clever code and over-engineering things that weren’t needed. I thought to myself that someone should be checking in with him, and then months later I got stuck doing overtime before a delivery deadline with dozens of other devs on a weekend chasing an intermittent release-only runtime crash that turns out he caused by trying to get tricky with copy constructors. A quick 1:1 could have prevented this bug that ended up costing tens or hundreds of thousands before it ever happened.
BTW, the best managers I’ve ever had were technical contributors, and they tended to be more relaxed about check-ins than the non-technical managers, in part because they had a better sense of where things sat. Personally I also feel like a better manager when I’m contributing technically to a project, and devs seem to respect that more.
> 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.
> 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.
This is widely presumed to reflect reality within a 1-2 degrees of separation from myself as well as from many of the people I speak to. Part of the problem is that there is always plausible deniability. Like the adage of how unwise it is to fire custodians just because you never see a mess and therefore you never actually see the custodians do anything, it may be "unwise" to lose the presence of these 300k/yr engineers just because they somehow actually keep things going smoothly.
> I constantly reiterate to people, whether they're reporting to me or not, that they need to speak up when there's a blocker.
This is presuming a particular/healthy culture where open communication is valued, appreciated, and not punished. This is not always the case, and an "objective description of a blocker" could result in some bruised egos where it transforms into blame upon some person or team for being or causing the blocker. People who experienced these cultures may be waiting for private conversations (such as 1-on-1s) that minimizes the risk, and they may be waiting to identify you (or whomever they are talking to) as a person who could make communicate the nature of the blockage in a politically favorable or neutral manner. All of this may be happening without the people involved consciously aware of this behavior of pushing out information through private conversations. And this maintains plausible deniability for ALL parties. The person who is blocked is never identified. The person who may have been the blocker is never identified. And hopefully everything gets fixed before anything is actually worth escalating.
> Like the adage of how unwise it is to fire custodians just because you never see a mess and therefore you never actually see the custodians do anything, it may be "unwise" to lose the presence of these 300k/yr engineers just because they somehow actually keep things going smoothly.
so you should keep people on pay-roll because they "might actually be doing something if you look hard enough" ...? don't think so
> People who experienced these cultures may be waiting for private conversations
the error is the "waiting" - if you have a problem it is your responsibility to do something about it
> so you should keep people on pay-roll because they "might actually be doing something if you look hard enough" ...? don't think so
The point was that you might be making incorrect assumptions that they aren’t doing work, and you might be making incorrect assumptions that replacing them will cost less. Looking busy and knowing what to do are two different things.
> 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 could be this person that appears not communicate, but the reason is because I've never had a manager that could unblock me faster than if I didn't tell anyone and just did it myself. For the longest time, every manager I've ever had was mostly useless (for unblocking some issue), it took quite a few years before I got an EM that actually makes shit happen. Only then did it become a habit I had to break.
It doesn't make sense to tell someone who can't or won't help you that you're blocked on something. Eventually you just default to never asking.
Read other comments: Even engineers with 10+ years of experience don't know how to do this, think they have it all under control, then complain that management only hindered them. And if we are talking from experience, based on mine, only 2/10 good engineers actually know how to communicate results besides just delivering code/artifacts.
In some particular cases and SMALL groups I do think a Manager by itself is unnecessary, especially if everything is working out and they are responsible enough to present usable information to others in the hierarchy, but if not, please stop this fighting and only complain when the Manager is really annoying.
If you think they are robbing you of valuable time, time it. Time it and tell them with hard data you're being robbed of at least a certain % of your working time, which means you can probably deliver less if they want X action from you.
Yes exactly! Devs resist asking for help when they need it, and this is why as a manager I have to insist on asking questions to discover blockers.
I can see why this happens, and I was (and still sometimes I am) guilty of thinking as long as I have a little more time, I can solve the problem myself. We are all capable of figuring out how things work, we all want to learn, and we all have fears that admitting spending time spinning our wheels might reflect poorly or reveal weaknesses, and/or might be used against us in reviews.
Part of making people feel comfortable surfacing blockers is making sure the environment is supporting that behavior. Devs need to be rewarded for working together, and rewarded for being proactive about telling their manager or the team they need help on something. If these highly paid engineers have had negative experiences in the past, they might have learned not to bring otherwise important issues to light. Occasionally there are also people who learn what they can get away with and will optimize for the minimum.
IMO, the environment also needs to allow devs some space to go slow for a while, solve unfamiliar problems, and learn new things - so for me there’s a certain amount of being okay with blockers, when people are still being proactive. I’d rather talk about them than not and make a conscious decision, but I do try to be sensitive to what I label as blocker.
> 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.
I’m not sure this framing is accurate. Companies have always had management. All large organizations have layered management; the Catholic Church has had layered management for two thousand years; your government has layered management; all militaries have layered management; Bell Telephone and Standard Oil had layered management for a hundred years before computers in business were a thing. This is purely a function of large groups, because communication is necessary to function, and giving FAANG companies credit for it overstates their influence.
Calling it a feature of empire building might be somewhat accurate in the sense that yes all companies and most groups aim to make money, or otherwise grow and succeed. Still, that seems like a pessimistic way to put it. Even small companies and church groups and libraries and PTA associations will have presidents & treasurers. Middle managers appear as soon as group size hits a certain limit.
I think what we are arguing is that yes management layers always existed.
But the state right now is that:
- those management layers are now more disconnected than ever from the actual work. Most managers are career managers that have given up on any actual technical work. Even if they used to be technical ICs, most bigtech actively discourage managers to do anything remotely technical. I still cannot understand this.
- There are way more managers per IC than there ever was (Last big tech I was in, my org had ~5 ICs per manager. I couldn't believe it and have no idea what those people actually did the whole day besides meeting each other!). This is directly because Directors decide to hire Managers and have a direct incentive to grow the amount of layers and amount of people in their pyramid. Even if they don't mean to, directors and VPs are managers as well and as such they have a direct belief and incentive that more management is better.
No, I think this still this isn’t an accurate framing of history. Managers have always had a completely different job than the people they manage. If anything, having a lot of managers that are in the trenches, writing code for example, is the newer trend. Since the Industrial Revolution, managers typically oversaw work but did not do the labor. You could ask some managers what they do all day, but once you get some management experience, you will start to understand what managers do all day and how there’s enough to do that getting technical work done is relatively difficult, and might compromise their ability to manage well.
Here are some pointers to the evolution of management over time that you might find interesting or enlightening:
The typical ratio of managers to laborers has definitely increased over time. 1:5 is higher than average, but 1:10 is very common for knowledge work. There are many reasons why this is, team building incentives are only one of many. But one question you should ask yourself is why you even care. Companies are free to function any way they want to, and they pay you to contribute to their choice of structure. Given that all modern large companies function this way, and also make money, maybe it’s worth starting from the assumption that it evolved this way for a reason? See Chesterton’s Fence.
>> Since the Industrial Revolution, managers typically oversaw work but did not do the labor. You could ask some managers what they do all day, but once you get some management experience, you will start to understand what managers do all day and how there’s enough to do that getting technical work done is relatively difficult, and might compromise their ability to manage well.
Oh believe me. I have managed a lot over my career. Sometime as a TLM and a couple times as a full time manager. I was still as technical and did as much as most people on my team though, which is against what most bigTech companies would consider acceptable for a manager.
All my opinions come from everything I saw and lived during my time as a manager.
I will repeat it again: I'm sure you are not slacking as a manager, most managers I worked with did not slack either. It is simply an artificial function with self-fulfilled busywork. The reason it still exists today is that the managerial class holds the power in most companies and self-hire each other as a way to keep themselves relevant.
A ton has been written about this, so I will put some links:
"Yet for all its dysfunction, the professional-managerial system proved remarkably durable. It persisted because it solved a different problem than organizational effectiveness: it provided a way to allocate status and opportunity that appeared meritocratic while actually favoring those who could navigate institutional prestige hierarchies."
Ah, I do sincerely apologize for making assumptions!
Discussions of history aside - I don’t think your opinion of management, as summarized as an “artificial function with self-fulfilled busywork” is entirely wrong so much as perhaps jaded, pessimistic, or a bit biased. There is a seed of truth there, and you’re right that this has been written about before, and it’s not a new opinion. But it’s also negative and incomplete, it intentionally ignores evidence, and it lacks explanatory power.
If management is useless and self-fulfilling and absorbing money, then why in a competitive capitalist environment can you not find large companies anywhere in the world without it? Or in any economic system that exists, for that matter? Surely if true, then someone else with your opinion can start a company and it would be wildly successful compared to the economic drag of the artificial and self-fulfilling professional managerial class. Why haven’t you started such a company? Why hasn’t anyone else? This is an important question to answer if you want to insist that management doesn’t serve a necessary and functional purpose; “remarkably durable” is a funny expression to use for something that has always existed, by design, from the start, and for which there are practically no counter-examples.
There are a very small handful of companies that claim little to no management roles, except that they still talk about managing and self-organizing and letting people define their roles, so managers emerge. They might claim no management and then still let the good talkers do the prioritizing and organizing and reporting and delegating, just like everywhere else. It might be the same as advertising unlimited vacation; the label sounds amazing while the reality is no different. It looks like the majority of such companies are software companies and have less than 1k employees (which suggests tech companies may be pushing more on reducing management than other sectors). When I searched, Gore came up as one example of a company with more than 10k employees that doesn’t use traditional management, and yet when I go look at their job postings, the very first page has roles like “president” and “manager” and “team leader”.
I’m not making any claims about “most”. TBH, I would actually agree with you, I assume. Most management is pretty bad, and many people are self-serving. Same goes for programmers, let’s not forget; many programmers are just as lazy and self-serving as the bad managers you’ve seen. Sturgeon’s Law is alive and well.
The PMC article kinda nails it - the term and the idea is a spin on Marx, and Marx wasn’t complaining that management is useless, he was just complaining that management kept all the ownership & profits.
I do check, of course. As you can see from the comment you replied to, progress updates aren’t the only reason for 1:1s. But as far as updates go, questions are almost always needed, and face-to-face conversations are faster & easier for both parties, which is why we do a little bit of it each week. We cancel 1:1s when they’re not needed, and cut them short when we’re out of topics.
Why do you assume not talking by default is better? Have you considered the downsides of your instinct to save yourself a few minutes a week? One thing a lot of devs don’t seem to realize when they push back on communication is the opportunities they’re missing to affect change in the group, to convince the managers to invest in things they need or want to work on in the future, to make changes to team communication practices, and to brag about what they’ve done, how hard they’ve worked, and what they really care about.
I will again say that most 1:1s are BigTech cargocult rituals where you talk about your path to the "next level" or "how are you feeling this week" but it's also a lot of project management and busywork that mainly exists because the manager is in the picture. Without so many managers most of those self-sustained meetings would go away.
What I’m describing is my 1:1s. I’m describing my experience, from a management perspective. You’re describing your experience from a non-management perspective, and I’m not arguing with your experience, but your claims about other people’s experience, speculation about how many, and assumptions about why, are problematic. Some management isn’t good, that is true. Sometimes there are too many meetings. That is also true, those things sometimes happen. I’m at a ‘BigTech’ company, and the meeting rate and quality of management is not consistent or uniform company wide, it’s something you’d have to evaluate on a case by case basis; One problem with your argument is that right level of meetings is more than a lot of devs want, and just because you don’t know what management does does not mean that meetings aren’t effective. With several decades of experience, I have seen lots and lots of programmers who writhe against budgets and oversight and communication, arguing fiercely that it’s all useless and would people just leave them alone to write code. And my experience is watching some of those people go off the rails when left to their own devices. Once you start managing, or try to run your own company, you might start to see more value in communication. My own views on management absolutely changed over time; when I was young, I was speaking about it similar to how you are.
Personally, I think it's good to have at least occasional 1:1s because a lot comes out informally. That said my "weekly" 1:1s with a fairly long-term manager mostly turned into more or less monthlies because we both traveled so much.
Yes, of course, and I do use both. There are underlying assumptions in your suggestion that it’s one or the other, and that async is somehow better. It’s worth considering whether those are always true, and trying to put a finger on the specific tradeoffs, because there are both advantages and disadvantages. I’m a believer in using the right tool for the job (and also understanding clearly what the job really is).
IMO face time is very important and serves more purposes than the explicit information transfer. It’s also a much faster, more efficient, and clearer way to have a conversation, when back-and-forth is needed (which may be more often than you assume.)
In my experience, devs (including younger me) often argue for what’s easiest or most comfortable for themselves, but sometimes they don’t see what’s actually best for themselves, nor what’s most effective for the organization, and they sometimes don’t care what’s best for the manager. (And I’m not suggesting they should have to care what’s best for their manager, just pointing it out.) Nobody likes a budget or oversight. Nobody wants to track time and be watched, and have to explain themselves, and have to compromise in order to finish tasks. Still, having budgets are sometimes good for us and sometimes produce better results, when money is limited and when focus is needed. Budgets also inhibit risk taking, which can be good or bad, sometimes we need risks and exploratory work… so, yeah, the right tool for the job…
The best manager I had in my career was a guy with zero software dev experience. Technical skills and leadership are simply different fields. Converting a best engineer into a mediocre manager doesn't sound like a solution for anything.
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.
Why, no coding experience doesn't mean "dumb". He was able to see the picture, and facilitate productive discussions between qualified team members. It worked wonderfully. Some managers who are former devs just want to leave their footprint on every technical decison really having no time or attention span to dig into a question. Guess which approach is more helpful.
As a data point, I work at a US company that ended up in this place and the same thing is happening.
In my BU there were directors with 2 direct reports. Even at the next level up, the number of non-IC directs is only high single digits. There are many managers who were already engaging technically with the product (not PRs but playing an active role in planning work) and they have no idea what directors are actually doing...aside from attending meetings with other directors.
Almost all decision-making capacity has been moved outside of teams which has resulted in almost no actual work (because everything needs to be cleared by someone with no engagement with product) and people leaving (because promo decisions are made by people who have no idea what anyone is contributing, the worst ICs are the only ones they can retain ofc).
It is a terrible environment to work in.
I don't necessarily think the manager should be best IC but definitely someone who is genuinely talented with sufficient scope and responsibility to make good decisions/add value for ICs. There are way too many passengers today.
Also, this is true of higher-level ICs. At my work, they have no real engagement with product so have influence through ambiguous statements about the general direction that get passed around like the word of God. None of these decisions, so far, have been helpful or relevant.
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.
>> Producing nothing, but for sure making themselves look self-important.
A good manager is worth their worth in gold even if they produce zero technical output. I've had managers that were absolutely instrumental in my career as a programmer, and they did close to zero IC work.
>>Before that the manager was essentially the best engineer in the tea
Yes, and it was absolutely awful. Keep the best engineer in the team as the best engineer on the team. Call them experts, distinguished, senior++, whatever, don't make them managers.
>>Let's go back to what it used to be
God, please don't.
>>We don't need weekly 1:1s to check on feelings.
Speak for yourself please. I find weekly 1:1 extremely important for the entire team, especially in fully remote roles.
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.
You people (as in this HN community) have your conception of middle management taken from memes, comics and to some extent a lack of experience. Managing even 5-10 people means juggling projects, personnel management, being held accountable for all actions of your people, having to be sandwiched between the pie-in-the-sky class and the myopic individual, translator in between. It means jumping on outage calls, doing architecture reviews, and getting slammed with meetings.
Please tell me where these 'managers make a lot of money and do nothing but approve timesheets' companies are, I'd kill to work for one!
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.
Then why are manager jobs now requiring LeetCode and other technical assessments? It's not easy to get any job anywhere unless you have a technical background.
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.
Crazy jeremiad here. This never existed as a norm across the industry outside pockets like Bell Labs. Office Space was not a film about Google's pioneering new management philosophy.
Hard agree. One-on-ones are one of the silliest fads in our industry lately. Why would you wait until a weekly scheduled meeting to bring something up? Your manager's job is to be available to you when you need something, not just once a week. And if they want to know how you're feeling.. they should ask, putting it on an agenda feels very disingenuous.
Me and my direct manager (a C-level) tried weekly 1:1s for a full year and ended up giving up on it because it was clearly unproductive cargo-culting.
> 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 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.
I prefer the exact opposite, especially when working remote.
When I was a manager, I saved non-urgent topics for a weekly 1-1 instead of pestering busy people with "Quick chat?" or "Do you have a minute?" messages. I wish others would do the same.
I don't pester people. I also hate that. In fact, nobody likes that. I regularly see people during the course of my day just doing my job, going to meetings, hacking on hardware, etc., and just say "hey how's it going? Anything I can help with?"
I'm also quite aware of what my people are working on, so its never a "what are you doing?" conversation. Some of my folks are remote, sometimes I am remote. If you do it right it really is just natural.
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.
I unironically want that to be me. Check in, make sure the team is 'well fed,' increase my team's survivability by talking with other teams and advocating for mine. Then I go home at the end of the day, take the kids to school, whatever... I don't really want to ever touch a line of code again either physically or by proxy (Claude code), yet I respect the hell out of engineers and want to fall on swords for them. Where does that leave me?
This jumped out at me right away too. What happened to the days when a dedicated manager would manage 8 reports? What now? AI is going to double the communication bandwidth with these reports and further double the free time they have?
I do think the most efficient form of team is a "cell" of three people. One is a little unstable.
> What happened to the days when a dedicated manager would manage 8 reports?
Cheap money went away which caused companies to start asking hard questions about productivity and how much those dedicated managers were contributing.
Then there's the convenient answer of "AI made me do it", to which investors are somehow really empathetic... feels like every company CEO is operating on the mindset of "its gonna hit the fan any moment now", except they're the ones holding the fan.
Its because when something is illogical, these "brains" retort to using some kind of a streched out metaphor which dumbs it down and makes it make sense, to them at least. So they invent the stupidities like treating a team as a Navy-SEAL unit or a sports team or... coming up with something like "player-coach"...
In most sports you've retired by the age of 40 and most coaches are older than that. I would say that's the reason it's common in sports, but that's the exception not the rule
I was a manager of 12 for several months and that was really difficult. I got a severe burnout, even though I had no IC responsibilities. I cannot imagine how could I dedicate enough time to my team if I did.
Earlier in my career I was a manager of a team of 12 direct reports (non-tech white-collar industry) and it wasn't that difficult to do on top of my normal workload.
Of course, as a manager my normal workload was reduced to account for the managerial tasks, because that's what most industries outside of tech do.
A 30 min 1-1 per week per report would be a full working day. Never mind that if you're an IC then you'll also be expected to support other people using your code, as well as analysing and approving decisions for your reports.
It might be better to have 45 minutes every 2 weeks with reports, which is 1.5 days every 2 weeks. Then probably another 2 days every two weeks for sideways and upwards meetings, 2 days for ad hoc planning and design work, and 4 days for coding and reviewing.
And that assumes nothing unplanned happens and there's nothing that expands in any domain. It's just a way to burn out everyone and create a culture of toxic positivity because you are gonna get fired otherwise.
30 minutes of chat is one thing but one might expect work to come out of it such as things you have to do for or about that person.
IMO it's just efficient to use any excuse to say "what's up, how did the house move go?" or whatever and make sure that you do that with everyone and that you behave in such a way that they don't fear or hate to have a 5 minute chat and know you are ready to listen if they want to say more. i.e. to take an actual interest in each person.
I think the point is to push people out primarily.
This gives them a narrative for doing that by asking for something which isn't doable. Then middle management applies the expectation unevenly to people below them based off of political favor.
lol I read "as many as 15+ direct reports" and thought it was hilariously low. My manager at google had like 50+ directs in 2010. And he was the best boss I've ever had.
Popular conception of what a manager is is wildly unambitious.
Weekly 1:1 is performative and useless. It's not what makes a good manager. What makes a good manager is:
* Having excellent domain knowledge and judgement
* Having the respect of the team, to settle disputes
* Solving problems when needed
* Hiring and retaining an excellent team
* Picking the right things to work on
... etc ...
If a manager is doing these things well I don't need a standing meeting at all. Or we can meet quarterly to check in.
Interesting. I'd define all of those tasks as the job of a team/tech lead, rather than a manager. I've worked at places where the same person did both roles, and it was not always a great mix.
If you think hiring, prioritizing, planning, and cross-team negotiation are all tasks of a tech lead and not a manager, then what is the job of an engineering manager in your opinion?
But how can you know who to promote, how to balance resources, or who to hire if you're not leading the project?
People management is about managing the company's resources to achieve goals. If you are not the one leading the implementation of those goals, you are not going to be able to:
* reason about what the right about of resources should be
* see opportunities for optimization
* forecast future need
You will be completely dependent on a technical lead who does have that information. So then what is your independent role? Just to shuttle information between the technical lead and others?
The most common split I'm aware of is tech lead / eng mgr. The eng mgr does "people stuff" like hiring/firing and cross-org negotiation, and tech lead does "technical stuff".
But the thing is this makes no sense. Tech issues always turn into people issues - when there is a disagreement, who adjudicates? How can a manager adjudicate something they don't understand. And how will engineers respect / follow the decision?
And people issues invariably become tech issues. How can you hire the right people if you don't understand the tech? How will you know when to fire?
This setup makes no sense to me and i have very rarely seen it work. It seems like it was a product of an earlier time when there was a lot of money floating around and provided a way to (a) shield senior eng from dealing with people problem they just didn't want to, and (b) provide cushy jobs to professional managers that didn't know much about the tech.
But it doesn't work. There's no way to do the shielding well and a person with hiring/firing power needs to know what the fuck is going on.
Really good eng leaders must be both good at tech and good at people. That's the job.
Median tenure at a lot of tech companies is around 18 months. If you meet quarterly with your manager, the median employee is only going to meet with their manager 6 times, total! Not to mention people change jobs, and org charts change, so even if you don't leave after 18 months your manager might. How can you build a real relationship with only 6 meetings total?
Do you people only interact with your manager via 1:1? I was constantly interacting with my boss - design meetings, code reviews, product decisions, whiteboard sessions, in slack, in irc ... he was always around.
I got to know him much better through these productive interactions then awkward smalltalk in a 1:1.
And it kind of make sense to meet privately quarterly since perf reviews are also quarterly and that's the only reason I can really think of for a private scheduled face-to-face.
Of course I could always just ask for a private meeting anytime I wanted, which I guess I did from time to time. But it always for a product reason: a tough tech choice I was wrestling with or similar.
I guess it depends on the culture. In a lot of work cultures those other meetings are all work, and if you are fully remote (especially while others are not)* then there's no water-cooler talk.
Plus I think the regularity/cadence of it is supposed to provide some psychological safety. Asking for a one-off meeting feels like overkill for a normal 1:1, and yet a little intimidating for the type of 1:1 that you really need to have a 1:1 for (like discussing interpersonal issues).
* I suppose if everyone's fully remote, in theory the water-cooler talk moves to Slack.
This is stupid and irrational. It's like seeing someone eat 100 cakes, and then assuming everyone can do it. And then getting diabetes afterwards.
It seems quite counterproductive to assume such a system would scale to everyone else, or that everyone else could possibly implement this. This is cowboy levels of human resource management, not careful engineering.
I mean a branching factor of 50 vs a branching factor of 7 is a massive difference. A team of 50 can either be run by one manager and a two-level tree or like 8 managers (!!) and a three-level tree. Think about the difference in execution (and expense) in these two companies.
If you can do it w/ the first model why on earth would you not?
This is "Steve Jobs looking at someone on a fruit diet" and thinking "I can do it too" levels of reckless.
Hell, Dunbar's Number is 150 people, and you expect to have 50 directs? That's literally 1/3 of your 150 being occupied by directs. It seems clearly infeasible the more you think about it.
A manager who is also contributing code is almost an entirely different role than a manager who is not contributing code. Typically the former should not exist in a smaller org and in a larger org it makes sense to shift to the latter because there's enough non-code work to do that you might as well dedicate whole people to the task.
I do think that if LLMs are the equivalent of more employees, then you'd expect people to do more managerial work and less individual contribution. Certainly, that's what I see in my day-to-day.
When your job becomes managing a fleet of agents, with all the design, planning, coordination, supervision and evaluation that requires, is that "individual contribution" or "managerial work"?
If everything is high prio nothing is and if the backlog is always full it's not a problem if it fills up even more. If I am at the assembly line, I am doing my darnedest not to make it run faster. One can only sprint so long.
It is not a problem if you are an assembly line robot making motions. People, however, are not robots. They get held accountable by their higher-ups for delivering on these (often nonsensical) priorities, they risk getting fired when expectations are not met, and high uncertainty of faulty planning systems like that is extremely stressful in itself.
Expectations will be raised until they can't be met anymore. There is always a ceiling.
It is on every single worker to make sure that they don't please the system beyond what is reasonable. Often the problem is people who overwork themselves to please and set the bar over the reasonable amount of work. Still when the majority does not raise their output to an unhealthy amount that must be accepted as a ceiling.
I think you are mixing cause and effect in real life dynamics.
In real organizations people tend to raise their performance to the [often unreasonable] level of expectations, even when situation stops being sustainable long-term for the whole group.
Suggesting that people should simply avoid overperforming assumes a level of control they don’t really have.
What do you think will actually happen at Coinbase now? Is it more likely that people will start saying hard “no,” or that they would stretch to meet the new expectations despite the personal cost?
I can tell you how I would react. They can't fire everyone and I am not going to be the one who is going to fill the gaps that other people's decisions created. If everyone acted the same there would be no problem. Things would just go slower. Expecting the same output from fewer people is stupid. My employment is not by their grace but for their benefit.
Oof. So not only are they giving their remaining managers more reports, but those managers will be expected to do lots of other, non-management work.
Sure, nothing can go wrong there... Even if they didn't have non-managerial work to do, 15+ direct reports is just too many. They're not going to get to spend enough time meeting each report's needs, not a chance.
I think as layoffs emails go, it's a pretty good one (as the current top comment points out[0]), but boy, I would not want to be working at a company like what Coinbase is turning into. Non-technical teams shipping code to prod? No thanks. "AI-native pods"? No thanks. I do like the idea of one-person teams; I was at my most productive when I was in that kind of role (though I'm not sure my experience generalizes). I get that companies are still struggling to figure out how to adapt to LLMs, but... damn.
Pretty solid severance package for the folks being laid off, though.
[0] https://news.ycombinator.com/item?id=48021843