11 ms·

Build a Team that Ships (2012)

173 points by saadalem 7y ago

rdegges 7y ago
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.
tylerrobinson 7y ago
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.
- alexmingoia 7y ago
  The author is the founder of AngelList which isn’t a business. Business as in delivers goods and services in exchange for money. AngelList is to angel investors what HN is to YC.
- tyre 7y ago
  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 7y ago
    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?
- rusticpenn 7y ago
  This might apply to B2C products where being first to market plays a vital role. Buggy Android being first to market as an alternative to IPhone, gave it a huge boost against the polished windows phone. After reaching this target, the company would need developers with completely different skillsets, whose importance is seldom written about.
- jiveturkey 7y ago
  i'm 51% confident this article is pure sarcasm
zck 7y ago
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?
- itsrajju 7y ago
  Well it's good that it's up on the internet. Gives you and me data on which companies to avoid.
  - zck 7y ago
    Ha, it does. Though, I meant "I don't know if it's smart to admit publicly that I'm not a Linus Torvalds-level programmer".
    - icelancer 7y ago
      Very few companies want employees who think they're as good as Linus. No companies should want that, but they gotta learn the hard way...
- akdas 7y ago
  A lot of the big tech companies actually have processes around mentorship. It's one of the reasons I think working at a big tech company can be more valuable than at a small startup, especially early on in one's career. 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...
ChrisMarshallNY 7y ago
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-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... https://littlegreenviper.com/miscellany/forensic-design-documentation/ https://littlegreenviper.com/miscellany/forensic-design-docu... https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...
- throwaway_pdp09 7y ago
  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?
  - rutthenut 7y ago
    A problem I've seen a lot of too. In this case, the definition of 'done' is totally leaving out all that technical debt. Hence 'something' has been shipped, but the work has most definitely not been 'done'. Just giving an appearance of done, sweeping other stuff under the carpet. It gets expensive doing that. And gives a very lumpy carpet!
Antoninus 7y ago
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 7y ago
  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.
- ace32229 7y ago
  That would kill me in a short amount of time. Is this a permanent state of affairs?
woutr_be 7y ago
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.
helsinkiandrew 7y ago
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.
- BerislavLopac 7y ago
  "Being complex" is not the same thing as "being complicated".
- 7777fps 7y ago
  > 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?
29athrowaway 7y ago
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 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - 29athrowaway 7y ago
kitd 7y ago
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.
carlsborg 7y ago
> Absolutely no middle managers. All BD via APIs. What does BD refer to here and how do APIs eliminate middle managers?
- poooogles 7y ago
  Behaviour driven?
- ttymck 7y ago
  Assumed business development.
Tade0 7y ago
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.
- arethuza 7y ago
  "who shipped the most" And how do you measure that - LoC, tickets, elapsed time, amount of time talking about it, executive weighting....
  - CodeBeater 7y ago
    Perception by management
    - iovrthoughtthis 7y ago
      You’re both right
- foreigner 7y ago
  "making good money" is the goal of a company.
  - echelon 7y ago
    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.)
fermienrico 7y ago
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 7y ago
  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.
BigJono 7y ago
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.
pjc50 7y ago
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 7y ago
  It’s Naval Ravikant: https://en.m.wikipedia.org/wiki/Naval_Ravikant https://en.m.wikipedia.org/wiki/Naval_Ravikant
- yCombLinks 7y ago
  He's a successful startup founder (100's of millions networth). Not some clown.
PeterStuer 7y ago
"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 7y ago
  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 7y ago
    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 7y ago
ashtonkem 7y ago
> 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 7y ago
  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 7y ago
Over-simplification, mentally convenient; however, won't go far in the real world. Some good point though to narrow-minded. Read more man.
demarq 7y ago
Wait what here is the advantage again?
motohagiography 7y ago
"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.
agentultra 7y ago
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.
IAmNotAFix 7y ago
"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.
zabil 7y ago
> 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 7y ago
  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.
ram_rar 7y ago
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!!!

173 points by saadalem 7y ago

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.

tylerrobinson 7y ago

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.

alexmingoia 7y ago
The author is the founder of AngelList which isn’t a business. Business as in delivers goods and services in exchange for money. AngelList is to angel investors what HN is to YC.
tyre 7y ago
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 7y ago
  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?
rusticpenn 7y ago
This might apply to B2C products where being first to market plays a vital role. Buggy Android being first to market as an alternative to IPhone, gave it a huge boost against the polished windows phone. After reaching this target, the company would need developers with completely different skillsets, whose importance is seldom written about.
jiveturkey 7y ago
i'm 51% confident this article is pure sarcasm

zck 7y ago

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?

itsrajju 7y ago
Well it's good that it's up on the internet. Gives you and me data on which companies to avoid.
- zck 7y ago
  Ha, it does. Though, I meant "I don't know if it's smart to admit publicly that I'm not a Linus Torvalds-level programmer".
  - icelancer 7y ago
    Very few companies want employees who think they're as good as Linus. No companies should want that, but they gotta learn the hard way...
akdas 7y ago
A lot of the big tech companies actually have processes around mentorship. It's one of the reasons I think working at a big tech company can be more valuable than at a small startup, especially early on in one's career. 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...

ChrisMarshallNY 7y ago

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-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... https://littlegreenviper.com/miscellany/forensic-design-documentation/ https://littlegreenviper.com/miscellany/forensic-design-docu... https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...

throwaway_pdp09 7y ago
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?
- rutthenut 7y ago
  A problem I've seen a lot of too. In this case, the definition of 'done' is totally leaving out all that technical debt. Hence 'something' has been shipped, but the work has most definitely not been 'done'. Just giving an appearance of done, sweeping other stuff under the carpet. It gets expensive doing that. And gives a very lumpy carpet!

Antoninus 7y ago

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 7y ago
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.
ace32229 7y ago
That would kill me in a short amount of time. Is this a permanent state of affairs?

woutr_be 7y ago

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.

helsinkiandrew 7y ago

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.

BerislavLopac 7y ago
"Being complex" is not the same thing as "being complicated".
7777fps 7y ago
> 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?

29athrowaway 7y ago

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 7y ago
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.
- deleted 7y ago
  [deleted]
- 29athrowaway 7y ago

kitd 7y ago

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.

carlsborg 7y ago

> Absolutely no middle managers. All BD via APIs. What does BD refer to here and how do APIs eliminate middle managers?

poooogles 7y ago
Behaviour driven?
ttymck 7y ago
Assumed business development.

Tade0 7y ago

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.

arethuza 7y ago
"who shipped the most" And how do you measure that - LoC, tickets, elapsed time, amount of time talking about it, executive weighting....
- CodeBeater 7y ago
  Perception by management
  - iovrthoughtthis 7y ago
    You’re both right
foreigner 7y ago
"making good money" is the goal of a company.
- echelon 7y ago
  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.)

fermienrico 7y ago

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

BigJono 7y ago

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.

pjc50 7y ago

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 7y ago
It’s Naval Ravikant: https://en.m.wikipedia.org/wiki/Naval_Ravikant https://en.m.wikipedia.org/wiki/Naval_Ravikant
yCombLinks 7y ago
He's a successful startup founder (100's of millions networth). Not some clown.

PeterStuer 7y ago

"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 7y ago
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 7y ago
  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 7y ago

ashtonkem 7y ago

> 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 7y ago
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 7y ago

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

demarq 7y ago

Wait what here is the advantage again?

motohagiography 7y ago

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

agentultra 7y ago

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.

IAmNotAFix 7y ago

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

zabil 7y ago

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

ram_rar 7y ago

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