This post was originally posted on my blog
I've found that one of the keys to a productive and happy development team is when every member of the team understands (1) the technical direction of the team, and (2) how the work they're currently doing contributes to that direction. Because of this, one of my key roles as a senior developer is helping teams establish a clear technical direction, as well as a plan for how to get there.
After several years working at Amazon, one thing that continually stands out to me is the genius of Amazon's Leadership Principles. At some other large companies where I've worked, their version of leadership principles or corporate values were just a set of vague statements or buzzwords printed on posters and hung somewhere in the office. Most people ignored them and carried on with their daily work. However, at Amazon, we live and breathe the leadership principles and refer to them frequently in daily conversation. Collectively, they setup a framework for thinking that pushes everyone who works there to become fast-moving, innovative leaders.
When it comes to establishing technical direction for a team, two leadership principles come into play: Think Big and Bias for Action.
Think Big encourages you to "create and communicate a bold direction that inspires results," while Bias for Action pushes you to move quickly and not get lost in the dreaded analysis paralysis. A good technical direction incorporates both of these principles. As a result, I coach teams that they must establish, both a long-term, directional vision and short-term, incremental milestones that lead in the direction of the long-term vision.
Long-Term Vision
The long-term technical vision is where the Think Big leadership principle comes into play. Take the business problem, put pesky constraints like time and resources out of your mind and try to come up with an idealized architecture. Be liberal with unicorns and rainbows in your block diagrams. 😉
Seriously though, long-term visions are tricky. They have to be clear enough that they are believable and everyone on the team can understand and align to them. They have to be relatively stable over time. Finally, they also have to be abstract enough that individuals feel empowered to forge creative paths to get there. This is a tall order and a key challenge of effective leadership.
Here are some tips that help me when coming up with a long-term technical vision:
- A picture is worth 1000 words. Architectural block diagrams can add a lot of clarity around key components and their relationship to one another.
- Don't try to fit your entire vision into a single picture. Use multiple pictures at different levels of abstraction to provide clarity. I love Simon Brown's concept of thinking of architecture diagrams as maps of your codebase.
- Stay abstract. Avoid choosing specific technologies. Instead, stick to defining components and keep concepts like databases, queues, streams, etc generic, rather than naming a particular solution.
- Walk through key business use cases and show how the components interact.
- Enumerate the key business and technical wins of the architecture.
- It's all about boundaries. It's critical to define the key subsystems and components of the architecture and their responsibilities. A great way to solidify understanding of responsibilities is to focus on boundaries when walking through use cases. Specifically call out what each side is responsible (and not responsible) for.
- Don't try to design to the last detail. You don't need to go deeper than component level, i.e., no class diagrams. Remember, the important thing for long-term vision is defining key components and their responsibilities.
Short-term Incremental Milestones
Long-term visions are important, but if you are really exercising Think Big, you will end up with the outline of a system that will take several years to build. If you just turn around and build that entire system from scratch, you might run out of funding before ever launching. Even worse, you might get to the finish line and realize what you've built wasn't actually the right solution. Businesses shift quickly and you need to be able to adapt to that change. This is where the Bias for Action leadership principle comes into play to balance out Think Big.
Once you've established your long-term vision, it's time to come back to the real world and come up with an incremental plan to get there. That plan needs to involve launching something real to customers quickly so you can get rapid feedback in case you need to course correct in the spirit of Agile and The Lean Startup.
I like to use the Impact vs Effort Matrix as a way to think about this:
Building your long-term vision from scratch should be firmly in the high effort, high impact quadrant. However, to get started, look for tasks in the low effort, medium-high impact area that are in the direction of your long-term vision. For example, your long-term vision may be to build a complex, feature-rich realtime business analytics platform for your business. However a short-term milestone in that direction would be to stand up a Kafka cluster and attach a connector to a replica of a few of your DBs and push updates into an ElasticSearch cluster. Then use Kibana to create a few dashboards. This is something that could be completed in a few months and will give you customer feedback that helps you determine next steps. It can also give you datapoints to help determine if you're headed in the right long-term direction or if your long-term vision needs to be tweaked.
Here are some tips that help me when coming up with short-term, incremental plans:
- Look for milestones that are achievable within a 3-6 month (or shorter, depending on the size and scope of the project) timeframe. Ideally milestones are customer-facing, but don't stretch your milestones out to a year or 2 years just to make them customer-facing. If they're that big, there's probably a scrappier solution that will give you the feedback you need.
- Be concrete. Unlike your long-term vision, short-term solutions should be well-defined. Choose specific technologies and justify your choices.
- Enumerate the key business and/or technical wins of each milestone. This ensures you know why you're doing each one.
- Use the long-term vision as your guide post. Your milestones should be in-line with the end goal, although they can veer off track a bit if there are good reasons for it. However, avoid lateral or backward movement.
- Don't try to define every single milestone all the way to the end goal. The long-term vision is directional and it may (will) change and evolve as you learn more from each milestone. Trying to define every step at the outset is difficult and wastes time.
I can't stress that last tip enough. I've worked with people who try to push for detailed plans that span multiple years, and it just ends up being overwhelming and demoralizing to the team. The thing is, if you start with lower effort work and get some quick wins, it builds momentum and confidence. I also find that as you make progress, milestones in the high effort/high impact quadrant start to shift left. In other words, something you've built or learned in a previous milestone suddenly makes another milestone much more achievable. They can become the next milestones on your roadmap, further increasing confidence and momentum. I much prefer this model, because it's adaptive and decentralized, which empowers teams.
Conclusion
Having a clear long-term and short-term technical direction is critical to leadership in software development. Hopefully this helps give you an idea of how to approach setting technical directions, and how Amazon's leadership principles can help. If you're interested in learning more about the leadership principles, I recommend reading The Amazon Way.
Top comments (13)
Hi James!
Thank you very much for your article, it was one of the best things I've read so far in 2017. It was really inspiring and I feel like I share most of the values you're trying to apply at your current position. I've also tried to set the technical direction for my current job, but I feel like I miss some practice on how to communicate it to get everyone in.
What can you recommend me to improve how I communicate the technical direction? I've been reading Simon Brown's book but I feel it's not enough.
Great question! Communication is key and you're right, it is not easy. I usually make a long-term vision document on some medium that suggests it's a living document, e.g., wiki. For me, a picture is worth 1000 words so it's generally context and component diagrams with bullet point descriptions of components and key design points. For diagrams, I make an effort to label my arrows as well as the components in such a way that they form coherent sentences if you follow the arrows. It can add a lot of clarity to diagrams so everyone walks away with the same message.
I actually already wrote an internal blog on how I do this, but I still need to write an external version. It's hard when all of my example diagrams are confidential and can't be shared, so I'll have to come up with some contrived examples.
Then I follow it up quickly with a doc covering the short-term plan. It has the high-level design for what we're actually going to build in the next 3-6 months. It also lists milestones, but it loose on specific delivery dates.
For smaller teams, sometimes we combine the two into a single doc with two sections (long-term and short-term). Now that I've written this blog, I've actually referenced it at the beginning of the doc to give context. 😊
Hope this helps!
It does, thanks again!
Nice Post James. The Impact vs effort is a great concept that is sometimes difficult to estimate and measure. There are many features that initially appear as high impact, low effort then change to high effort for many reasons and once implemented ends up having low impact. It helps to check in soon after work starts to verify actual effort still lines up with the estimates. It's impact is also difficult to measure as it is intertwined with other features and difficult to separate the impact of a change unless it is a new, core feature.
I agree that having a long and short term technical direction is critical. Your guidelines on how to set short term and long term goals is good.
John
Thanks for the feedback and good points, John. You're right that impact and effort can be difficult to estimate and measure. I don't have a bullet-proof solution for that, however here are my thoughts:
Thanks, James! Very good thoughts. I enjoyed reading through the Amazon Leadership Principles as well.
Very nice article, Hopefully more people go for something like this
The Ansoff Matrix is similar to the Impact-Effort matrix, at a strategic planning level. Great article James. I guess I'll be ordering the book from Amazon.
Hadn't heard of the Ansoff Matrix. Thanks for the pointer. Glad you liked the article!
Thanks, as always, James. Just bought the book you recommended.
Cool! It's a quick, interesting read. Lots of fun stories from Amazon's earlier days. After that book was published, Amazon made some minor changes to the principles. They rolled "Vocally self-critical" under "Earns Trust" and replaced it with "Learn and be curious," which I think was a good change. Shouldn't always just be about meeting the immediate deliverable. Leaving room for exploration and growth leads to good things.
Love the post!
Sounds to me that achieving long term goals with technical teams is best done just like achieving long term goals in life :)
Awesome post James. No wonder Amazon is disrupting the way it does, with people like you who have beautifully ingrained the culture!