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.
Senior software developer at Amazon Web Services. I work on the AWS Serverless Application Repository and AWS SAM. Iām passionate about writing quality software and teaching others how to do the same.
Location
Seattle, WA
Education
BS Computer Engineering, Minors: CS and Math
Work
Sr. Software Development Engineer at Amazon Web Services
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. š
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!