I think OP is describing the winning formula for a productive team, but he's attributing it primarily to the wrong factor. Shipping often increases quality if

I think OP is describing the winning formula for a productive team, but he's attributing it primarily to the wrong factor. Shipping often increases quality if you're getting good feedback from users and acting on it. But it's not a slam dunk obvious "best practice" or whatever. The end goal is to deliver the best quality software (or alternatively the most sell-able software), shipping early isn't some arbitrary metric you use to assess your engineers, it's a strategy to get your product from point A to B as quick as possible, where B is something really useful that the market wants, and A is presumably something crap that you can't sell. Because if you already have a piece of great software then your focus should be on selling it, not throwing more darts at the wall and hoping you don't knock the dart board off. Looking at the dot points, I have no doubt that all of OP's teams are successful. They're all great advice, except for the one the title and conclusion of the article are based on. Their first point is "keep the team small, all doers, no talkers". IME that already puts you way ahead of the pack. By far the easiest way to cork a startup is to hire one of everything and wait for Parkinson's law to bone you. A small team of programmers isn't the ideal setup for everything, but I bet it does well above average compared to the field (which is good, because the average startup goes down like the Hindenburg if YC's data is accurate). Outsourcing stuff that isn't core is also good advice. Half the reason big teams don't work is exponential growth of communication. If you can modularise your business so that one app/feature/whatever is tied strictly to one communication channel, then you avoid all that. Obviously it can backfire. I'm sure everyone has seen a few projects eat dust by outsourcing to the wrong people, it's not exactly an original story. I think it's good advice in general though. Aligning people's development goals with the business's goals is obvious. The further suggestion to prioritise employee's wants over the business's is interesting though. I think it's on the right track but the actual good advice is buried a layer deeper here. You should prioritise work your team wants to do, but there's a prerequisite that you probably also need a team that wants to do work that is good for the business. I think the real advice is hire people who are (or can become) mentally invested in what your business is trying to accomplish. And the easiest shortcut to that is probably to make them financially invested in it by offering equity. Align everyone's goals then trust your team completely. I think if you're already in a position where your employees don't care and have tangential goals (like a bit of resume driven development), then you probably don't have a great move to make, and blindly following OP's advice isn't likely to improve the situation much. One person per project is fantastic advice for some definition of 'project'. Big businesses and big teams hate this approach, it's all about bus factors and treating everyone like cogs that can be moved around to wherever they're needed. Most of the teams I've been on would rather everyone have a shitty basic knowledge of an entire huge codebase than have anyone be responsible for any subset of it. And IME it always devolves into one hero that tries to control everything and everyone else feels like they have no control. I've been on both sides of it countless times, and I don't think it's the best way to build software. Not by a long shot. I think the reason it happens is because good developers have an innate want for more control, to take on more power and the responsibility that comes with it. Supressing that might work for average teams that can do their job with average developers (including good ones that are brought down to the mean), but if you want to stand out from the crowd you need to build an environment where everyone can have responsibility and be a core part of the team. 'Peer management' works great. But OP's approach isn't the way to go about it. I know a handful of great developers, people who I would entrust with my business or back with my own money. One of the things they all have in common is that timed status reports designed to hold them accountable wouldn't work on them. They might put on a smile and suck it up but I can guarantee you they wouldn't actually give a fuck what anybody thought about their delivery speed unless they actually respected them as a peer. So this is another dot point with a huge pre-requisite. It's great advice as long as you already have a team that all respect each other's abilities and are all close friends who don't want to disappoint each other. And if that's the case then you don't actually have to take action as a founder or CEO. You don't need to set up weekly reminders for your staff to make promises, the accountability will have grown naturally and already be there. Good engineers are self managing. OP says that themself in the opening paragraph. So this specific advice seems a bit out of place. That leaves 'no tasks longer than one week'. I think in the context of OP's teams, this advice is crap. If you're already nailing everything above, then you have a team that will deliver results and build great software. In every project I've worked on, there has been stuff in the pipeline that would take longer than a week and be a net positive for the business. Especially if you're running a small team and have a modular workload with shared responsibility as above. There's always going to be something that, if you broke it down, would represent a big hairy mess of interrelated tasks that have a high level of complexity, affect the same parts of the code base, and require the same high level of domain knowledge. Breaking those kinds of tasks down is usually a mistake, and it's totally fine to have a team member you trust go off on a little odyssey for a fortnight or a month to deliver them. That doesn't mean they work in a silo, or you don't get kept in the loop, just that they're given space to work. In large teams these tasks are usually brute forced by breaking them down, creating jira monstrosities with every dependency thoroughly tracked, then splitting them up amongst a team of 10 people. They always, without fail, slip a couple of sprints and end up taking a month anyway, with the added bonus of tying the whole team up for that time. Nobody notices of course because we all know the correct language to use to make it sound like everything that was done was efficient and necessary and nobody really wants to suggest that whatever project management best practices are in these days might not have a 100% strike rate over the extremely varied work that goes into a complex software product. So, tldr; OP has a bunch of great advice that you should definitely follow, but I think they're off base on a couple of things.