A manifesto on work, waste, cost and value.

Work in progress has zero value. Ship!

• Before a task is shipped it provides zero value.
• Any work in progress is pure cost.
• Two tasks in progress adds cost, for no value.
• Only after shipping do you create value. Always ship.
• One task shipped is infinitely better than 4 tasks “almost done”.
• Ship something of value first. Then begin something new.

AI cannot develop software for you, but that's not going to stop people from trying to make it happen anyway. And that is going to turn all of the easy software development problems into hard problems.

• A computer can never be held accountable. Therefore, a computer must never make a management decision.

Programming as Theory Building

Non-trivial software changes over time. The requirements evolve, flaws need to be corrected, the world itself changes and violates assumptions we made in the past, or it just takes longer than one working session to finish. And all the while, that software is running in the real world. All of the design choices taken and not taken throughout development; all of the tradeoffs; all of the assumptions; all of the expected and unexpected situations the software encounters form a hugely complex system that includes both the software itself and the people building it. And that system is continuously changing.

To circle back to AI like ChatGPT, recall what it actually does and doesn't do. It doesn't know things. It doesn't learn, or understand, or reason about things. What it does is probabilistically generate text in response to a prompt.

You have to be willing to step into the unknown if you want to be creative.

The will to do things that haven’t been done before.

When we’re creating things that have not been done before, uncertainty is inevitable.

The willingness to stay in the question long enough for the dots to connect.

My inability to make decisions is frustrating, but it also allows me to stay in the question longer. I’m not rushing to find a quick fix but rather twisting and turning problems. I often find the need to go back and research some more. To make sure that the path I’ve decided to take is the right one. It wasn’t until I got more comfortable in my role as a designer (I wish I could say that my imposter syndrome went away, but it still surfaces in every project) that I discovered the benefit of this. When it comes to solving problems with creative solutions, we must first spend time figuring out the right problem to solve. Then make sure that the solution we propose is helping more than hurting.

It’s never too late to control your own fate

In my way of thinking, radical agency involves finding real edges: things you are willing to do that others aren’t, often because they’re annoying, unpleasant, or obscured in a cloud of aversion.

The idea of finding real edges, rather than eking out wins by grinding harder than everyone else, clicked for me when I started playing poker. Pros spent nearly as much time studying as they did playing, using solvers to seek out tiny mathematical advantages. I noticed a massive edge that was almost entirely ignored: physical reads, or tells.

Court rejection

Seek real (anonymous) feedback

Increase your surface area for luck

Assume everything is learnable

Learn to love the moat of low status

Don't work too hard!

Negative engineering is the time-consuming and sometimes frustrating work that engineers do to ensure small bugs don't take down systems.

There were no warnings or red lights, because the process simply hadn’t run in the first place. And so a new, time-consuming activity was added to the data analytics stack: manually checking the database each morning to make sure everything had functioned properly.

Negative engineering is “insurance as code”

Negative engineering is the time-consuming and sometimes frustrating work that engineers undertake to ensure the success of their primary objectives.

A new set of principles for better workflows when making digital products

“Ready for dev”

It’s safe to say that there is a natural tension between the fields of design and engineering. Traditionally, the role of design is to question, create meaning, and to argue for solutions that make for a better user experience. The role of engineering is to systematize, solve technical problems, and to argue for solutions that make for a simple, scalable, and future-proof implementation. The design process begins before we know what we want, and engineering usually happens when there is a clear notion of what is being built.

"Unfortunately, these projects often do more harm than good if the organization uses the design system as yet another initiative to centralize the decision-making process..."

1. Flatten your waterfalls
2. Make code the design product
3. Operate like an open source project
4. Increase visibility through automation
5. Plan like a farmer

​ ​ ​ Hey [FIRST NAME GOES HERE], Have you ever noticed how some people seem to get all of the press and attention even when other people have built something similar? It can be...

If you work in a 500-person company, even if you’re junior, you can gain attention by writing. You just need experience and ideas to write about, but you don't need authority or influence. Let your ideas speak for themselves.

Write about what you’re learning or strategies your team can pursue, and share it. People can comment on what’s interesting, or even disagree, but either way, you’ll increase your attention and influence.

Writing automatically elevates you from the sea of other people doing the same thing.

David shares a compilation of the best links from his newsletter Friday Finds. Read here.

A summary on how to pass the Amazon leadership principles behavioral interviews, and get a job at Amazon.

