The art of thinking big and working small

From an early age, we’ve been taught to “THINK BIG” in order to set a high bar to realize our full potential and to be successful in the goals that we set out to achieve. Companies do the same by chasing the next big thing and taking “moonshots”. 

However, one of the pitfalls of thinking big and tackling “big hairy audacious goals”, is that teams work too big and tackle more than they can handle. These large, prescriptive efforts advance slowly, offering little to no incremental value to customers or users. Or, the exact opposite: they work too small, tackling too many tasks without understanding the longer-term vision.

In order for teams and companies to be successful, they often need to find the right balance of thinking big and working small, said John Cutler, Head of Product Research and Education at Amplitude, in a conversation with Atlassian: 

“Working too big” essentially means that teams take on large projects that have no incremental value delivery, no experimentation, and infrequent integrations. When teams tackle big projects, they get bogged down, where efforts to advance through tasks occur at a glacial pace.

Some tell-tale signs a team is working too big include not knowing enough about customers and not integrating knowledge with the current market, or with recent technologies. This lack of integration results in companies being behind the market when a product is launched. The scope expands to fill available time and work on the roadmap gets bigger as teams struggle with planning overcompensation.

But why would a company or team work too big? There are many incentives, such as teams seeking to please senior executives and obtaining financial resources. A large project plan with defined goals is appealing to management since it looks like it can produce tangible results.

At the opposite end of the spectrum, teams “work too small”. This means teams work on smaller chunks of a larger project but don’t see how their work connects to a larger strategy and mission. This approach may seem like teams are adopting agile, but anti-patterns begin to emerge when over-planning occurs. For example, a company with hundreds of stories in a backlog might spend too much time analyzing these stories. Plus, a team might feel a sense of momentum in their work, but when they review it six or 12 months later, they struggle to identify how the work moves the business forward. Instead they see disjointed, reactive work.

Another problem Cutler sees is teams who define big work in small pieces. While a team works small, it may be challenging to respond to feedback. Similar to a Lego set, it entails following a plan of placing small pieces together. However, what if 20 percent of the work represents 80 percent of the value?

So how do you avoid working too big or too small? You strike the right balance by “thinking big, working small,” said Cutler, which means having a “compelling mission linked to a coherent strategy”. Teams understand the vision for the company, then create and manage tasks that support and fulfill that vision. It means thinking strategically in terms of impact and outcomes, and strategizing beyond the next six months or quarter while also giving enough room for experimentation and validation. 

If you only work big, then Cutler suggests trying to work small with the appropriate context for the big goals. If you are only working small, it helps to define the strategic initiative then ladder work down. If you’re working small and defining big things prescriptively, then start easing off prescriptiveness and focus on missions and strategies.

Teams can create learning backlogs that start with the “why” of work efforts, Cutler said. It’s important to learn this new information instead of the “way” to learn. Starting with the “why” means bringing context to each task. Teams should perform periodic backlog grooming to review the backlog of work. This helps ensure prioritization is correct and feedback is incorporated. It also helps teams avoid being reactive to work challenges.

By starting with a learning backlog, teams prioritize what needs to be learned, whether it be through extensive research or hours of development. Also, it helps to build a shared language throughout the company, as a taxonomy of work helps you better describe different shapes or types of work in your company.