[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?