
Build a Team that Ships (2012) - saadalem
https://nav.al/build-a-team-that-ships
======
ChrisMarshallNY
I’ve been shipping for more than thirty years. Twenty-five of them, as a
manager.

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/evolutionary-design-
specification/)

[https://littlegreenviper.com/miscellany/forensic-design-
docu...](https://littlegreenviper.com/miscellany/forensic-design-
documentation/)

[https://littlegreenviper.com/miscellany/thats-not-what-
ships...](https://littlegreenviper.com/miscellany/thats-not-what-ships-are-
built-for/)

~~~
throwaway_pdp09
Edit: skip this. I've read your links and it's clear you wouldn't fall into
this trap. Sorry.

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?

~~~
ChrisMarshallNY
It’s cool.

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.

~~~
still_grokking
>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.

~~~
ChrisMarshallNY
This is what I do: [https://littlegreenviper.com/miscellany/forensic-design-
docu...](https://littlegreenviper.com/miscellany/forensic-design-
documentation/)

I call the upfront spec my "Napkin Sketch." It's often a single diagram.

------
Tade0
Sounds eerily familiar, especially "People choose what to work on.".

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.

~~~
foreigner
"making good money" is the goal of a company.

~~~
echelon
Humans locally minimize entropy, sometimes in exchange for fulfilling an
objective function or following some optimization gradient (profit).

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

------
zck
Where are the companies that try to make their employees better? As someone
who is an employed software developer, but has never been confused for a
rockstar coding ninja, things like this hit me emotionally when I read them.

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?

~~~
icelancer
My company does this, but our pay is somewhat under market rate - our
developers make not much compared to what is bandied about here. But then
again, I run a company in a desirable field, the rules are pretty lax, and we
invest a ton of money in employees.

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.

~~~
wolfgke
> 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.

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.

~~~
icelancer
>> 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.

------
rdegges
I've worked on several teams, but mostly solo in my programming career. I can
tell you without hesitation that the times I felt the "best" were when I was
shipping things every single day.

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.

------
29athrowaway
You can compare this philosophy to "Publish or Perish" in academia.
Universities tell scholars if you don't "ship" (publish frequently, get
citations), we fire you.

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

