30 March 2020
by Katie Pohlman
So, this is part two following a post I wrote about Why We Prefer Small Mighty Teams we we looked at why the size and make up of a team is important. My goal here is to look at some other tactics we use to up the mighty-ante. The cool thing about these? They can help to increase the impact of your team regardless of size.
Discovery beats documentation
I know that starting a project without any sense of scope is silly, but trying to have the answer to everything on day one is just as silly, if not sillier. To get started, we need to understand the problem we’re trying to solve, the goals we want to achieve, and how we want to approach getting there. We don’t need to know every single detail that goes into it. Once we get started, with or without lengthy documentation, we will learn things that will change how we may have initially thought we’d do one thing, which then affects everything we will do from that point on. If that’s inevitable, let’s go ahead and dive in and start problem-solving right away instead of spending time on something that we know will be wrong.
We’re only going to get smarter about solving the problem in front of us as we go. We are bound to learn something we didn’t realize to be true, or even realized to be relevant, down the road. So why spend an exorbitant amount of time trying to document every single thing we need to complete at the time when we know the least about what we are setting out to do?
Shrinking feedback loop
Now, if we’re not going to plan everything out ahead of time, how do we make sure that we are continuously learning and moving in the right direction? That’s a great question! We want to tighten the feedback loop whenever and wherever possible. This touches on the constant communication we talked about in the last post—we need a daily touchpoint with the client—and frequent feedback from our users—to make sure that we have a shared understanding of what is happening, as it’s happening. This allows us to make small incremental course corrections along the way and ensures that we’re spending our time on the right things.
Always minimize work in progress
Speaking of minimizing things—work in progress, or WIP, is a deceptive little booger. It may seem counterintuitive, but the fewer things we are working on, the more we will get done. Huh? That is right; multitasking is not our friend. This goes back to Small Mighty Teams having laser focus in my last post. Working on one thing at a time allows the team to focus on getting that thing done. If there are multiple streams of work, then the team has to context switch, and track where multiple things are at any given time—all of which take up valuable time and brain power.
It also minimizes risk. Think of something being finished as being right—once we get it right, we can call it done. If there are things in progress that are not yet right, or are wrong, and we start additional work before it is, we are building on top of a shaky foundation. We want to make sure that each piece of the tower is steady before bringing something new into the mix to put on top of it. This minimizes the risk of rework, and everyone likes that!
Moving small and moving fast
Both of these ideas lead us to this last tactic. If we want quick feedback loops, and we want to minimize work in progress, then we need to make small, incremental decisions and test them along the way in order to move in the right direction quickly. Think baby steps; taking small steps to work our way toward a larger goal. That way we can pivot quickly and easily if we realize we are starting down the wrong path.
The software you want vs. the software you need
All of this to say we want to help bring to life the software you need, not the software you think you want. At the beginning of the project, everyone is coming to the table with some assumptions about what they want the end result to look like. Our hope is that, through Small Mighty Teams, we can uncover the needs of our users and build something to satisfy those needs.
