Focused teams are magical. An incandescent light bulb can dimly illuminate an entire room. Most of its energy is lost as heat. A laser, however, can cut through steel. All of its energy is focused on a single point. Both are light sources, but the latter is clearly more powerful. Teams should be focused like a laser.
If you've been reading this newsletter for a while, you'll know I preach the gospel of do-one-thing-at-a-time. I don't want teams churning through Jira tickets. The result of their iteration shouldn't be a list of unrelated features in the Done column.
I want teams to solve one problem every iteration and often compare these focused iterations to hackathons. We don't start a hackathon with a fully fleshed-out backlog or fixed scope. We start by asking the question: "What is the best solution we can build given the short amount of time?"
People tend to agree with the do-one-thing idea until they have to implement it. Do-one-thing-at-a-time is simple, not easy.
At the start of every hackathon, some people find it easier to contribute than others. A front-end developer might immediately know what to do, while a marketeer might struggle to get started. They wonder how they can apply their marketing skills at this point.
The same thing happens when teams start to focus. Let's say they want to focus on redesigning the admin dashboard. The front-end developers and designers know exactly what to do. They are ready to go. The back-end developers might struggle to find a meaningful way to contribute. What can they build to help solve the dashboard design?
At this point, most teams will resort to multitasking. Giving the back-end developers "work" feels more productive than keeping them "idle". Yet, just like the lightbulb loses most energy in the form of heat, a multitasking team will lose most of its productivity through context switching.
Focus has the obvious benefit of increased productivity. But there are secondary benefits that we shouldn't overlook. Take team building, for example. No paintball outing can compete with the sheer camaraderie-building force of solving hard problems together. Your best-ever team was the team that got shit done.
Then there's the instant knowledge-sharing. Since everyone has worked on the same problems together, the knowledge is automatically spread across the entire team. If you ever had a feature that was "owned" by a single developer, you know how debilitating that can be.
Finally, there's increased skill building. That front-end developer can do more than code React components. The hackathon might ask them to leave their comfort zone to help with design or back-end. That's a great way to keep your teams learning.
You lose out if you choose to multitask.
So, what do you do if you feel a team member isn't able to contribute to the hackathon?
Get creative.
More often than not, we can flex our creative muscles to find meaningful work. A company I once worked with generated reports via REST calls. As their dataset grew, the reports started to take longer. Clicking the "generate report" button would require the user to wait for minutes. We organized a hackathon to solve that problem. It soon became clear the team wanted to move to an asynchronous approach. Clicking the button would trigger a job that would send the user an e-mail once the report was ready. The back-end developers started to whiteboard like crazy.
But the front-end developer wasn't sure how to contribute. Nothing in the front-end would change other than showing a "you'll get a mail" message.
So we asked: "What can we do to make the experience of this asynchronous report even better for the user?".
Soon, a few ideas came up. We could add progress animations. We could create a page with a history of generated reports. We could set up a notification system in the header bar to inform the user their report is ready.
There are always plenty of valuable ways to contribute.
To people who think in scope, this feels counterproductive. We are "making up work" while we could have that front-end developer work of ticket ABC-1234. But building a product is more than churning out Jira tickets. We need to share knowledge. We need to build the team.
That's where focus shines.
Fantastic article Mike! I've seen the benefits of a focussed team versus an unfocussed one and not only does everyone end up working more effectively (far less context switching) they tend to have more fun too as it's a chance to really dive deep into a problem and all work together.
The future is in focussed work. Single piece flow for the win.