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