I’ve mentioned that being a generalist gives me a good vantage point to see similarities and differences across fields and thus to gather a lot of tools and skills to use. But equally important is knowing when to use which tool for which job — that’s based on understanding transition and recognizing where you are in it:
- A product transitions through the phases of the product development process or software development lifecycle.
- A project transitions through the project management phases.
- An organization transitions through growth models, workforce, and management approaches.
If you’ve got a deep enough tool kit, you can pick and choose what’s going to be most useful for the work at hand, rather than trying to use a cookie cutter approach. What you need for working with an early-stage startup, for instance, will be very different from what you need in a more established organization — not just because the work is different, but also because the people are different. Personalities often self-select to different stages of project and company.
A recent 99U article about using sprints very early in the product development process highlights a key reason for adjusting your approach based on the stage of development:
While you can spend longer building a perfect prototype, that isn’t the point of the sprint—it’s a learning process, not a manufacturing one. Knapp has found that teams can get 90 percent of a product’s user interface finished in a single day. And that timeframe is important. “After a day you are definitely willing to listen to what customers say about your product,” says Knapp. “But when your prototyping goes on longer than that, you become more and more attached to the idea.”
But sprints may not be a useful framework in a later stage in manufacturing, for instance, where root cause understanding is more critical than feature building. That kind of work may be more investigative and documentation-based, requiring different tools altogether.
Sometimes you need to be rigid and focus on diligence above all else, and sometimes you need to focus on individual autonomy, loosen the grip, and accommodate different working styles above all else. The key is knowing when to use which approach, and that really depends on where you are in the interplay of transitions.
Here’s a short deck I made to illustrate the interplay of these stages, and what tools come to bear. Click on the arrows or on the slide itself to advance the deck.
No matter what tools you use, or what approach you take, you’ll only be effective if you keep empathy at the core. Managing transition is managing change. Transition is hard and can be emotional, but you can make it less painful by setting expectations, clarifying process, and making sure everyone understands how to hold each other accountable to the process — all of which are driven by empathy.