It’s somewhat shocking how often people buried in large companies don’t mentally identify their customer as the final external customer. Their customer is their boss, sales, marketing, etc. They are so focused on doing what they’re told, so focused on building what they’re asked, without taking a big step back to understand who uses their product.

What good design managers do
A good design manager focuses on 5 key responsibilities to build a healthy and happy team:

1. Ensure a steady stream of challenging and meaningful work for you & your team
2. Show where the quality bar is, by doing exemplary work yourself
3. Protect time and focus of your reports so they can do their best work
4. Communicate timely & clear feedback to every team member
5. Create a personalised growth path for every member in the team

_The perdocent exploits the claim of not having been taught how to do something, as a means of not understanding, of taking control, or to avoid doing any actual work.

As a management professional, no matter their appeal to credential, never let a perdocent take control. Always seek to maintain familiarity with the perdocent's tactics…_

Those given the greatest authority in the firm turn out to be the most powerless to effect positive change in the production process. The actual means by which decisions get made in the firm are a rats' nest of bypasses often held up by the force of will in singular individuals.

Many of these individuals (such as staff engineers) also have a crisis of meaningness when and if they realize their vast skills are essentially wasted being a glorified "glue stick" holding together a system which is perverse, and for no real purpose.

https://hbr.org/2019/12/can-you-know-too-much-about-your-organization
If you looked closely, would you see a deliberate strategy or the results of years and years of patches, workarounds, political truces, and shadow systems? They came to see peripheral roles, in which they stood apart from the complex system that required redesign, as a place from which they could add more fundamental and long-term value to the organization.

'Schlep Blindness'
http://paulgraham.com/schlep.html
A company is defined by the schleps it will undertake.

'Chesterton's fence' is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood.

There is a tremendous amount of spit and polish that goes into making a major website highly usable. A developer, asked how hard something will be to clone, simply does not think about the polish, because the polish is incidental to the implementation.

Five questions to look under the hood of the interview

1. How will I fail?
2. How do you incentivise your team?
3. Can you share an example of something the team did that didn’t go well, and what did you do to course correct?
4. What does the shipping look like internall`,
5. How much attention do you pay to reducing friction for the engineering team?

It can be challenging to express your thoughts clearly. Alan Alda recommends three rules of three for effective and empathic communication.

1. Make no more than three points

Research suggests that short-term memory is far less robust, maxing out at a meager three to five items.

2. Explain difficult ideas in three different ways

3. Make important points three times

In some close-knit relationships, spaced repetition is a phenomenal tool. Teachers, parents, psychiatrists, or team managers can use it to return to and reinforce difficult ideas across many conversations.

Why they don’t read it

I’m a bit of a perfectionist. Several years ago, I believed the best documentation should be nicely formatted, concise, well-illustrated, and written in clear language — and this is not wrong. But all these features make little sense if the documentation isn’t regularly used by those for whom it has been created.

If the team doesn’t react to anything you publish, I have bad news: this documentation (specs, reports, guidelines, etc.) might be already “dead.” Here are several typical scenarios of what may have gone wrong:

1. “Approved and forgotten” — design guidelines were created without team involvement and then approved by stakeholders. After the official presentation, someone checked them out, while others didn’t. Since the guidelines were comprehensive, they looked like a huge reading that would take a lot of time.

2. “A perfect monolog” — amazing design knowledge base inspired lots of team ideas and questions, but commenting was either absent in the tool or disabled. As a result, the discussion occurred elsewhere, in Slack or MS Teams, and soon this chat became a more valuable “source of truth” than the knowledge base itself.

3. “Lone warrior” — design system documentation was detailed and well-structured but didn’t include any links to what other team members (engineers, QAs, UX researchers, etc.) were doing. As a result, it remained just the designers’ resource, and designers had to answer the same repeated questions in the chat or team meetings.

Documentation is a digital product no less than the actual product you are designing and being paid for.

A guide for your daily "professional" interactions

That’s not my job

I’m not the correct person to assist with this but I am happy to connect you with [insert name] who will be able to help

You are not my boss, stop trying to assign me work.

Have you connected with [manager name] in regards to me taking this on? As it has not been communicated to me that I’ll be working on this.

Use this complete guide to hire a UX designer. Learn how to find, interview and recruit a designer with this step by step guide.

The Working Backwards product definition process is all about is fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build. It typically has four steps:

1. Start by writing the Press Release.
2. Write a Frequently Asked Questions document.
3. Define the customer experience.
4. Write the User Manual.

Levels at big tech, the most common career paths, and what comes after making it to Staff