Do Less

As I’m writing this post, I’m getting ready to publish my most recent app, Ora, to the App Store. Ora is a funny project, since it took me over a year to get it into a shippable state—but for most of that time, I didn’t touch the codebase at all. I stopped working on it in June of 2024, and when I opened it again in January of 2025, I spent most of my time removing features from the app.

The benefit of stepping away from the work was the clarity and confidence to remove all the parts that no longer seemed so important. Being able to see your friends’ time zones, recurring alarms, Live Activities and calendar events—all this seemed like cruft that only delayed the launch of an app that was ready months before it was “finished”.

At the same time, Meta, the company I work for at the time of writing, is going through a period of intensity. In fact, 2025 has been dubbed the “year of intensity” at Meta in the media. Intensity comes in many forms, but in tech, it usually means doing more with less resources.

After almost 9 years at Meta, I’ve found that the only way to do more with less is to actually… do less. Whenever I’m confronted with a new project, problem, bug, or vision, I go through the same set of steps to try to make sure we’re getting the most value out of the least expended energy.

Delegate

I don’t mean this in the passing-the-buck sense; I think delegation is critical to scaling yourself. At Meta, nothing is someone else’s problem—but that isn’t to say that you are the best person to solve every problem.

Whenever a new project lands on my doorstep, one of the first things I ask is: is there someone else who can do this better than—or at least as well as—myself? It might be that the project would benefit from a specific skillset or historical context I don’t have; or it could be that the project would be a great opportunity for someone else to gain new skills or experience.

Understanding why you were selected and helping the team objectively evaluate the needs from your role can help identify the right person for the job, whether or not it’s you.

Descope

Projects that don’t begin with all the necessary functional roles filled often end up ballooning in scope. When the functional roles are filled and the work is actually happening, one of two things (or both) tend to happen:

1. The project faces delays since elements of it are technically hard or impossible to deliver
2. The project is artificially scoped down in real time in order to release an MVP, or minimum viable product, which fails to deliver the core promise of the idea

Instead, spend the time to challenge the scope of the work to distill the minimum valuable product and make that the initial milestone. This exercise allows your team to deliver something of value quickly, learn from that work and adjust the ambitious plan accordingly.

Parallelise

If we really want to move fast, no person on a project should be left feeling “blocked” while they wait for the work of someone else. In product design, we’re often asked for “final designs” to provide to engineers so that they can begin coding. But at large companies, “final designs” often have to go through rigorous review cycles, from design system teams, product reviews, and one or more groups of executives. In my experience, this way of working presents several failures:

1. It creates animosity between designers and engineers, where designers feel rushed to provide something airtight in impossible timelines, and engineers feel frustrated that designers are slowing their progress down
2. It produces unrealistic designs and back-and-forth between designers and engineers at build time. As products are built in code, new constraints are encountered that invalidates designs and causes the team to pause and re-litigate decisions.
3. It creates design review processes that are somewhat detached from reality. When design reviews precede any engineering progress, it means that whatever design is approved by executives will always mismatch the actual, built product.

Instead, insist that engineers begin prototyping based on the knowledge you have of which parts of the product are absolutely essential. Think about the data types, the creation and management of those types, the privacy and integrity requirements, and even the novel interactions that you know you want to explore, and have engineers build those pieces as part of what I would call “design discovery”.

This parallelising of design and engineering means that designers can adapt to constraints encountered by engineers during the design process, and not after designs have already been approved by reviewers. This results in less time spent revising work, more realistic designs, and more accurately-built products.

Time-box

“Money is circulated. Time is spent.” — Frank Chimero

Your time is your most precious and finite resource. Work has a tendency to fill the time allotted to it. This can actually be helpful for accomplishing the three above approaches, if you know how to spend your time wisely.

A small change you can make to begin practicing these behaviours is being judicious in limiting your availability for projects. For example, telling your partners on a new project that you can only dedicate a certain number of hours per week to a project, and sticking to it. Whether it’s through 1-hour long calendar blocks you use to focus on a specific project, or hosting office hours where people can come and ask you for tactical guidance, this limiting can be helpful for both descoping work and parallelising progress.

It will also leave you with a greater sense of control if you—rather than your work—are the master of how your time is spent.