“We used to be fast, now we're slow”
As a founder dealing with growth, you may think back to the early days and remember how fast you could move. Now, with more people, you're asking yourself: Why do things have to take so long? Is this just "the way it is" as we get bigger?
In the early days, you're hands-on. Decisions are quick. Product and engineering aren't departments — they're just a couple people. You don't need process. Things happen organically.
Then, as you bring in more people, you need an answer to "how we work." Most founders resist this for as long as possible. But at some point, necessary process evils start to creep in, especially on the engineering side. The engineering team gets busier and busier with things that don't draw a direct line to strategy. Too much time goes into bugs, issues, requests, and infrastructure. It gets harder to get dedicated time from engineers for things that drive growth.
Through this process, product and engineering grow apart. A hard moment of truth starts to appear when product presents ideas to engineering. Product gives engineering what they thought was a finished solution, but the solution doesn't take technical realities into account. So the engineers push back.
After some rounds of this, product swings to the other extreme. They try to just describe outcomes, and leave more room for the engineers. But the engineers push back again — now they don't have enough detail! All of this leads to lost time, frustration, finger pointing, and lack of movement.
When I was at Basecamp (37signals), we were determined not to get ground down by these problems as we grew. We wanted to maintain startup speed and have the minimum process possible. I described what worked for us in the book Shape Up, but you can boil it down to three things:
- We committed engineering time in six week units. That time scale is big enough to receive founder attention and small enough to keep everyone focused.
- Before kicking off any effort, senior team members from product and engineering worked together to define (to "shape") a concept that is technically buildable within the six weeks.
- Because of the clear direction in the shaped work, the build team could take over responsibility for realizing the project. They defined their own tasks, worked autonomously, gave regular demos, and shipped on time.
If you're small (10 people or less) and are structured similarly to Basecamp (bootstrapped, highly cross-functional), then doing Shape Up by the book might work for you. See: Learn about Shape Up and Common Problems with Shape Up.
If you're bigger than that (20-100+ people) and not similar to Basecamp, it can help to see how real-world teams make Shape Up work for them. See: Shaping in Real Life.
If you need the team to move faster, and you don't have time for mistakes and experimentation, I can guide your team to run a successful pilot the new way. See: Get Unstuck.