These days there is pressure on many software development teams to ship software more often. With the growth of DevOps and the numerous stories about companies that update their applications regularly, more managers are putting pressure on their development teams to perform. This can be a challenge as the culture changes needed to alter the way we work and achieve frequent updates are difficult to achieve.

I saw a post from an entrepenuer, Naval Ravikant, on building a team that will ship software. This is advice for a startup, which often has different goals, challenges, and structure than more mature teams. Certainly I've seen the way we've built software at a few employers change. Even at Redgate Software, what we do to build software wouldn't the same as what we did as a small company with 10 people.

As I read the list, I can imagine why some of this advice is there. The need to push forward and get software working and in front of customers is strong. Sales, marketing, and certainly the users of the application want to see things move forward, features added, bugs fixed, and a reason that someone will pay money for the software. This rapid pace requires some decentralization, some lack of control, and trust in your developers.

However, at some point this isn't the model that a more mature organization needs. While we do want people that get work done in small teams at Redgate, we're also more mature. Allowing developers to work on whatever they want isn't in our best interest, and it could mean some products wouldn't get any attention. We also have somewhat large codebases, so a person per project isn't ideal. In fact, we often get code done in groups.

I think I might be more inclined to adapt some of these goals with a startup, and certainly in a PoC or early access/beta product. However, once clients are invested and paying, I think a little more coordination and collaboration is likely needed. Not a lot, but a little.