Build a Team that Ships (2012)
nav.al
nav.al
Not everything has been a success, and I was not the “big boss,” during most of that time, so I often had to work in far-from-perfect systems.
The one thing that has been a constant drumbeat, throughout my entire career, was a relentless focus on “Done.”
“What does ‘Done’ look like?” Is a question I’m constantly asking myself. It can change, as the project progresses, but it’s always there.
I tend to start vague, with “Done” being almost abstract, and get sharper and more focused, as the project coalesces around an end-user deliverable.
As I said, I have had many less-than-stellar outcomes, but I’ve always delivered an end product.
The best ones have been the ones with the least planning up front. Not always the most ambitious ones, but the best ones.
I’ve learned to adopt an “organic” project process, based on the assumption that it’s impossible to know the end result when I start.
I write about that in these articles:
https://littlegreenviper.com/miscellany/evolutionary-design-...
https://littlegreenviper.com/miscellany/forensic-design-docu...
https://littlegreenviper.com/miscellany/thats-not-what-ships...
At least in the software world, I'd say an abandoned project is done. Good enough to ship is something else entirely.
> I’ve learned to adopt an “organic” project process, based on the assumption that it’s impossible to know the end result when I start.
For some things you do want to spend a bit more time planning up ahead, as some decisions can be hard to undo later.
But I think one should definitely try to make code pieces as modular as possible, and as easy to change as possible. As you say, the final product will likely not be as one imagines at the start. Especially since customers seldom know exactly what they want.
So many times I can whip up new features in short order, because I spent some time up ahead making small reusable modules out of functionality, so it's easy to use from elsewhere.
Absolutely. That's the key. Modules and layers; each with its own project identity and lifecycle. loose-coupling, minimal APIs, and reevaluation phases at the completion of every module.
If you do this right, projects can be almost "Lego" simple, with the ability to rapidly reconfigure to adapt to changing requirements.
Here's an example. Yesterday, I was working on a "UUID scrubber" for the Bluetooth project I was working on (https://github.com/RiftValleySoftware/BlueVanClef). I started by having a private class function to do the scrubbing, but realized that this would be something that could be useful for any similar project, so I broke it off, and added it to my toolbox project (https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...). That meant that I also had to write a unit test for it, and then update my Carthage include.
Took, like fifteen minutes, and I now have a permanent tool for scrubbing UUIDs.
Another habit that I developed, was making every project I do, including "one-off" experimental projects, "ship quality."
I simply cannot put too much stress on the need for maximum quality. As a lone developer, I just cannot afford bugs. It's imperative to do it right the first time.
The general argument against a high-quality process is that it is inefficient and slow.
Unless you make it a habit.
"We are what we repeatedly do. Excellence, then, is not an act, but a habit."
-Aristotle (Probably, but these attributions should always be taken with a grain of salt)
I am the big boss of our 12 person company but I still cannot ever get to a perfect system. Yes in theory, I can make all the decisions and impose BUT it is far from it. The challenges of building a perfect system is not only related to how much power you have (yes it helps) but many other factors.
I worked for a Japanese company for most of my career.
It was...challenging.
HUGE team of very, very capable engineers (I regularly worked with some of the finest scientists and engineers in the world), but hidebound like you wouldn't believe.
I quickly learned never to use the word "agile" when talking to my bosses. Frowny faces appeared everywhere. They considered it a "low quality" process.
The main issue, is that I was talking to top-shelf engineers and managers, who had been delivering top-quality products for 100 years. This was not trying to convince impressionable American VCs or play "buzzword bingo." These folks knew how to do something, and they had been having success for generations.
It's just that what worked so well for hardware, went pear-shaped with software, and I was never able to successfully convince them of that.
That made me very sad, as I think that they really lost a lot of benefit, because they couldn't pivot into modern software engineering. I loved that company, and I have tremendous respect for my peers in Tokyo.
Since leaving that company, I have been working on my own, and implementing the ideas that I cultivated while working there.
It's been fairly effective.
Those cranky bastards had one thing right, though. The software industry has a shockingly high tolerance for crap. It's a real challenge to try to advocate for doing quality work.
99.999…% of all software is utter crap. If people would build houses like they build software we would generally all live in paper boxes glued together by duct tape. And those paper boxes would explode on a regular basis for unknown reasons…
Still you will hear most people in this business saying: "That's fine". Look, "it works".
I don't think this will ever change. One of the reasons this won't change (besides development costs of course) is imho the overall mindset that "bugs are unavoidable, any software has bugs". As long as it's a "natural" thing to deliver buggy crap, and people declare you outright crazy if you even mention that there's something quite wrong there, no chance that this will change (at least not until software will be produced mostly by machines).
One reason is that I keep my scope fairly humble, so it can be argued that software that doesn't do that much doesn't have room for bugs.
But I like to avoid dependencies, if at all possible, and have a number of habitual practices in my coding that I think result in exceptional quality.
Problem is, it's not valued at all. I'm in a semi-retired status, and have found that no one wants decent quality.
It's been rather depressing, TBH.
One of the open-source systems I designed is becoming a worldwide infrastructure, and they have more bugs than ever (I don't code it anymore), and that means they have maybe 20 issues, in all; across about 50 subprojects. When I was doing it, it was a single-digit count, but only about five projects.
It's still of remarkably high quality. The folks who took over are good, and follow good practices. Also, the substrate is very strong.
I had a boss who relentlessly focused on getting things done, neglecting anything but the immediate cost. If the cost could be pushed into the future (well, that wasn't the calculation - it was more like 'can I ignore this right now') then it was. He built up a whole lot of technical debt that was expensive to deal with, and some never was dealt with, so continued costing permanently. Any thoughts?
Tech debt is a HUGE deal. Since I work alone (for the most part) these days, it’s an absolute killer.
I can’t afford it at all.
The single biggest guarantor of a massive debt (IMNSHO) is a rigid up-front specification.
Or the lack of any meaningful upfront planing.
This goes in both ways. But I agree of course with the above. Detailed specs, especially done in some ivory tower, will cause massive problems, no question.
I call the upfront spec my "Napkin Sketch." It's often a single diagram.
It's kind of sad, though. What you said above ("I’ve learned to adopt an 'organic' project process, based on the assumption that it’s impossible to know the end result when I start.") is literally what Agile was trying to convey when it started out.
My experience is that things go pear-shaped when those pesky "people" get involved. It's all great on paper, and in the theoretical perfect world, but as soon as people start getting involved, and developing their own mental models, it can cause problems.
A big factor, as well (IMNSHO), is that a lot of folks decided that they wanted to be "gatekeepers" of the methodology, so they started to formalize it, and develop a vocabulary that they "own."
That happens with pretty much everything.
I'm old, grumpy, and very experienced. A great deal of the programming that I do is "instinctual." I don't stop and say "This would be a great place for OBSERVER!". I just go ahead and set up a subscription management utility, and don't give a damn what it's called.
In my experience, every time we come to a "new paradigm," a great deal of it is really just a formalization or rebranding of concepts that have been around for years.
True IME. Any time I see the word Agile, I now consider it to mean Clusterfuck In Progress.
You can't have that for the whole team in the real world. There are tasks which are universally unpleasant. Usually this devolves into one guy (the one who "ships" the most so is favoured by management) picking the best, most "shippable" tasks and the rest getting what's left.
That's because what this philosophy does is it turns what was supposed to be teamwork into some kind of weird competition over who shipped the most.
And contrary to popular belief when people compete instead of working together the outcome is usually worse.
I know one company that implements very similar rules and while they do make good money, they ship unmaintainable crap. Fortunately for them there's a niche for that as well.
I understand what this is like, and it sucks. Everyone else is left picking up the broken pieces of what the "superhero" built.
There isn't an easy answer here, but incentivizing speed of iteration (aka shipping) has several benefits, both to getting value to customers as well as to architecture and maintainability of the code.
I have been involved in paying off many kinds of tech debt, and I see a lot of people scream maintainability and then realize the problem that the horrible thing solves is itself a horrible problem.
If you can fix it, fix it, if you think its going to take months to years of work to fix it to be maintainable the truth is likely you never will.
Any product that is static long enough for you to do this is probably not making enough money to justify the cost of doing that kind of refactor except as a hobby project (or was really well designed in the first place, or is a literal hellscape you should let die.)
1. People rushing out crap code and not taking responsibility for cleaning their mess.
2. People trying to clean up code, but doing a poor job for various reasons. (Incompetence, lacking sufficient domain-knowledge at the start, bogged down by organizational problems, etc.)
The problem in each case is people either lacking the capability or desire to do excellent work. "Ship fast or write decent quality code" is a false dichotomy.
And how do you measure that - LoC, tickets, elapsed time, amount of time talking about it, executive weighting....
If individuals choose what to work on, then individuals have to be responsible for owning the things they've built. Doing support, doing maintenance, being accountable for problems. If you let people cherry-pick the fun bits and then leave the crap to someone else, then you're doomed, as you say.
I work on a team like this. It's pretty weird, having come from classical XP teams where the team as a whole makes decisions and owns the code collectively. I don't think it's better. But it does work.
We had a classic "glasses salesman" story going on here.
The story goes like this: there was a store that sold prescription glasses which had a few salespeople.
One was consistently better than all the others, so management took note and wanted him to teach the others.
Turns out that what he did was to observe people coming to the store and only approach those who looked rich, going as far as distracting the other salespeople so that they wouldn't get a chance.
That's the pattern.
It's nice when it works out and we leave things behind in better conditions than we found them, but that's not what the universe is playing at. Nor is it necessarily a/the goal.
It's weird how this all works, and how short a time we have to affect it. It would be nice if everything we made was good and worthwhile, but it's hard to know where things are even going to wind up, and if our investments in making certain things better will pay off. You have to consider opportunity cost when making improvements.
(This pandemic is really screwing up my sleep schedule.)
The relationship between what engineers want and making money is less strong than most would care to admit, for example.
I for one voted with my feet, because I judged this particular approach to be shortsighted.
This might not be the smartest thing to put onto the internet, but I'm not someone who comes in guns a-blazing and ships dozens of features my first week. Or do I ever get to a high velocity. Would I like to? Sure. But that's not where I am at now.
So, a lot of companies talk like this. I suspect this is like baseball before Moneyball -- what if you can get people who are undervalued and make them better? What companies are doing that? Or even, how does one do that on their own?
I don't mean to suggest all startups forgo mentorship, but often, smaller startups simply don't have processes in place for most things, including mentorship. And of course, what you get mentored on depends on the company too: at a big company, the focus may be on growing your career, whereas the mentorship at a smaller company may be about navigating an uncertain product roadmap.
Unfortunately, getting into a big tech company (especially when not doing so right out of a well-known college) requires a lot of luck, so getting access to this mentorship isn't exactly easy...
Nobody does. We have a running joke at our company of avoiding anyone who thinks they’re going to accomplish anything meaningful in the first month. Unless your company is totally mismanaged (ours is not), there won’t be the low-hanging fruit around that they think will be.
You might find the inverse relationship, unfortunately. High salaries often come with high expectations and low time to develop employees because of your high salary. That's been my experience, and I've worked for a fair number of large and small tech firms.
Small companies had little onboarding process, little to no training budget, and everything had be deployed yesterday. Plus a lower salary.
Large companies had formal onboarding, training budgets which they encouraged you to use, and didn't mind spending more time get the thing right before releasing and a higher salary.
This hasn't been true most other places I've done contracting work for, or heard from friends who are full-timers.
It probably just runs the gamut depending on personal experiences. I guess my point is that it's hard to find a really high salary and expect to be trained up, and that seems logical enough to me.
The strangest thing I've noticed about my experience in the tech industry is the utter and complete disconnect between salary and expectations. I've worked for a wide gamut of firms, from startups with single-digit numbers of engineers to FAANG companies with thousands of engineers. I have never noticed a clear correlation between salary and expectations.
The job where I was under the most pressure and where I had the most asked of me was actually my lowest paid position. I graduated in 2009, on the tail end of the financial crisis, and I counted myself fortunate to find a job at a local firm that was hiring. This was in the Midwest, so I counted myself fortunate to have a job offer at all, regardless of the salary. I very quickly found out why that firm was perpetually hiring. The work environment was so high pressure (and the wages so far below market rate, even during the recession) that people would leave as soon as they could find an opportunity (any opportunity) elsewhere. I held out for about 8 months before finding another role that paid significantly more and had significantly less expectations around how fast I would ship.
This is surely correct. I just ask myself whether this is just a very different formulation of what zck wrote:
> I suspect this is like baseball before Moneyball -- what if you can get people who are undervalued and make them better?
If we identify "undervalued" with "salary below market rate", one obtains the statement above: By moneyballing, look for great developers who are paid below market rate (and will thus accept a salary far below the one of "rockstar developers") and hire them.
Yeah, I don't disagree with this at all. My software architect was writing JCL COBOL full-time before he took this job and has a degree in Computer Science from a no-name private school. He knew nothing of our tech stack, but he was a hard worker and a good culture fit, so I hired him and gave him two months (EDIT: on salary) to teach himself - bought him all the courses, books, and such he could stand. Within 3 weeks he was pushing to our repo.
This is very close to what I was thinking, but there's a slight difference. I was thinking less about people who are _underpaid_ relative to how well they are performing, and more about people who are _underperforming_ relative to how well they could be.
I imagine this to be the most powerful kind of sports scouting -- you look for the people who could do well in the majors, no matter how well they're doing now. It's trivial to say "LeBron James would be a good #1 pick"; it's harder to recognize people like Kurt Warner (https://en.wikipedia.org/wiki/Kurt_Warner), an NFL quarterback who went undrafted, but was inducted into the NFL Hall of Fame. I'm talking about people who have more potential than they're showing.
You don't need to fit in everywhere, different places work in different ways.
There were a few jobs I had where I'd work on a project for what seemed like an endless amount of time and almost never saw any sort of real-world feedback--it was sad and demotivating.
I definitely agree that if you want results, keep your team small, have everyone ship things, and be personally responsible. It's highly motivating and from what I've experienced, draws out the best in people.
In that system, quantity is more important than quality. It's about pointless journals, conferences and citation rings, rather than actual research. "Publish or Perish" is about institutions trying to inflate their ranking, rather than fulfilling their original purpose: advance the frontiers of human knowledge.
Another example: When IBM projects paid engineers based on "kilos", or thousands of lines of code added, what was the result? millions of lines of pointless, redundant code. Bloated software that doesn't work and is impossible to maintain.
Another example: Stacked ranking/Vitality curve. The idea is simple: you evaluate each employee, producing a score. Then you rank all employees within a team. The lowest scoring 10% gets fired. Repeat every year... result? teams hire the worst employees they can, because that improves their chance of surviving the next stacked ranking iteration. Repeat for many years and you obtain an incompetent organization incapable of doing anything, full of toxic people.
If you use sprint velocity as your most important metric, the result will be a lot of redundant actions followed by corrective actions to undo those actions. It looks like a lot is getting done, but that's the same as saying that a truck driver driving in circles is productive based purely on fuel utilization, when in reality the guy is not going anywhere.
A perverse incentive, that's what it is. Want to have 0% crime rate? Have a population of zero, problem solved. Want to end elephant poaching? Kill all elephants, problem solved.
What is important is not only when you ship, but what you ship, and how you ship it. Don't upset your customers in the process of releasing changes. And keep the vital aspects of your product working...
That invalidates the "shipping is #1" credo. Sustained and sustainable growth is #1.
Accountability is important, but being forced to ship a broken release is irrational.
Some of the absolute worst teams I have been on were like that. Full of self-proclaimed "doers". Always doing things without thinking even the basics through, no coordination whatsoever. Creating complete shitshows and clown-fiestas that others then have to fix somehow and always, always (did I say always already?) with the dumb excuse "well, at least I did something".
These are the "net negatives" on your projects.
P.S. And no, "be smart gets things done" people do not refer to themselves as "doers".
1. Overzealous ActionJockeys, who would just do shit - bothered only about local maxima ("I did mine! His thing is not yet done!" or "My code is superb; others' is total poop") Few variants are BrilliantJerk, who is supersmart but nobody wants to work with him. Also on same lines are some appreciation junkies and hero-role-playing characters , who always want to "save the day" - the LastMinuteHero types; but they'll never ever train others to hold their own as that could pose a peril to their heroism.
2. Dr AnalysisParalysis and his gang of bikeshedders. Could spend a week to choose the color of a button and while doing so earn a PhD in color theory.
3. Clueless Jimmy who just does what the leads ask him to do. He's a sure shot follower (in the lead-follow-or-get-outta-way kind) who just does NOT want to know the big picture.
4. Albatross managers. They come, they scream, they poop and fly away. Caw-caw caw Ca-caw!
5. IndifferentManagement - Anything goes as long as money comes in timely.
"All doers, no talkers" is just absolute peak Silicon Valley - may be the does should talk often and properly, to do things well. And do it well.
Collaboration over competition - it's 2020 FFS!
One approach is building a team that actively prohibits bad characters (like those listed above) and empower them by treating them like adults, and things would just work? But very few would do it - cause "the SV prophets said otherwise! "
Keen observers will have noticed that something is missing....
They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt. is (and that they'll be stuck doing it) and they want to talk/plan out/advise people on the least burdensome options.
They invisibly help/mentor the self-proclaimed "doers" on the projects they've eagerly taken on without any clue as to how challenging it will end up being (the same project the "talkers" cautioned others about because their knowledge gave them some degree of foresight).
The truth is, you probably need both breeds. The "doers" for ambition and the ability to actually start something (without getting lost in months of talking/planning) and the "talkers" to insist on the limited amount of talking/planning needed and actually have the knowledge to follow through.
The "does" he described cherry pick easy, fun, highly visible work, refuse to coordinate with others, dont help with integrating other peoples parts and then take offense when people doing integration complain.
> They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt
This is literally the people who deal with consequences of bad code. If you fire on bad code and then you leave maintennance on others, you are the "armchair" one. Because you are not dealing with consequences.
They go and decide to do a rewrite by committee to ensure everything is clean now, sit in endless meetings discussing the best way to do things, end up with a product doing half the things of the old one since they make even slower progress than the pace they would go at even with massive amounts of technical debt, and because their clean solutions actually are less flexible than the old "ugly" ones. Now we have two versions of the products to maintain since we couldn't migrate everything meaning we now have more technical debt than before. The result is roughly the same as if someone just sat and churned through everything on his own, just that you now don't have a clear culprit to blame.
Good rhetorical trick, but not much more.
In practice, purely maintennace programmer is rare up to not existing. Most people do both maintennace and new projects. I have seen many people who wanted to cherry pick the best tasks, never coordinated and left after "finishing". They never even learned about issues of their decisions - because they run away as their creation was becomming hard to keep.
I don't think it's good for any individual to be an extreme with any trait. Thats how you end up with a sales team that sells the world with no regard for how it'll get done, or a developer who can crank out features with no ability to support those features, or product folk that spend hours every day with meetings full of people toiling over all the accessories that may one day need to fit inside your bike shed.
And for the first time in my career, I've looked at the product and thought "Wtf! that's a thing of beauty ". As a result I'm confident that users will actually, you know, like our product, not just tolerate it.
So, IME, having confidence in what you're producing has a material benefit on the motivation of the developers to get their end of things right too.
I've tried this. To be frank, it's the wrong incentive. All processes will start revolving around this. It gives a great rush to the head but a false sense of security.
Despite patting ourselves on the back on our great release cycle and velocity, we never had the time to listen and adapt to our users.
We changed. We now measure how quickly we respond to any kind of feedback.
If PM is doing their job well, engineers can build and ship multiple times within a sprint without significant delays waiting to gather feedback.
The down side is that I'm exhausted all the time. We don't interact much outside of reviewing PRs, questions and help regarding our domains on the project. This can be a lonely experience during the COVID WFH days. Its a difficult pace to sustain week after a week with no real days to work on personal projects. At the end of the day I'm disgusted by screens, terminals and editors. That is not a good sign.
The upside, I'm outputting the most code in my career (I came from enterprise/IGO work). I'm learning how to perform at a high-pace. There is a lot of focus on preparation: eating right, sleeping/resting correctly and spending time off-computer time breaking down problems I need to solve during my next 'shift' into sizeable, ordered chunks. All done so I can make my 8 hours productive the next day.
Committing, merging and deploying at a rapid rate feels good but I become more and more like a factory worker each week.
> It’s not perfect. We ship too many features, many half-baked. The product is complex, with many blind alleys. It’s hard to integrate non-engineers – they aren’t valued.
> But, we ship.
That in particular meant I viewed the article as a cry for help.
But it seems like all the commentary here thinks it is sincere and not an ironic piece?
This idea of commitments as value keeps coming up. It's difficult to explain to many technologists who see their value as measured in work, middle managers who see their value measured in negative time. If you just take the problem you are solving, express it functionally in terms of what goes into it, and what it will produce when it is solved, committing to that creates value for others. If you've seen Ray Dalio's "economic machine" video, commitments are are not unlike creating credit that facilitates spending, which creates growth. I get there are dodgy anti-patterns for creating fake commitments and fake credit that project managers tend to use, but a team that is creating growth doesn't need people like that.
I have found product market fit 3 times in my life. Each time was with an extraordinarily shitty, unmaintainable, low quality codebase. But those shitty codebases iterate the end product faster and the speed of iteration is all that matters when you are trying to make your worthless startup become a useful company. Once you find what your users want, 100% it will be rewritten from scratch in a scalable, robust, thoughtfully designed way anyway.
With you on the equity bit.
If we assume the author is part of a team that makes software and has users, to "ship" for him or her is another way of saying "deliver a product that our customers will find valuable enough to use" and hopefully pay for. Do the people who use this software depend on it for any important purpose, or would its failure be inconsequential?
Maybe I'm wrong with the assumption that the author wants to make a product people would pay for, since they lead with "we want a team of self-managing people who ship code." It doesn't say we want to make a business. It begs the question of Why? We ship to what end? Would it be less impressive to say, We just like to write software and want everyone to leave us alone?
Why write an article and observe that your process creates too many half-baked features but do nothing to reflect on that and reduce waste?
Why make the ridiculous claim that you don't value people who aren't programmers? What goal, if any, would such a statement help you reach? Why are we shipping so often (...customer feedback...?) if we don't care about anyone?
And of course the pithy final line.
So no, it's not just the tone that bothers me. It's the dismissive and plainly antagonistic approach to software development that says the creator is the only one with any worth.
I'd be interested to know how the author might reflect on this piece today.
After reaching this target, the company would need developers with completely different skillsets, whose importance is seldom written about.
AngelList is to angel investors what HN is to YC.
The least surprising sentence after all of that was:
> It’s hard to integrate non-engineers – they aren’t valued.
This describes a bunch of hackers, not a company.
A team that ships often is arguably doing great (because complex things that work are made out of simple things that work, and early feedback is important), but you can definitely just ship random shit and be satisfied with it if you've set your mind to ship often without regard to the proper way it should be done. Shipping often is easy, shipping often good things is hard.
What does BD refer to here and how do APIs eliminate middle managers?
Choose your culture and incentives wisely and use an approach that helps you to solve problems.
If the consequence of shipping software that has an unknown and undesired behavior could cost your customers millions of dollars an hour you should probably invest in a team that is familiar with formal methods (or some other approach to ensuring you ship the right thing). Shipping the first thing that works on your dev machine that passes a few unit tests isn't generally sufficient when property or people are on the line.
The people who act as the bridge between development and business just side with the business. Anything that goes wrong is blamed on our development team.
It’s probably just a hopeless situation and time to move on.
Among many drawbacks to this idea, it puts a hard cap on your organization size. Building large companies with hard to build products requires getting hundreds of engineers moving in the same direction, i.e. someone telling someone else what to make.
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.