[bluefishinit]

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.

[sarchertech]

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.

[doxeddaily]

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.

[asoneth]

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.

[re-thc]

> 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.

[asoneth]

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.

[bluefishinit]

> on average we found productivity plummet with remote junior hires

I'm curious how you're measuring productivity. Most people really struggle with this and can't do it accurately.

[asoneth]

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.

[bluefishinit]

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.

[asoneth]

Totally agree that hiring locally is much more constraining. 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 for our area so we have it easier than most. Logically our remote competitors should be at an enormous and overwhelming competitive advantage.

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.

[bluefishinit]

> But the trend seems to be more companies going back in person.

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.

[doxeddaily]

Well sure, seniors have concerns outside of work that juniors often don't have.

[asoneth]

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.

[bluefishinit]

> Folks who consider themselves "high-velocity"

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.

[asoneth]

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.

[bluefishinit]

> 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.

[sarchertech]

> but are not as successful year-to-year.

How many times have you had teams in both categories that were mostly the same people and environment for long enough to judge this?

[steve1977]

> 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.

[asoneth]

> 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.

[mmcdermott]

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.