Local Angle specializes in “small” projects. But what counts as “small?” More than you might think.
What makes a project “large” or “small” has nothing to do with how high-profile it is, or how much code needs to be written to make it work. It’s about dependencies.
A project with many dependencies — human or technical — tends to be “large.” Involving many teams and specialties requires coordination, consensus-seeking, project management and executive engagement. Before long, managing the thing becomes more complex than building the thing. This might be necessary, but it also slows things down.
“Small” projects are projects with few dependencies. They can be executed by an individual or a tiny team. They are built using simple technologies, perhaps on top of isolated infrastructures. They trade process for progress.
You can do big things with small teams, but it’s hard to do small things with big teams. And small is often plenty. That’s the power of small — you do what needs to be done rather than overdoing it. — 37 Signals
One of my favorite examples for news organizations is Election Night.
From an audience and mission standpoint, Election Night is massive: the highest-traffic day of the year, high-stakes, important to democracy. But as a project, you can choose to treat it as “large” or “small.” I’ve seen both.
The large version involves months of work: engineers building hardened infrastructure for ingesting and displaying results, designers making comps, frontend devs translating those into code, product managers corralling newsroom stakeholders. Meetings, requirements documents, tickets, decks ...
The small version happens in weeks. It might only involve one developer and one designer, both from the newsroom. Both intuitively understand news, and the most important requirements are implied. This team might not work with as much structure and rigor, but they know which corners they can safely cut and which features are truly necessary. Fewer dependencies make for faster work.
It’s easy to convince ourselves the “large” approach is best. Election Night seems big. Ritual and process create transparency and the impression of security. Communication and consensus feel empathetic and inclusive from a leadership standpoint. The “large” approach feels responsible and professional — like what “serious” tech companies would do.
But the teams I’ve worked with have invariably had more success with “small.” It’s fast and scrappy, it feels a little on the edge, but it works because the benefits outweigh the risks — not just in terms of speed, but quality and accountability, too. Done right, you get a better product, and you bring the rest of the organization along for the ride.
In a recent podcast, Bret Taylor, one of the original creators of Google Maps, made a point that feels relevant to the benefits of "small" projects:
"There's a lot of power and combining product design and engineering into as few people as possible," he said. "If engineering is an order-taking organization for product you can sometimes make meaningful things, but rarely will you create extremely well-crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a maniacal focus on outcomes."
Of course, not everything should be small. Some projects — redesigns, migrations, integrations — benefit greatly from a "large" approach. I know wonderful people who excel at that work. I’m just not one of them.
Local Angle focuses on small projects because that's where publishers can make breakthroughs at relatively low cost. Reducing dependencies means more time and energy dedicated to the product, service or tool you're hoping to build.
Of course, some small projects can also evolve into large projects. And some large projects can be broken down into small projects. It's all kind of a mess. But get in touch and we'll help you figure it out!
Outside Angles
A few things I found interesting this week:
- 95% of AI Pilots Fail — Here’s How to Be the 5%: “Budgets flow disproportionately toward highly visible projects like customer-facing chatbots, sales enablement, or marketing personalization, while the real treasure sits in less glamorous areas ...”
- Lessons on building an AI data analyst: "Hallucinations aren't the main risk anymore; Context is the real failure mode."
- 37 Signals manifesto from 1999: The early manifesto of the web development and product company 37 Signals, circa 1999. Lots here that still resonates today.
- S3 Vectors: ICYMI, S3 now works as a vector store.