Maybe you are correct. But ICs do not decide what to work on, the PMs and other leadership do. So why can’t ICs continue working from home while the “deciders” go back to the office?
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
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.
Most places are bad.
Is it this way because they have "manager" on the task name?