I've been writing software for over ten years across early-stage startups, growth-stage companies, and FAANG. The companies were wildly different in almost every way that mattered. The dysfunctions were almost identical.
There was always a standup. Always a sprint planning meeting. Always a backlog of tickets that had been there longer than half the team. Always a "quick sync" that wasn't quick. Always a Slack thread forty messages deep where the scope of something I was already building got quietly renegotiated without me. By the end of an average week I'd had maybe two real coding sessions. Not two days. Two sessions of two or three hours each.
If you've ever spent a Friday afternoon refactoring something for a feature that got cut on Monday morning, you know what I mean.
The frustrating part is that on paper, every one of these companies was doing fine. Velocity targets were hit. Burndown charts were clean. We almost never missed a sprint commitment, because we'd cut scope quietly the day before sprint review whenever things got tight. Leadership had no idea how little was actually shipping. Velocity is a number that goes up.
I think a lot of teams are like this. Not bad. Just slow in a way that's hard to see from the outside.
Workspace runs on a different methodology called Shape Up, originally developed at Basecamp by Ryan Singer. The short version: you do the real planning work before committing a team to a project (Shape Up calls this "shaping"), you commit in six-week chunks instead of two-week ones, and you don't keep a backlog.
That last part is the one that makes people physically wince. No backlog? What about all the ideas? What about the customer requests? What about the thing we said we'd do six months ago?
Honestly, let them go. If they matter, they'll come back. A backlog isn't a record of work, it's a record of decisions you couldn't bring yourself to make. Walking away from yours is one of the best gifts you can give your team.
Here's what actually changes when you switch.
You stop estimating. You set an appetite instead, which is basically a budget: "this idea is worth two weeks" or "this idea is worth six weeks." The appetite shapes the solution, not the other way around. If a feature can't fit in six weeks, you don't extend the cycle, you make the feature smaller. This forces a clarity that estimation never does. Estimation lets you keep your scope and renegotiate your time. Appetite makes you defend your scope.
This change alone would justify the methodology for me. I have never met an engineer who liked story points. Story points are what you give people who can't be trusted with hours and won't accept "I don't know."
You stop running daily standups. Teams own their own coordination. Some do a Monday check-in and skip the rest of the week. Some don't meet at all and just talk in chat when something needs talking about. It feels uncomfortable for about a week, and then you realize the standup wasn't actually doing anything.
You stop doing sprint planning, because there's no sprint. Instead, a small group of senior people meets once every six weeks and "bets" on a handful of shaped projects. Whichever teams get those bets work on them uninterrupted until the cycle ends. No reprioritization mid-cycle, no quick asks, no executive walking over to your desk on a Tuesday with a "minor tweak" that's actually a week of work. If the project doesn't ship by the end of the six weeks, it doesn't automatically continue. You stop, look at it honestly, and decide whether it's worth re-shaping and betting on again next cycle.
That last rule is called the circuit breaker, and it's the thing that makes the whole methodology work.
I was skeptical of it when I first read about it. It sounded harsh. After a few cycles I think it's probably the single best governance mechanism I've ever worked under. It's the reason shaping gets taken seriously, because everyone knows there's no overtime. It's the reason scope gets cut aggressively when projects run long. And it's the reason leadership has to engage seriously with what's actually worth building, because there's a real cost to betting wrong.
The thing I appreciated most about it as an engineer: nobody pulls you off a project mid-cycle. Six weeks of focus is six weeks of focus. That alone is something I'd never had at any company I'd worked at, in any environment, at any size.
Workspace is the tool I built to run all of this.
Pitches, cycles, scopes, hill charts. The hill chart is the part I'd point to first if you only had thirty seconds to look at the product. It's the Shape Up version of a progress chart, and instead of showing you how many tasks are left (which is what a burndown does), it shows you whether the team has figured out the hard part yet. That turns out to be the only progress signal that actually matters. "We're 70% done with the tasks" tells you nothing if the remaining 30% is the impossible part. "We've crested the hill on three of four scopes" tells you everything.
We made one design decision early on that I think is more important than any specific feature. The shaped layer of the product (cycles, pitches, bets, hill positions, status updates) is shared. The execution layer (your tasks, your subtasks, your draft documents) is private to each person.
Leadership sees the shape of the work. Makers own how they get there.
This sounds like a small thing. In practice it's the difference between a tool people use because they have to and a tool people actually like. Most project management software treats every keystroke as a status update for management. We didn't want to build that. The Jira-as-surveillance dynamic is a big part of why software teams hate their tools, and I say that as someone who has been on both sides of it.
Should you switch?
Maybe. Shape Up isn't a fit for every team. If your work is genuinely ticket-shaped, lots of small disconnected things, you probably want a different tool. But if you're a product team somewhere between five and fifty people, you do real feature work, and you can feel yourselves getting slower, try one cycle. Pick a project. Shape it for two weeks. Bet on it for six. See what happens.
What I think will happen, based on watching this play out at startups, in mid-stage companies, and now with the teams using Workspace, is that you'll ship the thing. Then you'll ship the next thing. And about three months in, somebody on your team will say, half-joking, "wait, when did we get fast?"
That's the moment I built this for.