> You also lose the ease of just walking over to someone to ask a question.
Well, the person that got interrupted by you probably lost quite a bit of productivity because of you.
Well, the person that got interrupted by you probably lost quite a bit of productivity because of you.
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.)
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 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.
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.
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.
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 have seen just as much of the reverse.
That is absolutely possible. In the end, the question is whose productivity is more valuable to the enterprise (and who do you measure that).
In my case, I often get interrupted by "non-producers", so I would guess my productivity is worth more. But I'm biased. ;)
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.
Or if I’m already on DND? Ignore, and create an appointment for later.
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.
If you get fired for doing that sort of thing, the company is doing you a favor.
So uh no. Can’t jump on a zoom real quick, I’m doing work.
10 might actually be 2 hours, but whatever.
If it happened every five minutes that's a different story.
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.
I don't see what he said as lacking communication. It's enhancing it by allowing them to "schedule" it according to their workflow.
Very rarely does anything actually need an immediate response, and when it does, just call the person.
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.
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).
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.
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.
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.
Then why is my performance review always individual?