Model, document and share.
Early on in my career, I spent a lot of time trying to find my leadership style. Recently, I think it’s more useful to think about growing yourself as a leader by developing a range of styles and applying them thoughtfully to your circumstances. Confining yourself to one style is just too hard.
One of the trickiest, and most common, leadership scenarios is leading without authority, and I’ve written about one of the styles that I’ve found surprisingly effective in those conditions. I call it Model, Document, and Share.
How it works
Imagine you’ve started a new job as an engineering manager, and the teams around you are too busy to use a planning process. You’ve mentioned to your peers a few times that you’ve seen Kanban work effectively, but folks tried it two years ago and are still upset whenever the word is mentioned: it just doesn’t work here.
Your first reaction might be to confront this head on, but it takes a while to build credibility after starting a new job. Sure, you’ve been hired for your experience so they respect your judgement, but it’s a hard sell to convince someone that your personal experience should invalidate their personal experience.
I’ve been trying something different.
Model. Start measuring your team’s health (maybe using short, monthly surveys) and your team’s throughput (do some lightweight form of task sizing, even if you just do it informally with a senior engineer on the team or yourself), which will allow you to establish the baseline before your change.
Then just start running Kanban. Don’t publicize it, don’t make a big deal about it, just start doing it with your team. Frame it as a short experiment with the team, and start trying it. Keep iterating on it until you’re confident it works. Have the courage to keep at it for a while, and also the courage to stop doing it if it doesn’t work after a month or two. Use the team health and throughput metrics to ground your decision around whether it’s working.
Document. After you’ve discovered an effective approach, document the problem you set out to solve, the learning process you went through, and the details of how another team would adopt the practice for themselves. Be as detailed as possible: make a canonical document, and even get a few folks on other teams to check that it’s readable from their perspective.
Share. The final step is to share out your documented approach, along with your experience doing the rollout, in a short email. Don’t ask folks to adopt the practice, don’t lobby for change, just present the approach and your experience following it.
You’ll spend the majority of your time refining approaches that work effectively for your team, a bit of your time documenting how you did it, and almost no time trying to convince folks to change their approach.
Strangely, in my experience it’s often led to more adoption than top-down mandates..
Where it works
When considering the Model-Document-Share approach works, it’s interesting to compare it with the top-down mandate.
Mandates assume:
- It’s better to adopt a good-enough approach quickly
- Folks have bandwidth to adopt a new approach
- Org has available resources to coordinate a rollout
- You want to centralize decision making on this topic
- Consistency is important; all teams need to approach this problem in the same way
- It’s important to make this change quickly
Model-Document-Share assumes:
- It’s better to adopt a great approach slowly
- Some folks don’t have bandwidth to adopt a new approach
- Org may not have resources to coordinate a rollout
- You want to decentralize decision making on this topic
- Teams have agency to adopt the appropriate practices for themselves
- It’s okay to gradually change approaches
If your circumstances and your organization’s values align with the second list, then this approach may be more effective for you than making mandates. If you have the time, you can slowly flock towards great practice, without needing organizational authority (you’ll still need some natural authority, the respect of your peers).
Although I’ve seen this approach work remarkably well, I’ve also seen it go no where. It’s a particular tool for certain circumstances, and it does fail. It may be an inexpensive failure–folks simply don’t adopt–as you haven’t spent much authority on it, but nonetheless you still haven’t accomplished your goal.
It’s particularly important not to try to use this as a strategy to circumvent organizational authority. Operating in direct conflict with authority usually doesn’t end very well.
What leadership styles have you seen work?