This is just Amazon's "Working Backwards" methodology [1] expressed simplistically. There's also a book about written by key Amazon people. [2]
A core part of the Working Backwards idea is to start out by writing a fake press release, even for internal projects. This helps crystallize exactly what is important and what isn't, as it forces you to express your goal precisely and succinctly as well as define what it brings to the table.
As there seems to be some doubt as to whether this is a joke or not, I’d like to posit that we’re not supposed to know and that’s the point.
The author is the founder of the now-defunct YC startup RethinkDB. He learned engineering management the hard way, and he has done a lot of writing in various places that resembles this one: they’re un-nuanced bits of advice that take a strong position. I wouldn’t be surprised if the author actually stands by each of them, but he surely is well aware that this isn't mainstream “best practice” material. After all, that would be boring. We can find an endless stream of that on LinkedIn.
Personally I find it refreshing. Too much software engineering management advice is so overly nuanced and thinned down that nobody is offended but nobody learns anything either.
A lot of the author’s articles and tweets contain a way of looking at things that I hadn’t previously considered. I don’t think you need to agree with the whole thing to take whatever part out of it that resonates. And, well, they’re ultra-fast reads.
(In this particular case, I love the headline part, I think it can help us cut away stuff that seems important but isn’t. I hate the deadline part because I think arbitrary deadlines and constant crunch mode are bad. I don’t think spakhm minds that I only appreciate half of it)
> Personally I find it refreshing. Too much software engineering management advice is so overly nuanced and thinned down that nobody is offended but nobody learns anything either.
I love and bask in simplicity, but I think the reasons software engineering management advice is often overly nuanced is that it is a very complicated subject where simple approaches don't work. The number of corner cases that emerge are staggering. The most "simple" advice I would give now is that you need to know your people. Personalities and individual working styles make one strategy work great on one team and terrible on the other, and it's not as simple as the first team being good and the second one being bad.
“Limit WIP” is a well-known recommendation in agile circles. It’s great except for the situations where it doesn’t work, eg. you have multiple customers with must-do features, you have support commitments and bugs to fix, your work doesn’t cleanly divide into [team size] pieces, etc.
But particularly for small teams pre-PMF it is good directional advice, as folks seem to err on the side of trying to do too much in parallel. And even if you don’t _actually_ only work on one headline, having exec buy in for the general approach is great for focus.
> “Limit WIP” is a well-known recommendation in agile circles. It’s great except for the situations where it doesn’t work, eg. you have multiple customers with must-do features, you have support commitments and bugs to fix, your work doesn’t cleanly divide into [team size] pieces, etc.
This is exactly where you want to limit work in progress and have your management or leadership earn the big bucks by managing your multiple customers with must-do features expectations.
The way you get work to done is to focus on getting it done, not adding more work. Limited work in progress doesn't mean they can't be parallel efforts and most teams do that. It means that we figure out how much the team can do at once before it slows work delivery down and stick to that. Nothing is exact so some leeway is expected.
Kanban does have the possibility of expediting bug fixes or other work disrupting priorities, but it does mean that other work is done later and that needs to be managed by leadership with your customers and stakeholders.
As someone currently working hard on a simple MVP for my own SaaS product, this is good advice for me.
When you’re building your own thing it’s easy to get carried away and spend too much time on increasingly granular details and endless scope creep. It’s not easy to keep it lean and actually get your product launched and in front of customers quickly.
The article’s approach - which should probably not be taken too literally in some cases - gets you to keep the end goal in mind. And the end goal of software development is almost always a business goal and not a technical one. Something else that’s often easy to lose sight of as a developer.
Well this is, at least, better than Gartner Driven Development which has been observed at several startups. Whereby a startup begins to care about their placement on the Magic Quadrant, and start adding very poor imitations of features merely to get a check on a form and move their company more towards the top-right "Leaders" category.
I'm not sure why you're getting downvoted. I think the pressure to appease Gartner usually starts when companies bring in CEOs whose primary background is enterprise sales. They tend to over value magic quadrant positioning (in my view).
For enterprise sales, the Gartner MQ and Forrester Wave are pretty big deals. (As is how they talk about you in client inquiries generally.) Maybe enterprise buyers place more stock in how the big analyst firms view a vendor than they should but it's generally the reality.
It reminds me of Musk announcing that the Cybertruck would be able to traverse calm water as a small boat.
A former employee tweeted [1] shortly after that "Having worked at Tesla, I can say with some confidence that the design engineers are hearing about this requirement for the first time here".
See also: Steve Jobs' announcement that FaceTime would be an open protocol. To a large extent, both Engineering and Legal didn't think it was something they would need to do, and as such, didn't plan for it.
Let's just skip over the part of the story where VirnetX sued them for patent infringement, won the first case on appeal [1], lost a second related case regarding VPN patents [2], and then seemingly vanished into thin air.
I don't know if this works in a big organization, but as someone working on a solo project, I actually love it, and don't take it as a joke at all.
I reject the deadline part (I'm a solo dev, I do what I want when I want), but I love the idea of focusing on working on discrete functionality that I can then communicate to my small community of followers to show progress.
I think this is precisely the type of advice that's needed for large organizations. They can easily get mired in all the complexity and managing launches by headlines can (1) simply paint the vision of the future for the teams that are building, (2) simply communicate to leadership what is launching and when so they can a) not block and, better yet b) help unblock and even accelerate.
I think the real challenge is for whoever has final word on the goals to have realistic expectations. They almost never really do.
But as someone who often works solo or in a very small team, it's obvious that I need to pick the next most important thing and just work on that.
It's also clear to me that I don't want an issue tracker or even any separate place to put tasks. Because what happens is then they pile on a bunch of tasks that are lower priority which I have to keep trying to explain that I am ignoring them for now since there are higher priorities.
What I prefer is to just have a single text chat channel and a live deployment of the software that updates every few days or week. Then we decide whatever the best priority is and work on that.
Having a separate place to put issues and requests encourages indirect communication and creating backlogs that don't add business value and just stress the developers out.
> Third, the deadline effect is real. Most of the work in college happens at midnight before the project is due.
This depends a lot on what your team is like and what your long term vs short term look like.
If you've got an established product and revenue stream and can look 5 years ahead then pushing deadlines will make developers cut corners and make feature delivery a lot slower and buggier a couple of years down the line.
And if you have a motivated hardworking team (which, to be fair, isn't that common) you won't get much of an increase in pace as the deadline approaches, you'll just get more corner cutting and short termism.
Headlines are good but not a replacement for long term thinking. The devs debating how to meet the next 3 years goals is still valuable and those insights can lead to better ordering, flushing out crap that ain’t really needed and architecture in general.
For example those discussion might lead you to choose kubernetes or avoid it. I don’t think headlines alone get you there. Also things like what teams to have, what roles to hire etc.
Headlines (Aka… user story “epics”? OKR objectives?) are a good tool though.
As April Fools jokes go, this is really well done.
On one hand, this could easily be read as the musings of some overzealous, re-awakened and re-charged techbro/middle-manager who has tried and failed a few times. But this time, things are gonna be different....
But also, there's a modicum of truth in there. Only the experienced will recognize the red flags buried in the brush-away commentary.
SOS - Shiny Object Syndrome
MDD - Magpie Driven Development
HDD - Hype Driven Development
JDD - Jargon Driven Development
BWDD - BuzzWords Driven Development
HNDD - Hacker News Driven Development
RDD - Resume Driven Development
CVDD - CV Driven Development
EDD - Epoch Driven Development
PDD - Promotion Driven Development
BPDD - Blog Post Driven Development
MDD - Medium.com Driven Development
HDD - Headline Driven Development
There's definitely truth to that as the flip side. If you say something will take three years, you'll find some way to stretch it out to three years (or at least 2 1/2) even if you could have gotten something reasonable out in a year.
Many replies are so busy finding reasons to reject an entirely sound premise that they deliberately overlook "Don’t work on anything that doesn’t help you ship the headline", which clearly implies that you do work on the things which actually help ship the headline, ie: all of the "but what abouts" in the torrent of picked nits.
The number of people who are taking this seriously is startling.
Just because you lay something out simply doesnt mean youve simplified something.
Here's a simple statement:
"Do the most important work, and ignore everything else"
Do you see the problems with that statement? If not I cannot help you. If so then you probably agree with me already.
This is not an article boiling something complicated down to it's essential bits. This is just any old "focus" advice devoid of any real world details, that falls apart as soon as you try it.
Obviously a bit too simple, as if you don’t focus on at least some platform maintainability it’s all going to shit around headline 10, where each new headline release INEXPLICABLYYYYY introduces more and more bugs.
On the other hand, I love it. If you can’t work backwards from a great headline… what exactly are we building again???
Also it’s April 1 so haha, good timing if it’s one of those :p
This has to be a joke but it's also good advice if you only care about having a minimally viable product to ship by an arbitrary date. A strategy of "cut as many corners as possible and do the bare minimum" makes money in the short term and hopefully you'll exit before customers figure out that your products are garbage and stop buying them.
I don't agree with it but I can see how somebody who only cares about getting rich by any means necessary would be interested in this approach.
> Third, the deadline effect is real. Most of the work in college happens at midnight before the project is due. The industry isn’t that different. So simulating class assignments turns out to be a very effective way to ship quickly. You need a discrete chunk of work, with an arbitrary deadline2, and a binary outcome. You get this with headlines– a headline has either shipped by a given timestamp or it hasn’t.
Please no. I keep working at places where management gets this idea that all developers work better under pressure, and make arbitrary deadlines because of that. It's an awful way to work, especially for an extended period of time.
Agree. And one reason devs work better under pressure is because of analysis paralysis. Have a structure in place to minimize this and you don't need to work devs under pressure.
Want to expand on exactly why it is a nightmare? Core idea seems to be about focus: decide one thing, "work like hell" to do that thing, then move on to the next thing.
> pick an aggressive date to ship the first headline
From the way I've seen this done, the headline is too big (despite the article calling out a realistic example) and the timeline is too aggressive (not addressed at all). Maybe it's fine for a startup or small org where things can be ignored, but I've got lights to keep on and users to support, and "work like hell on this and only this" doesn't really fly, or if it's the actual expectation, is awful.
This is a joke, and the reason why is because even if you “deliver” a headline, you are unlikely to be “done”. It runs counter to the approach of incrementally shipping functionality, listening to feedback, and adjusting.
Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. This is a nightmare, because you end up working long hours on valueless work… and upset all your stakeholders by ignoring their urgent requests to deliver small fixes and enhancements to instead just do the one thing you said you would, even though it ends up being worthless.
> Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need.
I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff.
After all, look at the example headlines:
“You can now rent VMs through an API”,
“we rolled out FSD autopilot”,
“Treasury is available in India”.
Those are all goals!
"Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier. I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business.
No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high.
[1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher".
> Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need.
I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff.
[JO: I don't understand what you mean here. Are you saying the goals should all be appended with "and the customer buys it?" So, "You can now rent VMS through and API, and customers do?" In which case, wouldn't that be something that has to happen over time and cannot be delivered solely by engineering by an arbitrary date?]
After all, look at the example headlines:
“You can now rent VMs through an API”,
“we rolled out FSD autopilot”,
“Treasury is available in India”.
Those are all goals!
[JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success.
If you goal is "customer can now rent VMs through an API", my assumption is that to meet that initial goal a MVP will be delivered. My further assumption is that the MVP will not have all the features it will ultimately need to be commercially successful and so will need to be iterated on to be better than the alternatives customers have available to them. So, devoting engineering resources to the next headline and not iterating and improving the MVP would be a mistake. If you keep doing that, you end up with a bunch of half-baked marginal products, none of which is successful.]
"Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier.
[JO: I disagree. In the B2B setting at least, I've seen customers cancel because commitments to make minor enhancements for them were not honored. It is rare but it does happen. In addition, while customers rarely cite a specific bug as the reason to cancel, they often cite things like "bad UI" or "bad usability" or "lack of adoption", which IMHO is sometimes the way that customers articulate their experience and/or the results of working with a buggy product.]
I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business.
[JO: Can you tell me more about what you are thinking about here? In general, I think Microsoft is a tricky example to use, because they have something of a "natural monopoly", and unless you happen to be working at another company that also has such a natural monopoly, an example based off Microsoft may not be applicable.]
No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high.
[JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
[1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher".
[JO: On that we agree; one of my engineering colleagues used to say, if you say everything is urgent, you are letting the other person decide the priority. A good PM should run interference between such customer requests to provide useful and realistic prioritization, otherwise there is no-prioritization at all.]
> [JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success.
I agree with this (and the clarification in the paragraph just after this), but to my mind, those are different goals.
The goal of an MVP is quite different to the goal of refinement - in one you are determining if there is a market, in the other you are determining PMF via successive refinements.
Those would be different headlines, but headlines nonetheless. I see it as
H1: "You can now rent VMs through an API"
H2: "Rentable VMs available across our entire offering (not just the x2.small)"
H3: "Cost-calculator available on our RVMs"
H4: "RVM snapshot facility, first of its kind, now available"
H5: "RVMs are transferrable between regions with no loss of data"
What you clarify was not something I considered - that each new headline one is working towards is, in fact, a new product. I only considered headline-oriented work in the context of a single product.
I think working towards a headline is a bad idea if the headline is a greenfield development, but a good idea when ensuring that the product is evolving to ideally fit the demands of the market.
> [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
What systems are you thinking off? I've seen ancient tiny MSDOS-based software used well into the late 2000s in spite of poor reliability of the underlying system. I've seen long-lived ERP systems have their bugs worked around by users over a decade.
I mean, right now I consulted on a small company extremely unhappy with their accounting software (quickbooks force-moving everyone to their cloud)) dismiss any notion of using anything else because "The users already know how to use this!"
[EDIT: I only somewhat agree with your points, but I upvoted your comment anyway because the ones I agree with, I feel are good points].
> [JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success.]
I agree with this (and the clarification in the paragraph just after this), but to my mind, those are different goals.
The goal of an MVP is quite different to the goal of refinement - in one you are determining if there is a market, in the other you are determining PMF via successive refinements.
Those would be different headlines, but headlines nonetheless. I see it as H1: "You can now rent VMs through an API" H2: "Rentable VMs available across our entire offering (not just the x2.small)" H3: "Cost-calculator available on our RVMs" H4: "RVM snapshot facility, first of its kind, now available" H5: "RVMs are transferrable between regions with no loss of data"
What you clarify was not something I considered - that each new headline one is working towards is, in fact, a new product. I only considered headline-oriented work in the context of a single product.
I think working towards a headline is a bad idea if the headline is a greenfield development, but a good idea when ensuring that the product is evolving to ideally fit the demands of the market.
[JO: Yeah, that makes sense. I can see that in the context of a single product. The examples the OP provided made me think of the headlines as being more mercurial and greenfield in scope, but that was an assumption.]
> [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
What systems are you thinking off? I've seen ancient tiny MSDOS-based software used well into the late 2000s in spite of poor reliability of the underlying system. I've seen long-lived ERP systems have their bugs worked around by users over a decade.
[JO: That specific example that came to mind was a GRC system which I worked on years ago. The system was full of bugs, and a large insurance carrier wanted an enhancement. I forget just now what the specific enhancement request was. I do remember though that when I said "no", they said "Ok, then we are not renewing our subscription." I remember it vividly because I was surprised, that was the first time it had happened to me.]
I mean, right now I consulted on a small company extremely unhappy with their accounting software (quickbooks force-moving everyone to their cloud)) dismiss any notion of using anything else because "The users already know how to use this!"
[JO: Yeah, that can be a problem sometimes.]
[EDIT: I only somewhat agree with your points, but I upvoted your comment anyway because the ones I agree with, I feel are good points].
If you cannot simply articulate the actual need met by whatever you've shipped, you have failed to understand that need and probably even what you shipped.
The face of the author, if this isn’t a joke and commenters in the thread are categorically affirming it is.
Honestly, I don’t see why a variation of this wouldn’t work. It’s like a headline is a sprint goal or an epic or whatever agile artifact you choose… You can still apply good engineering practices from there on: splitting the work into smaller bills, working against a solid definition-of-done, testing rigorously, etc.
Although it's a joke, I'm reminded of "Sprint goals" from agile.
In practice, this never made sense on my previous agile team. Features were never the perfect size and divisible in such a way we could all work towards a unified goal. Plus, QA can't work until we're done.
A core part of the Working Backwards idea is to start out by writing a fake press release, even for internal projects. This helps crystallize exactly what is important and what isn't, as it forces you to express your goal precisely and succinctly as well as define what it brings to the table.
[1] https://youtu.be/aFdpBqmDpzM?si=NFM9N62VpWmRi8Jp
[2] https://www.amazon.com/Working-Backwards-Insights-Stories-Se...