When people ask questions like "Why does it take X engineers to run twitter?", well that is the reason.
If this was already the case at your company before the WFH, then yes, WFH didn't change anything, or even maybe let your emloyees work on the wrong thing even faster.
The other thing people don't appreciate is that it's significantly harder to find good managers than good individual contributers. I believe that management is about 300% more efficient in an in-person environment. As in, I can effectively make sure that 3x the number of people are working on the correct things in an in-office environment.
I find it nearly impossible to find people with the ability to do this correctly right now, let alone somehow needing to find 3x this number.
Even if people worked at half speed at the office (which I don't really believe), that is still worthwhile.
It doesn't match my experience though. The person I hired during WFH consistently works on the right things and has great judgment, while the other team members who predate it are either neutral or struggling in the same way they did before the pandemic.
Why do you believe seeing a person live makes it easier for you to instruct them on what is worth spending time on? What's your evidence?
(There is of course a lot of nuance in my specific situation but would love to hear general thoughts on what makes a manager good.)
Training materials and “what good looks like” references for self guided study
Mentoring from yourself or good performance seniors on team
Specific goals and projects to aid in development
But emphatically the solution is not to force the rest of the team back to office as some sort of punitive measure.
But I was never a good manager, and I don't know how to do better.
I've seen two strategies that seemed to work for teams. A) foster a healthy culture of people who want to do a good job and let their interactions increase the standards. B) Have a ton of process.
Option A flows top down and requires the people to interact. In-person friendly nudges to bring the new kid up to speed are effective and not taken as criticism. Nudging over email or chat, it's hard to convey that we're all on the same team, and I think it leads to resentment.
Option B is unpleasant and achieves maybe 10% efficiency, but progress keeps moving. People tend not to squabble because nobody cares enough to put the energy into it. I hated these environments.
There really is a difference between communicating in person vs online. For instance, you'll probably lock your heals in response to what I wrote in this post, whereas in-person we'd probably exchange some smiles and body language and we'd both know it's just a friendly conversation. :-)
I guess I’m trying to say that a lot of managers are afraid to give the negative feedback they hold privately and even lament to their peers about.
So some underperformers have no idea they are on thin ice until it is far too late. By being nice this type of management isn’t actually helping the person grow.
Sometimes a blunt conversation works wonders for that one person on the team that everyone knows is a problem child. Sometimes the conversation uncovers the person is unhappy due to something outside work and needs a little time/space. Sometimes it turns out the person doesn’t like their current role and you can help carve out a better fit for them.
Waiting for the annual review process to mark someone down or to start a PIP once forced to do so doesn’t help them.
Anyway I doubt I was a good manager either and am glad to be a high paid IC instead.
If someone wasn't working out, I tended to sideline them and try to move them to some other group. It was certainly better for me, and honestly I think it was better for (most of) those people too. I was happy to see several of them find a better fit away from me.
Being retired now, it's easy to think back on all the mistakes I made. I much prefer working on solo projects for fun.
Just like if there’s something at a company I work for is unacceptable, first I see if it can be changed, and if not find another job.
It’s like finding someone who’s lost, but doesn’t know it. Letting them continue on unaided is callous. Calling them an idiot for getting lost is unhelpful. Giving them a map and checking in with them is the decent thing to do.
I've found a lot of managers don't really give feedback in a way that is clear & actionable. Some assume that bad performers are either 1) aware they are performing badly or 2) just unable to perform any differently. So either 1) resentment at the bad performer for "gaming the system" or 2) "soft bigotry of low expectations" that the idiot can't help themselves. A lot of these managers put aside their low performers as a lost cause and spend all their time trying to make their A player perform A+. The ROI of making an D player into even a C+/B- is much higher!!
I have never had to sideline anyone. Either they perform, respond to constructive feedback, or they’re gone. I don’t have the time or mental energy to do anything else.
If you are not giving timely candid feedback as to the what/why/when/how to that team member as to their performance issues, you are doing them a disservice. The sooner they have an opportunity to course correct, give their feedback to you, or ask for a role change.. the better. Coasting along without agency for a year or two until PIP season is not fair to them.
With Remote, many things have to be put in writing, organized, and referenced back to.
Way less room for misinterpretation than the occasional drive-by chat.
What drives (drove) most of it is that as a product matures and the user base grows, polishing smaller features and chasing 0.1% wins can meaningfully drive metrics to a point that having a team focus just on a single user flow is a net positive. Enabling this often means a more modular codebase and system architecture so people aren't stepping on each other's toes. There are also exploratory features that are unlikely to pan out, but at the scale of 500M users, if they do, it's huge. A lot of this work might be wrong, but some of it isn't, and you won't know what's what until you try.
At 500M users, you also need more spam detection, account protection, content moderation, etc.
You can run status quo Twitter with fewer engineers, but don't expect incremental growth, and expect more issues like the recent SEC mishap.
Twitter doesnt seem to be doing the latter.
I'm going to be a bit blunt but most of management in reality is useless, if not actively harming people under them. 300% of 0 in those cases still remains 0.
Having ICs in the office doesn’t suddenly cause managers, product owners, or business people to figure out what the true direction is. And ICs typically only work on what’s assigned to them.
It's not worth me driving an hour and a half to the office (and her flying from many states away) just so we can discuss these things in person. And the product is coming along very well. We just had a successful demo that impressed a lot of people and secured another year of funding.
And this is the third major product I've worked on entirely remote, all have done very well. That's not including the video games I developed along with artists that I never met in person that also did well back in the day, where we only communicated with text via AOL Instant Messenger and sending files to each other via email.
Leadership and managers that don't take advantage of this and instead "listen to their gut" are gambling.
This was one of my biggest lessons transitioning to management. My biggest mistakes have all been cases where a feedback loop from engineering to PM/UX/leadership was missing and I failed to set one up. Biggest successes have been projects where I set that feedback loop up early and got out of the way, so that engineering and UX had a high-bandwidth communication pathway to negotiate issues and make product compromises based on real constraints.
Unfortunately it feels like I'm swimming upstream when it comes to actual org policies here, which have forcibly reclassified me from a TLM to an Engineering Manager (so my official job duties now include assigning work, but not necessarily understanding the work I'm assigning), given me a reporting load that's too big to understand the details of each project I'm managing, made my report's performance reviews independent of how well they work with others and instead fully dependent on how much they please me, made my performance reviews largely independent of how well I support my team but very dependent on how well I please my superiors, and so on. Somebody in upper management wants people to be responsible for things and yet doesn't seem to know or care much about how to actually get results in a knowledge-based org.
Your job is to understand the domain. Your job is to talk with users and technical support staff and product managers and read about the domain and care about what your users care about.
From there, your job is to explain what you have gathered, connect it to the technical challenges, and explain this to the ICs and work with them to make sure they understand what the right thing is.
You can do all of this on zoom calls and sending links for them to read and reinforcing this in every 1:1. Ask them questions about what they understand about the product and why it matters.
And if your reporting load is too high to dive in deep, you need to delegate many of those tasks. Explain why you are delegating them - writing a status is not the most fun task for an IC but you can use that to distill what your managers need to support the team.
I can do this over zoom calls & docs & links - my team is half remote, and they continue to be productive. But it's a lot less efficient. When everybody's at the office, ICs talk amongst themselves, if they're missing context on product goals or an important change to the codebase they'll hear it from their coworkers, if management is making a bone-headed decision they'll talk amongst themselves and eventually it'll generate enough buzz that it'll get reversed. The model of "manager figures out what to do and then tells remote employees" lacks this resilience, and these feedback points. Employees are usually pretty well incentivized to not tell their manager directly when the manager is screwing up (although I actually have a couple directs that are good at this, and I listen closely to it), and when touch-points all go through the manager and people see their job as to execute on what the manager decides, that information that "hey, this plan doesn't make any sense" doesn't really have a good way to bubble up.
BUT. And I say this with all respect, since I broadly find a lot of value in your comments: I strongly disagree to your assertion that remote "is less efficient."
My theory to what is happening is that there are existing methodologies people are used to working in, including 'hacks' to build consensus that were developed in an in-person environment. (Namely, pulling a bunch of people into a room and arguing it out.) My perspective is that remote work makes a bunch of things that are just as critical in-person (shared documentation, good communication channels, trust and rapport, etc etc) non-optional, and your previous hacks far less effective. But I don't see this as a bad thing. If anything, it's like a strongly typed language: It forces you into a more effective pathway. (For instance, imagine how remote folks or even folks-just-not-around-at-the-moment felt in not being able to participate evenly in the "in-person-bash-it-out" sessions or hallway chats without a strong culture of proliferating knowledge and documentation?)
While you may reasonably say "Ok, that's fine, people built up methodologies, why flip it on its head and disrupt a status quo that works" to which I'd emphasize the "we were relying on suboptimal ways to build consensus, and it was a local maxima." I would also propose that I believe a good manager _HAS_ to change their methodologies in some ways more disruptively than just the local/remote shift when dealing with certain styles of employee, (their own) manager, and org+busines structure/process/incentives, and as such, this should just be part and parcel with the constant process of adapting to refine your own methods and style.
(As an aside, I was tempted to make this comment on your upstream comment[0] talking about "maybe I'm not actually succeeding, it feels like winning at a fucked up system" since I definitely feel you there. I got into management in large part out of a "I'm frustrated by how management is often done and how it ends up percolating down to ICs, and I want to put my money where my mouth is that there's a better approach", and while I definitely feel like I've succeeded in some respects, and continue to get "rewarded" as you say, I'm intimately aware that I'm likely still screwing things up/finding the optimal way to balance pathological incentives, and still have a ton to learn. In short, I'd not be surprised if both of us are "doing fine but still have blind spots," so please take my above just as one person's opinions/"attempt to draw the elephant" :) )
I'll let some manager explain why you're misrepresenting the responsibilities of managers, but as an IC I can tell you I would be offended if any manager I worked with acted like it was THEIR Job to understand what is the right thing is, then just tell me what to do as part of that.
And it pisses me off when other IC's I work with don't seek or desire agency.
By the way just knowing WHAT to do is only part of the task - HOW to do it is another one that also requires collaboration between technical IC's - whiteboarding, pair programming, etc.
The job of the line manager is to take a giant amount of information and develop a mental map in which he can present the context to the team. It isn't that an IC cannot do this (though I see this as more rare than I would like!) but rather if an IC did this, they would be in 20 hours of meetings.
"The right thing," in this case, is not breaking down the tasks into mindless coffee to code, but rather "Four of our customers are really frustrated by the lack of this feature, so our PM has prioritized it. It's in an area we've identified as having some technical debt. Design has a proposed idea of how we could solve it. Talking with support, two of these customers are enterprise and want more ability to customize to their processes, and two are mid-market and would rather it was easy to use. This is going to touch an area you all have identified as having technical debt, so it'd be great if we could use some of that time to make progress in cleaning it up. We'd ideally like to constrain this to three months of work. Now, team, how much is possible given those constraints? What scope do we need to cut if it all won't fit?"
That cliffs notes can be as a result of 20 hours of meetings and research. Now, it's the team's job to take that brief and work toward the art of the possible and help the team if they also need to talk with the stakeholders to gather more information. However, somebody needs to do that work. That person needs to have a technical background at the senior level, a high tolerance for meetings, the ability to work across the organization and maintain relationships, an understanding of business as a craft, and an understanding of the domain.
Can a senior engineer do all that? Sure! However, it is hard to do all of that and have as much time to actually code. And most individual contributors start losing joy in the job if that becomes a significant portion of the job. (That, or they end up as managers.)
In truth, we could completely divorce this role from people management. The authority is the least interesting part of the job, and is a relatively small portion of it. But even if you completely went to a communist, non-hierarchical system, you would still need someone to work in this role.
Anyway, I think we are seeing a rethinking of what management is - and that will have implications for elite / aristocracy as well. There will be a fight.
My two cents are that the “workers” for many industries are moving from human beings to CPUs. There are amazing photos of rooms of “accountants” simply adding numbers on adding machines which are passed up the line till the corporation gets a final number. Each of those got replaced with whatever IBM made in 1956 (besides Fortran). The manager of that room of humans suddenly stopped worrying about Bob’s attitude and had to worry about silicon.
Something less obvious and photogenic has been happening for years.
Coders in short are the new managers (supervisors)
But we have three other jobs of “management”
- technical lead : understands the details of his area deeply and can make trade offs and build a better engineered product (ie door plugs that don’t fall out)
Product management- honestly I remain dubious about this as a category - with good user communication a tech lead can do most of this, until we shade into strongly fashion / FMCG
- organisational manager - someone looking at the needs of the org - how will this affect the nebulous idea of the company. This is the point at which politics takes over - this level of management is primarily running budgets 100x their own salary and so can be seen more as financier or VC than part of the company. However this is how for example the Post Office justifies jailing it’s own employees
I am wandering off the point a bit - paint fumes I suspect, but there is one final point to make - management differs above from working in the company - on day to day operations - and working on changing the company - new projects and initiatives. Theoretically the cut off is supervisory (ie. Coders are new managers)
But that’s never true - most innovation bubbles up and is then selected in a competition by various hierarchies
I think the point I am making is that we do not need superman as manager - we need properly aligned systems and incentives, which I suspect only happens in open daylight
But I have a blog I'm half in the middle of that dives deeper here. The manager is less "superman" and more a collection of part time jobs, one of which is to be contextual hubs for the organization. Within most IT organizations, it is their job to gather information from across and outside the organization. That isn't as much a "superhuman" job as much as a role that takes a job.
The real problem is that we tied "people management" to this job. I don't think that's a necessary feature but rather a historical coincidence.
I think you are pointing at a disaggregation of the manager role - and I agree My take on the various roles is
- (Model, Monitor, Mentor)
- resource allocation
- hierarchical politics (ensuring the continued existence of the hierarchy and shifting currents within that hierarchy for rights to resource allocation. Certainly not significant rethinking of hierarchy)
The first two are replaceable by software, resource allocation and hire by politics are replaceable by democracy.
The combination of software and democracy in our organisations threatens everything
Most places are bad.
Is it this way because they have "manager" on the task name?
Not a personal sleight against you, just there are many features of the system around you that should at least cast doubt on your interpretation.
This is in general a good argument against WFH but one that managers are (for obvious reasons) reluctant to make: they’re just shitty managers and WFH makes it extra hard to get by with shitty management.
I usually like to think of it as winning at a fucked up system. But then, that might be pretty illustrative of the title and article here.
In any case, it’s good to be relatively good, so I’m really happy for your success so far! It’s not an easy job at all.
We have biweekly meetings where we arrange our goals and strategies, and share what we've been working on. We call each other constantly when we're struggling with a problem, and I have 1 on 1 meetings with everyone at a frequency of their choosing to talk out potential problems, bitch about engineering challenges, or just shoot the shit for a little bit. This is possible to be done and the fact that it's kind of vaguely easier to do it in an office, IMO, is a shitty trade-off to offer for all the costs, both financial and personal, of RTO.
And yeah completely agree on working on the right things. Programmers (me included) pine for “focus time”, but we need a lot of talking to know if we’re overengineering or underengineering. I’ve watched a lot of people get their way with too much focus time and implement the wrong things, wasting weeks or months at a time.
But... that's kinda ok? A company might be upset at any negative effects that might have, but I personally think it's a completely acceptable (fantastic, even) trade off for the ability to eliminate a commute, work in comfort, and have a more flexible schedule.
Obviously not all companies are going to do remote onboarding well. Just as many companies don't do a great job of in-person onboarding either. But that doesn't mean throw up your hands, give up, and make people go back to the office. It means... do better.
I do think remote onboarding is especially hard for people starting their first job in the industry. But I'm not convinced these problems don't have solutions. Maybe not perfect solutions, but good-enough solutions.
I keep hearing this while at the same time seeing very little evidence for this.
Most 'water cooler social stuff' is absolutely pointless small talk at best that you have to often engage in to remain polite. I'd rather not if I could avoid it except for certain circumstances with people I am already 'friends' with.
Guess what I do with those coworkers I am friends with? we have a separate channel/group from official channels where we do that already. Nothing's missing there.
It's easier to just go "hey want to grab lunch?" in office, I'll grant you that, but it by no means is an 'absolute stop' for new hires from socializing with coworkers.
Our experience with software development team was WFH actually helped with the larger picture. It allowed people to be more strategic and intentional about decisions, instead of trying to do that in the daily tilt-a-whirl that is the office.
Where are we seeing this? I'm a manager at a mostly WFH company and we don't fall short on this.
Big thing is this was never an office based company, WFH is in the DNA from the co-founders and while we regroup occasionally, remoteness has not affected our ability to grow and build meaningful things. One could argue that we might do better if we were an office based company but as far as I know there's no data out there showing that this would be the case.
IMO companies should embrace what they truly are and not force it.
What I would add as someone who has been managing collaborative science teams embedded in large companies remotely, pre- and post-pandemic, is that some forms of alignment translate to the remote setting, but other forms of alignment are more challenged. I think the boundary is probably: if the teams were aligned pre-remote, you can sustain the alignment, even with new collaborative initiatives, but gaining new alignment with new teams is way more challenging.
Which is fine when what you are doing is Business as Usual, but falls apart when there are crises or disruptions that require net new collaborative relationships.
Sure, communication isn't as fluid, and you lose some context cues, but we're not talking about things that need intense physical interaction.
I did enjoy going into the office from time to time for group meetings (I lived close enough to the office for that to be easy to do), but never felt like the meeting was significantly more productive in-person.
No need for this antagonism, regardless of whether it's true.
Anyway, yes, I think your theory is based on something true on average about RTO vs WFH. However, improving collaboration under WFH is simply an easier problem than improving focus/efficiency/work-life-balance/happiness/etc under RTO, for most people.
I don't think I would ever want to do a full WFH/remote arrangement, rather one that allows for flexibility without judgement and mistrust.
It's been my experience, that everyone (from the lowliest IC to the CEO) fails to understand the cost of team synchronization. That's a [set of] topic[s] that would fill an entire bookshelf, and anyone that gets it right, could live in opulence.
That isn't necessarily a bad thing, but it needs to be planned for, by managers and architects.
Architects need to design systems that allow ICs to have more personal agency, while encouraging synchronization (an approach that I use, is blackbox implementations, and whitebox APIs). The more an IC can work on their own, the better, but we still need that transparency.
Managers need to know when it's OK to send work to remote agents, and when work is required in-office. They need to know their teams well enough to be able to choose wisely. Human nature is a big deal. Until the entire workforce is AI, you'll always have those pesky humans in the mix, with their annoying emotions and personal lives.
Also, and this is almost never talked about, is that different people work differently. Some folks are almost superhuman, when left alone, while others just screw the pooch.
They may both be incredible employees, but they need to be handled differently.
Unfortunately, modern HR practice, is to treat every employee exactly the same as every other one (and there are actually valid reasons for this).
TL;DR, it's not simple, there's no "one policy to rule them all," and good managers are hard to find.
Meeting from time to time is great, but the RTO push has been problematic across multiple dimensions.