[https://youtu.be/XXBxV6-zamM?t=4072](https://youtu.be/XXBxV6-zamM?t=4072)

~~~
rusticpenn
Most of these problems can be curbed by pproper oversight and exception
handling, however i also find that techniques based on empathy and trust tend
to help longterm.

~~~
29athrowaway
So there are aspects of development that rank higher than shipping, right?

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.

------
PeterStuer
"All doers, no talkers"

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

~~~
BigJono
I assume 'talkers' means people that _only_ talk. OP isn't making a case for
or against planning, just saying that if you're taking a small team approach,
once the planning is sufficient, the people who do the planning also have to
jump in and produce. Your 'small team' can't be one programmer with a team of
BAs, POs and designers looking over their shoulder for 40 hours a week.

~~~
lucideer
This obviously doesn't apply across the board (but what does), but in my
experience, on engineering teams I've been on, so-called & self-proclaimed
"doers" are only doers of highly visible work, whereas the "talkers" are the
real behind-the-scenes doers.

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.

~~~
varjag
There's always more people willing to tell you what to code than the people
who can code. You are not mentoring anything if you can't step in and do the
job yourself.

~~~
watwut
I would point out he described people who do the most uncomfortable work on
the project and therefore also talk to other people.

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.

------
kitd
My coding career started in 1987. For the last 3 years, and for the first time
in my career, I've been working on a product that has a team of professional
designers, ie proper graphic designers, artists, "empathetic" people, etc.

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.

------
zabil
> You have to ship something into live production every week – worst case, two
> weeks. If you just joined, ship something.

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.

~~~
adenverd
This is one the most important jobs of product managers, if you have them:
building out a backlog of shovel-ready high ROI work aggregated from customer
requests, user analytics, and strategic engineering efforts.

If PM is doing their job well, engineers can build and ship multiple times
within a sprint without significant delays waiting to gather feedback.

------
Antoninus
I work on a team that functions this way. We're pretty productive for a team
of 4 doing 100 story points a week. We usually deploy a day or two after our 1
week sprint ends.

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.

~~~
syntactic_sugar
I also feel that being disgusted by editors and terminals at the end of the
day is a really strong sign of something off. I can say that in some jobs I
would study / do personal stuff at night, in some others I just wanted to
drink after leaving the office.

------
helsinkiandrew
Half baked and complex are hardly descriptions that endorse their process:

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

~~~
7777fps
> 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?

------
motohagiography
"Peer-management. Promise what you’ll do in the coming week on internal
Yammer. Deliver – or publicly break your promise – next week."

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.

------
fermienrico
What constitute “shipping” exactly? “Just ship more” is as ambiguous as “be a
better driver”. It doesn’t tell you much about the quality of code, amount of
tech debt they’re creating while shipping frantically and generally not taking
the time for careful design. Software should be designed like they do
mechanical engineering - you get a few prototyping shots at it but it’s
expensive to iterate too many times - prototypes cost a few thousand dollars
depending on the complicity of whatever you’re designing. So spend the energy
and focus into designing robust code that isn’t gonna fall apart in 6 months.
Stop chasing after “shipping” madness. Instead of shipping, perhaps ask for a
solid chunk of the equity. Don’t do cheap labor for small startups unless
you’re handsomely paid for the appropriate risk involved in your career.

~~~
sub7
This is 100% true for later stage companies with established
products/stakeholders and 100% false for early stage startups.

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.

------
ram_rar
I was on the ship ship ship, bandwagon for a long time. Until, I realized
there is a technical debt that you eventually need to pay down the road. Its
like playing tetris. There are only soo many blocks you can place at will.
Eventually, it catches up with you and game over!!!

------
tylerrobinson
I'm going to take a stab at responding to this, to see whether it's the
insufferable tone of the writing that bothers me, or something else.

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.

~~~
tyre
Yes.

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.

~~~
BigJono
I wonder how many CEOs have said something like this just before a "bunch of
hackers" has eaten their lunch and decimated their stock price?

------
IAmNotAFix
"When a measure becomes a target, it ceases to be a good measure." (Goodhart's
law)

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.

------
carlsborg
> Absolutely no middle managers. All BD via APIs.

What does BD refer to here and how do APIs eliminate middle managers?

~~~
ttymck
Assumed business development.

------
agentultra
What works/worked for AngelList isn't going to work for your team necessarily.

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.

------
woutr_be
How does one go about improving this in a big corporate company? Our
development team is focussed on shipping, but most of our delays come from the
business changing their mind and changing requirements constantly.

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.

------
pjc50
I was trying to work out who the author(s) were, and whether this was the kind
of content-marketing blogspam that doesn't belong on HN. But it's pretty
anonymous. Their twitter account retweets Scott Adams and seems to be on the
"unlockdown young people to keep the economy moving" viewpoint. Some data
points for your bayesian filter.

~~~
scribu
It’s Naval Ravikant:

[https://en.m.wikipedia.org/wiki/Naval_Ravikant](https://en.m.wikipedia.org/wiki/Naval_Ravikant)

------
ashtonkem
> People choose what to work on. Better they ship what they want than not ship
> what you want.

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.

~~~
lotyrin
I think there's (at least theoretically), the idea that folks could flock like
birds or fish in a shoal and all make independent motions based on observation
of others with no heirarchical orders and self-organize into a coherent mass
which is efficiently moving in the same direction, but I haven't seen it arise
in practice so far.

------
cirkut
Over-simplification, mentally convenient; however, won't go far in the real
world. Some good point though to narrow-minded. Read more man.

------
demarq
Wait what here is the advantage again?

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

