I often find that the best technical leaders can manage the combination of thinking big and acting small. We need the big thinking part of us to set a grand vision and often to inspire folks to support the journey. I find that ineffective leaders only have a big picture view, they only ask for the big accomplishment. The most effective technical leaders have mastered the art of kaizen, or small steps to continuous improvement. These small steps are not only approachable, they also help solidify permanent change.

Small steps routinely executed have been called out over and over as a way to make big change. There’s a book by Robert Maurer called One Small Step Can Change Your Life that outlines the kaizen way.

As a technical leader, you not only need to make progress - you also need to inspire others to make progress. Ideally towards a big goal that folks may not see as achievable. Breaking own a problem into small parts that can be started and finished, built, demonstrated, tested is the way to make real progress. Often these small steps feel like partial progress. Measuring against the big goal, they are partial progress. And the more tangible they are the more tangible the actual progress you’re making is to the actual big goal.

I’ve been party to projects where the team is working week in and week out on stories. Stories that are completed, but not tested. Burn down charts that shoe progress and percentages of total project completion without interim builds that can be exposed to the user. Or even effectively integration tested. And those project invariably use the cloak of bad reasoning to hide the lack of true progress. Have you ever heard “it’s more efficient to complete all the stories and test at the end” or “if we make all the changes in one big set we don’t have to compromise the architecture by interim builds”?

Jim Collins has a different take on it with his tactic called the “20 mile march” in Great by Choice. Collins talks about building a habit that can be sustained over long periods of time. In technical leadership, this “20 mile march” is measured in continuous contribution to the project every day.

The most effective projects I’ve participated in hold true to small stories completed, built and demonstrated. Your job as a technical leader is to model this behavior, to encourage it, to provide feedback when it’s going well (and when it’s not). We all need to be checking in code daily that builds and runs tests. If we’re checking work in daily there is no way we can’t be forced into working in small pieces. And the requirement stands that the build cannot break. So we’re making small progress towards the big goal, and we can not only see it we can use the software in the new state every day.

Take a look at your team and the frequency of commits you have in your source code repository. If you’re like most average teams, you’re not getting daily commits from your developers. Are you getting the frequency of builds and integrations that you need to be assured that even your short, two-week iteration is on track? If you’re not, encourage your team to commit more frequently. Maybe make it game and report out who is winning. Take the artifacts and automatically deploy your nightly build so it can be exercised every day.

Small steps, ever visible, are real progress to the big goal.