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.
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.
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 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'm curious how you're measuring productivity. Most people really struggle with this and can't do it accurately.
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.
But it hasn't happened yet. I mean, I wouldn't be surprised if it does happen, maybe it's just a matter of time. And personally I hope it does happen, as remote work is better for the planet and regional inequality.
But the trend seems to be more companies going back in person. Maybe they're all behaving irrationally or trying to prop up commercial real-estate or something. But it's also worth acknowledging the uncomfortable possibility that high-quality output from world-class rockstar devs isn't as critical for making successful products as coordination between perfectly average developers, and the latter being slightly easier in person is enough to offset the costs.
That's the trend with the megacorps but almost every startup that's been created in the past 3 years is fully remote or at least remote friendly (for the reasons we've both outlined with regard to access to talent and lack of office overhead).
> But it's also worth acknowledging the uncomfortable possibility that high-quality output from world-class rockstar devs isn't as critical for making successful products as coordination between perfectly average developers.
> I'm having trouble filling positions and we're in a major tech hub and can afford to pay near the top of the range
I have to say that in all of my years of management I've never struggled to hire amazing developers. Some of that is that I will only work on interesting problems and it's easy to attract great devs in that situation. I'm not sure what I'd do if I had to hire local to where I'm physically located though. That would be an issue in both crowded markets like the valley or non-crowded markets (with little local senior talent).
Have you ever tried building a purely remote team? The number one thing I'd recommend is to focus on trust. Remove as much process as possible and trust your team to do what you hired them for. If they're not succeeding, it's possible the wrong people were hired, which indicates that the wrong managers were hired.
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.
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.
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'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.
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.
How many times have you had teams in both categories that were mostly the same people and environment for long enough to judge this?
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.
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.