I think this is the crux of why people have such disparate estimates of remote productivity.
Senior folks seem to experience more upside and less downside being remote whereas junior folks seem to experience more downside and less upside.
Depending on the makeup of the team, one or the other may be net more productive even if you yourself feel less productive. (It may also depend on whether your company sufficiently acknowledges and rewards the work senior folks do unblocking and mentoring others.)
I don't think senior/junior is the right divide. There's tons of young people cranking out absolutely amazing things from home in the open source community. What I've found is that product focused people who ship with high velocity like remote work, regardless of their time in the industry.
Low velocity shippers who lean on process are the ones who seem to want to go back in the office. Presumably because you can mask not shipping by chatting with your manager or playing meeting roulette.
That lines up with my experience as well. I think though that there is a cutoff where very junior people are almost never going to be highly productive and require fairly constant babysitting.
I think you can mentor/babysit them in a remote environment, but it takes intentional effort.
This is just a symptom of a larger problem though, which is that people try to get useful work out of very junior developers. They should instead treat them as investments that will generate useful work in the future. If you can’t do this, you shouldn’t be hiring juniors.
I agree, if you are hire juniors you need to know what you are getting.
The thing is not all juniors are the same, some are a lot more immediately productive than others. When it comes to remote work it's hard to bullshit, you are either checking things in, or you aren't. You can only go by productivity.
I don't doubt your experience, but it is not my own. There are absolutely exceptions who prove the rule but on average we found productivity plummet with remote junior hires and remain similar for folks who have been at the company for decades across all skill levels. Even high-velocity junior folks seemed to be spinning their wheels or getting stuck when remote in a way that perfectly average senior folks did not.
I was anticipating employee pushback as the company switched from remote to return-to-office 3 days a week last year. But the junior folks I've talked to have seemed mostly enthusiastic (with significantly higher retention than when we were remote) whereas the objections mostly came from senior folks. The people who quit to keep working remotely were almost entirely senior folks.
> I don't doubt your experience, but it is not my own.
Are your scenarios the symptom or the cause? Do juniors prefer in office not because of the office or other reasons? E.g. do they have the support they need remotely, is there enough documentation, etc? Usually requiring adhoc in-person interactions is just masking the real issues. The seniors are fine because they've already had workarounds for it.
In talking to the junior folks the two things they bring up are mentorship and socialization.
With mentorship I think you're spot on with regard to adhoc interactions. Senior folks know who, how, and when to ask when they're blocked, or when they need to plant an idea in someone's head. Even though we have daily stand-ups, weekly 1-1 check-ins, and responsive mentors a number of junior folks seemed less comfortable admitting and asking for help when remote until it was too late. My company is overall the best place I've worked but has poor processes in this regard -- it's one of those places entirely run by engineers where everyone is proud of how "flat" the org is which is code for a hidden and ad-hoc org chart. I'll bet manager training and process could have minimized that, but it would be a tougher sell than RTO -- so you go to war with the army you've got.
With regard to socialization, the junior folks seem to hang out with each other after work quite a bit more. We also have lots of social events, presentations, movies, etc during work hours. We had similar sessions set up for remote folks that are well attended but don't seem to scratch the same itch.
Normally I agree, but the differences were particularly stark. After a couple of years the top junior performers were almost all in-person. They were more self sufficient, more likely to still be working at the company, generally made the products they worked on more successful, etc. There were certainly exceptions, but the trend became fairly clear even to remote work advocates. I think that's why we had so few objections to RTO -- even folks who quit over it admitted it was the right choice for our company.
I'd wager better remote processes and culture could have shrunk the gap, and I'm happy so many companies are doing that well, it just didn't work for our company.
I guess we just have different experiences, but I will say that in 20+ years in the industry working in a ton of companies of different sizes, on products used by tens of millions of people... that the highest quality output has always come from remote developers. Some of that is because you can hire world class devs if you look anywhere in the world, but if you hire locally you're tied down to the best devs that can commute to your office, a talent pool orders of magnitude smaller than the global dev community and excluding those people good enough to refuse anything other than WFH.
I think you may be on to a useful distinction there, but I'm not sure I agree with your implicit values.
Folks who consider themselves "high-velocity" seem to look down on process and prioritize their own productivity over the productivity of the team and the organization. They seem to believe that they'll be evaluated on number of features shipped, or tickets closed, or lines written. They seem to consider coordination with others to be overhead that distracts from "real work".
That mindset may work for small shops or independent features but in my experience successful large products are built by people who are willing to invest as much effort in coordination as they do in heads-down coding.
I'm not talking about self-diagnosed high-velocity, I as their manager see that they are high-velocity, high-quality developers.
> That mindset may work for small shops or independent features but in my experience successful large products are built by people who are willing to invest as much effort in coordination as they do in heads-down coding.
I've always modeled my team's process on open source development, which has successfully produced very high quality "big" software. Documentation in code, PRs and issues, async communication... I've never seen regular company process (things like Agile) produce software that matches the quality of that done with a more distributed and async process.
From that perspective, hiring accomplished open source developers leads to an amazing team. Back to my original point, those people may be 18 years old or 60 years old. The trick is to build a team of people who have a proven ability to ship.
I'm not sure what more there is to say. I'm happy that you have created remote processes that work well for your team. I wish we were better at that. My personal experience is still that groups of high-velocity rockstar developers relying on asych coordination can deliver features faster day-to-day but are not as successful year-to-year. I do believe you that it's possible though, and perhaps someday fully-remote competitors with lower salary/office costs will eat our lunch. Perhaps it requires better managers than we have. Still, we ship software our customers love and are extremely financially successful so I have trouble faulting management for continuing to do what has proven successful.
> I've always modeled my team's process on open source development which has successfully produced very high quality "big" software
That's an interesting example and reminds me of an anecdote. At my last company I worked on a very (very) expensive fintech product. We had several competitors including an open source alternative that we were quite nervous about. I wouldn't be surprised if their code quality was higher than ours. But while many customers donated to them, spent a lot of effort integrating them, and talked about them a lot (especially when negotiating contracts) in the end we never lost a customer to the open source alternative.
Don't get me wrong, I love free and open source software and personally use and support several projects. But with a handful of exceptions open source developers seem to be more successful at creating tools for other developers than products for non-technical end-users.
> can deliver features faster day-to-day but are not as successful year-to-year.
This sounds like a management problem. If you have productive people and that productivity isn't leading to success, there's a bigger problem in the company at the strategy and product definition level.
> Perhaps it requires better managers than we have.
That's the thing, if a company insists on working from the office it's a sign that they have bad management. Not every remote company has good management but the inability to manage remotely is a sign of bad management.
> in my experience successful large products are built by people who are willing to invest as much effort in coordination as they do in heads-down coding.
In my experience, successful large products make so much money that it's possible for non-productive people to exist in large enterprises. This wouldn't be the case on smaller case. But that does mean that those people are actually needed in any way.
> But that does mean that those people are actually needed in any way.
True, the presence of people who spend time coordinating is not sufficient for success, nor is their presence in any way evidence of success.
But the absence of people who devote time to coordination has definitely sunk projects I've been on, including ones stacked with brilliant rockstars. It may simply be correlation, but I have never worked on a large, successful project that lacked people who were willing to invest significant effort in coordination.
I suspect it's more individual contributor vs. leadership, where senior developers are more likely to be in some form of technical leadership role on their teams.
The senior folks are sometimes cleaning up messes created by the junior folks.
The last 10 years it seems like junior developers have become less likely to own up to their mistakes and senior engineers have to track down the mistake and then pull in the junior engineer to discuss what the mistake was and what the fix needs to be. The Junior engineer didn't want to participate at all and thinks their productivity is being impacted because they just want to keep working on whatever new feature ticket they think represents productivity. The seniors are thinking their productivity is increased when everyone is in the office cause they can much more rapidly find the people responsible and pull them into an in person meeting and do a full interrupt on the people responsible for an issue.
It's like the juniors are too incentivized by completing new feature tickets versus generating positive customer impacts or something.
I've been at 3 companies in the past 11 years and seen this at all of them.
I don't understand this way of looking at things. I sometimes learn something new by answering a question from someone who is looking at things from a different direction than I am, or discussing something I don't have a quick answer to. That helps both of us. If I don't even have to think about it, it helps the other person be immediately productive (and learn something) at the cost of taking me out of "the flow" as opposed to having them beat their head against it for who knows how long while I get a a couple more minutes of uninterrupted time. I can hop back into "the flow" pretty much immediately.
If it happened every five minutes that's a different story.
> I sometimes learn something new by answering a question from someone who is looking at things from a different direction than I am, or discussing something I don't have a quick answer to
This can happen on Slack or whatever too, but with much less friction. I'm not ignoring teammates for days - I just want to be able to take 10 minutes or whatever to reach a reasonable place to context-switch versus being forced to do so right now.
> I can hop back into "the flow" pretty much immediately.
I envy you, but I very much cannot do this. If I'm working on something of sufficient complexity, I'm going to lose at least 15 minutes every time I'm forced to make a substantive context-switch. It's a huge drain for me.
This is a great way to get management up your ass and get fired.
End of the day, it’s all about the culture of your workplace. No one here really understands that. I’ve been interrupted more during remote work at some companies than when in person at others. It’s entirely culture dependent.
Easy, just learn to push back or setup mechanisms like office hours to attend for folks whom are in need of support.
Like security, the human chain will always be the weakest link here. If you don't have backbone to stand up for your own time, that's on you - not the remote work inherently IMO.
About ten years ago I worked at a company with a DBA who saw gatekeeping everything database related as a form of job security. But he also complained bitterly about how often he was interrupted. Even simple things like adding a column to a table required his participation. When developing, these types of changes are frequent and often blocking, so creating something like a ticket queue wasn't a good solution. Our manager was not only aware of the situation but seemed entertained by the inherent conflict it created.
Since going through that extreme case of blocking through gatekeeping, I try to keep my eyes out for ways to allow other to self-service as much as possible. It's not possible to eliminate all interruptions but it's often worth spending a bit of time examining how the interruption could have been avoided in the first place and if similar interruptions are likely, invest in creating something more self-service. At least in the DBA situation I was in back then, simply allowing developers to have local database or even control over development database on a dedicated database instance would have eliminated most of the blocking and interruptions.
If your superiors don't consider you training people part of your job then you should either get them (ahead of time) to agree it's part of your job or you should stop doing it.
The thing is it's not always obvious. You don't always spell out how many hours each day you spend training others and so management just thinks you're doing nothing.
And then seniors have to pull overtimes just because they need to semi-constantly babysit juniors, or clueless managers of other teams or projects who only know how to escalate and chase etc.
I get it, if you are junior, there are benefits. If you are senior (and not ie team lead and control freak at the same time), you lose. Hell you lose a LOT, can confirm. Offices are way more stressful, so this is clear downgrade for senior people. Constant noise and interruptions way overweight the benefits.
Guess who brings more added value to companies, juniors or seniors? (not talking about long term perspective, most companies are led by people who focus on next bonus only, and who they manage is steered that way too).
A former boss called me the most distractable person he had ever met. I've worked in open plan offices since 1997.
But apparently I have superhuman abilities to concentrate, because honestly I've never found it difficult to ignore people around me to focus and get work done. And yet I don't feel special, most people I've worked with seem to able to do it.
I understand many people don't prefer it, and they should very much choose jobs accordingly. But I guess I'll stop pretending my preferences are based on objective criteria when everyone else does too.
For me, this is the bottom line. Working in an office -- even the best offices I've ever seen -- is a pretty terrible experience in a ton of ways.
In my younger years, I kinda gave up on actually getting anything done in the office. It's just too difficult. So I'd take my work home and make up for the time wasted in the office by doing my work in the evenings.
Eventually I wised up and stopped doing that, but that didn't make working in the office any more productive.
I think it's generally better to take the short-term productivity hit to train the new hire than it is to leave them to the wolves for your own work. Two heads are better than one and all that
By the only metric that matters -- collective output.
Combined with the negative metric of employee burnout, which inevitably follows from years of exposure to open plan offices, constant interruptions ... and the toxic positivity of company owners pretending how wonderful these things are for everyone.
Some people don't work like that. When I'm in a flow state, a 5 minute interruption can break me out of it and slow me down for a half hour or more before I'm finally able to get back into flow.
They are doing it wrong. If you keep two or three things on the go you can switch to a different one when you get stuck without wasting hours or interrupting someone else right this minute. Very often, having switched focus the solution to the original problem will reveal itself without needing to bother anyone.
An org can find ways to ensure juniors don't stay blocked while also ensuring that seniors can keep in flow state for long, uninterrupted periods.
Prioritize docs and tests. Teach juniors how to use docs and tests. Spread knowledge and mentorship around enough that a question on the team channel gets an answer from someone who is available.
All of these things have other major benefits in addition to restoring flow state for seniors—juniors learn faster, your tests are more comprehensive, seniors can basically onboard themselves, your bus factor goes way up. "Stick everyone in the same room" is just a local maximum, not peak productivity.
Senior folks seem to experience more upside and less downside being remote whereas junior folks seem to experience more downside and less upside.
Depending on the makeup of the team, one or the other may be net more productive even if you yourself feel less productive. (It may also depend on whether your company sufficiently acknowledges and rewards the work senior folks do unblocking and mentoring others.)