Culture by Poster
My favourite Facebook office poster slogans and what they mean to me.
Done is better than perfect.
Don’t mistake motion for progress.
What would you do if you weren’t afraid?
It isn’t prioritisation until it hurts.
Move fast and break things.
I worked at Meta for over 12 years. Meta’s offices have a solid poster game. If you’ve ever visited one you’ll know what I mean. The walls are covered in posters bearing maxim’s to live work by.
This tradition started, the story goes, when the company approached 150 employees (Dunbar’s number). A designer, Ben Barry, realised that as the company grew, it would be harder to infect new joiners with the principles and tenets that the first employees organically shared. A screen-printing enthusiast, he made up some posters and stuck them around the office. People loved them, and this idea developed into the Analog Research Laboratory - a space that started in Facebook’s HQ, now replicated in Meta’s major offices around the world.
Now, you may sniff about “corporate propaganda” or “employee brainwashing” - but company culture is important — it helps people understand what to do and how to behave at work. As someone once said “culture is what people do when no one’s looking”.
Some of these posters didn’t resonate with me, but some really did, and often helped me at pivotal points in my career or development of a product — so I wanted to share some of my favorites with you, explain what they mean to me, and show how they might work for you.
1: “Done is better than perfect”
This is about two things: A) improvement through iteration and B) opportunity cost.
A/ Iteration
Building things is fun and safe. Shipping things is scary. When you ship, you lose control, and risk the embarrassment of your decisions and assumptions being proven wrong. As a result, there’s an intrinsic pressure to keep iterating; to try and anticipate every need and iron out every kink.
But perfection is impossible to reach. And you’re not solving anyone’s problems if the product is still in the lab. Often the best way to travel the asymptote toward “perfection” is iteration — get things into people’s hands, see how they react, and make improvements based on the feedback.
Of course this is not an invitation to ship shitty products. In fact, in the last few years at Meta, there was somewhat of a backlash against this value, with “build awesome things” being added to the company’s values in response to a perception that some teams were shipping lower quality product than leadership would have liked.
But I still believe “done is better that perfect” is a valuable frame. It’s a reminder to overcome your fear of shipping - and force you to be humble about receiving and acting on user feedback — rather than trying to chase perfection.
B/ Opportunity Cost
Recall the 80:20 rule - the idea that 80% of the value requires 20% of the work, with the last 20% of the value taking 80% of the time. Is that last bit really worth the cost? Sometimes yes (e.g. regulatory compliance or privacy where edge cases are important), but often, no. If you’re spending a ton of time on things which have limited value (the last 20%) then that’s time you’re NOT working on something else of high value.
If your job is to maximise value, you’re doing your stakeholders (customers, investors etc) a gross disservice by not calling something “done” and moving on to more impactful things. For completer-finisher types, this can be frustrating — but we’re here to have impact and create value — not make ourselves feel better.
This is similar to Steve Jobs’ “Real artists ship” or “perfection is the enemy of the good”. But I love the simplicity of “done is better than perfect”.
Takeaways:
What is actually BLOCKING you from shipping? Most of the things on your backlog are likely nice to have’s, not essentials. If so, why are you not shipping sooner? Done is better than perfect.
Are you spending your time discussing product details where the decision won’t have much impact on the user base? Is this a decision that can easily be changed later? Done is better than perfect.
Are you discussing features where there’s not a blazingly obvious user need? Done is better than perfect.
2: “Don’t mistake motion for progress”
We’re all busy, we all have a lot to do — but just because we’re doing things, doesn’t mean we’re actually making progress. There’s meetings to attend. Emails to reply to. But is this actually having impact? Does this clearly move you toward having impact?
Now meetings and emails are necessary, but they’re not sufficient for success. I used to work at an organisation where you could literally coast for 30 years just by writing emails and attending meetings. People were not being held accountable for creating business impact. There wasn’t a culture of questioning if what people were spending their time on was impactful, or clearly driving progress toward future impact.
A story:
Back in 2011-12, I spent a bit of time in developer advocacy & developer marketing. There was a lot of excitement about events. Flying around the world, going to cool places, asking developers to use our stuff. It was BUSY. We had to write presentations, build sample code, get people to attend, rehearse, and ensure everything went well.
But was it motion or progress? At the time, I remember thinking we were having impact! But our very smart manager did something unusual in the world of developer marketing: they built a data pipeline to track event attendees, and their later engagement with our products. Ideally, people who’d attended our VERY EXPENSIVE events would be more likely to adopt, and more likely to be successful with out tools.
Turns out, over many events and many months, we couldn’t see any real uplift from event attendees vs regular developers.
We thought we were measuring progress: # of events run, # of attendees — but we were actually just measuring motion - things we thought were important, but didn’t have any clear connection to business outcomes.
Sean Byrnes has written about this eloquently and persuasively. He offers a simple framework:
Activities that are internal to the business are motion. These include: Implementing new tools; Implementing new processes; Building a new report; Attending regular meetings.
Activities that affect your position in the market are progress. These include: Adding new customers; Improving customer satisfaction; Making money; Hiring new people; Layoffs.
“What was the impact?” is the single most powerful question in management. If you (or the person your questioning) can’t immediately explain the business impact — or how this thing clearly moves us toward creating business impact (progress): you have a problem.
3: “What would you do if you weren’t afraid?”
When you assess situations and make decisions, you do so with inherent biases based on your beliefs, principles, and past experiences. You can’t eliminate bias, but you can try and identify them, and control for them.
Fear is a powerful biasing factor. Most us are wired to avoid risk and maximise self-preservation. This poster is a reminder to check yourself against the intrinsic fears that are holding you back.
In a work context, these might be things like:
Giving up on a product that’s not succeeding for fear of being seen as a failure.
Fear of a big redesign because you’re worried about losing existing loyal customers — even though you know you’ve hit a limit with your current design.
Not taking a new job because you know you can succeed in your current role.
Not speaking up in a meeting because you’re worried you’ll reveal your ignorance or lose credibility.
This poster’s message is powerful because invites you to identify (like, actually write down) the things holding you back. And once you do, you’ll often you find they’re not things which should hold you back at all.
Take my list above:
There’s no prizes for continuing to invest in a dead product - so why are you still working on it? Admitting you need to change course might hurt your pride in the short term, but clearly better for everyone in the long term.
Many products have had massive redesigns and kept their customer base, you just need to think about how to help your existing folks learn the new ropes. If you don’t change you can’t grow!
People change jobs all the time. In fact, moving between companies is the best way to grow in your career because you’re exposed to so many more situations. Again, some short-term pain for long-term gain.
If you have a question in a meeting, I can guarantee other people in the room have the same question. By speaking up a) you’re gaining credibility with them, and b) you’re highlighting something that’s not clear — likely enabling the thing you’re questioning to be improved.
It’s as simple as that. It’s like an A3 therapy session: and it’s amazing how many things you can either discard, or at least identify and then start talking about with your team.
4: “It isn’t prioritisation until it hurts”
Resources are not infinite. You don’t have unlimited people, money, or time. You need to choose what do work on. Prioritisation is thus a key skill in product development - but almost universally, I find teams are unwilling or unable to prioritise hard enough.
What you often see is people doing “obvious” prioritisation — de-pri’ing a feature that’s clearly only valuable to a few customers, or marking as P3’s the things you’d like to do, eventually. Why do we do this? because it’s easy. And easy things are fun to do.
But this isn’t where you should be spending your time — you need to be up the other end of the roadmap looking at your P1’s.
If you only de-pri the easy stuff, you’ll end up with many high-pri things to do — each of which looks important and urgent — because because you’ve not had the hard, frank conversations required to really really tease out what matters most.
Prioritisation is hard because, as Steve Jobs once said, it’s about “saying no to good ideas”. This means prioritisation conversations should be hard. They should feel tense. There SHOULD be very smart people on both sides of the argument. When you make a decision to pursue X over Y — you SHOULD feel some pain, risk, or worry.
You are going to piss some people off. That’s a signal you’re doing it right, not wrong.
Things to think about:
Stack rank: As a team, ask yourself the question: if we could only do ONE of these two things, which would we do?
Sequencing: If you have two things that are clearly important — ask yourself, is one more urgent than the other? If feature A is as valuable if built next half as it is this half, but feature B is more valuable if built now, then build B before A. Remember (and say to yourself and your team!) that just because we’re down-pri’ing thing X, doesn’t mean it’s not important and we’ll never do it — it’s just less important RIGHT NOW — it may well be the most important thing next planning cycle.
One in, one out: When someone asks for “just one more thing” in the roadmap: ask them: which of these other features would they’d like you to drop? If they can’t identify one, you’ve already done your job well.
Read a more thorough exploration of this idea from the wonderful Ami Vora.
5: “Move Fast and Break Things”
This is probably the most famous; and most misunderstood.
Later iterations in included “move fast with stable infra” (awkward) or just plain “move fast”. Some people took the original framing to encourage recklessness — to operate without thought for consequences. But it never meant that to me. Let’s break it down:
A/ “Move Fast”
The ability to react quickly to new information is, I think, one of the most important predictors of successful teams. That’s because product improvements aren’t linear — they compound. A team that can ship 50 iterations a quarter is going to pull away from a team that can only ship 10.
Moving faster might seem obviously valuable, but it’s hard. Inertia is everywhere. It’s easy to stand still - keep doing what you’re doing, or wait until you have more information to reduce risk.
A story: When I joined in 2010, Facebook released code (to the web tier) weekly on a Tuesday (with smaller pushes for bug fixes on other days). In 2017 they moved to continuously deployment. Once an engineer committed a diff, it was going to production in 5 hours or less whether they liked it or not! The company grew more than 50x in terms of employees over that time. Normally things slow down as companies get bigger. At Meta, they sped up.
Now, this increase in speed wasn’t accidental - it was intentful, It took WORK. A lot of work. And created risk — potentially making it more likely for a bug to takedown one of the worlds largest communication platforms on whom billions of people relied.
So why did the company invest in reducing commit-to-production latency? Because speed enables success. It enabled the company to better serve it’s customers. Teams could react to changes in user behaviour within the day! When bugs were found, they could be fixed within the day! It enabled teams to launch orders of magnitude more experiment variations than they otherwise would have. The benefits of speed compound.
B/ “Break Things”
Some people have read this as “cause disruption without thought for the consequences” - but to me this means something more subtle: have a healthy disrespect for the status quo, and a willingness to question why things are they way they are.
Progress comes by changing things: seizing an opportunity that didn’t exist before. But changing things often means “breaking things” — that doesn’t mean laws, or regulations - but it might mean established user behaviours or business practices.
Some things are the way they are because that is, indeed, the optimum. Other things are the way they are because they were designed in the past with different constraints (e.g. technical, financial). This poster reminds us to question which is which.
A story:
Before 2006, the home page of Facebook was your own profile. In 2006, they developed News Feed - a stream of updates which saved you from having to visit each friends’ profiles individually. Testing showed this was dramatically more engaging. People who had Feed spent more time on site and engaged more deeply, which benefited everyone through the network effects. Yet upon the launch, there was uproar: “how dare you change my Facebook” and “bring back the old Facebook” etc. The team could have backed down, reverted to the old design — but they didn’t. They stuck with it. They heard the user feedback and implemented some changes, but they had the conviction to hold course. They lived up to the poster on the wall.
Today, we can’t imagine a world where the default view of a social app isn’t some kind of feed. Facebook, Instagram, TikTok, heck even LinkedIn.
Break things doesn’t mean “be reckless” and it certainly doesn’t mean “break any laws” but it, to me, does mean: have confidence to push for something you believe is better, even when lots of people might be telling you its’s not.
There’s a lot more posters where those came from, but these are the ones that have stuck with me.
What other posters have you seen that have impacted how you approach your craft?
A wonderful summary and trip down Memory Lane - thank you Simon.
These messages all really resonated. Great article, thanks!