DEV Community

How to Set the Technical Direction for Your Team

James Hood on May 13, 2017

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 ...
Collapse
 
delacruzdev profile image
Daniel de la Cruz

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.

Collapse
 
jlhcoder profile image
James Hood

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!

Collapse
 
delacruzdev profile image
Daniel de la Cruz

It does, thanks again!

Collapse
 
jlehew profile image
John Lehew

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

Collapse
 
jlhcoder profile image
James Hood

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:

  1. Estimation of effort is hard, period. I generally like using Scrum, because it tries to mitigate this with frequent practice of estimation, measurement of actuals and retrospective to continuously improve. For longer-term planning, frequent checkpointing to see if you're on track, and if not, if you can make changes to help (reducing scope, adding resources, etc).
  2. Measurement of impact can also be difficult to measure, however I think the more common pitfall is failing to define success metrics from the beginning. If you take the time to think about what you want to measure and instrument your solution, then you can draw meaningful conclusions from the data, even in an environment where you can't hold all other variables constant.
  3. In any case, as I mentioned in the article, fast iterations with rapid feedback is key to taming the chaos. If the cycle time is too long, the amount of noise you'll have to sift through quickly becomes prohibitive.
Collapse
 
jtvanwage profile image
John Van Wagenen

Thanks, James! Very good thoughts. I enjoyed reading through the Amazon Leadership Principles as well.

Collapse
 
lewiscowles1986 profile image
Lewis Cowles

Very nice article, Hopefully more people go for something like this

Collapse
 
lowtherc profile image
Christopher Lowther

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.

Collapse
 
jlhcoder profile image
James Hood

Hadn't heard of the Ansoff Matrix. Thanks for the pointer. Glad you liked the article!

Collapse
 
ben profile image
Ben Halpern

Thanks, as always, James. Just bought the book you recommended.

Collapse
 
jlhcoder profile image
James Hood

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.

Collapse
 
ianissoawesome profile image
Ian Rumac

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 :)

Collapse
 
kaykaysea profile image
Krishna Karri

Awesome post James. No wonder Amazon is disrupting the way it does, with people like you who have beautifully ingrained the culture!