Designing an Engineering Strategy. Part III

I divided this topic into four posts/emails. This is the last one Part I. What the heck is Strategy? Part II. Understanding the high-stake problem. Part III. Giving direction and coherent action. [This post] Part IV. Executing an Engineering Strategy Engineering Strategy Template Congratulations, you understood what's an Engineering Strategy. You gathered essential and relevant information regarding your organization, like business objectives and OKRs and business and product goals. You measured engineering performance based on the 4 Key Metrics, identified main frictions and barriers, understood the socio-technical architecture, and probably found some handovers between teams to deliver value. So, now what? It's time to share your findings with key people and develop a narrative. Focus on what helps the business to succeed Clustering per topic or area After collecting all the information, I first aggregate the stuff based on the topics or area of influence and note down which teams are affected. If you used Miro, you can group them and form clusters per topic. I also add the relevant information of the other tools used, like the 4 Key Metrics, 24 DevOps Capabilities, Engineering Experience Survey, … everything in the same Miro to have all the information in one place and link the different insights I find. Here is an example. Several teams noted problems with Mobile and Monitoring/Observability in the image. We can cluster them and label them with a meaningful name. We can see that those topics affect various teams, and they gain relevancy for the Engineering Strategy. When you see one team being affected by one thing only, you shouldn't discard it just because it affects only one team, instead, assess the implications of that risk. Maybe a platform team spotted a considerable risk given their knowledge and context, take those things into account, and do not discard them! Choose the right size of the topic. It shouldn’t be too low as Java Unit Tests nor too high as Move to the Cloud. Good alternatives could be Enhance our Testing Practices and Adopt the Cloud for on-promise instances for client-facing services. Prioritize based on the business Until today, the best way I know about prioritizing the Engineering Strategy is about relating those topics that might prevent us from reaching the business goals by doing a Correlation Matrix. I add the OKRs or Business Goals as columns and the topics as rows. Then, ask yourself how much that topic or thing to improve impacts the business. I usually mark them as: High Correlation. You want a lot of them. Medium Correlation. Low Correlation. No Correlation. You don't want them. Then, ask some colleagues if they think the same. Hear their arguments about the correlation and adapt. It doesn't need to be accurate but be an educated guess. For sure, not everything is High Correlation. It's a smell that you cannot identify which topics influence business the most. If everything is a high correlation, then nothing is. Choose 2 or 3 areas to focus A good Engineering Strategy drives focus. I'm sure you identified many things to improve, but you will be more likely to fail if you don't put people's effort into a few things at a time. My suggestion is a maximum of three based on my experience and not in any scientific evidence for that number 🤪 You got your Engineering Strategy Direction! 🙌 You made it! Congrats! You started understanding the business, the problems, the inertia in engineering, and the different risks. And thanks to that, you identified the high-stake situations that could prevent you all from reaching the business goals and started addressing them. We want to go in that direction to overcome those obstacles in our path! It's vital to link the insights that explain the why of the direction. It would be best to share why those problems you analyzed can prevent us from succeeding and why we will increase the probability of succeeding by addressing them. Into coherent actions Imagine that you share the direction with the team. And then you leave up to developers all the implementation. It might sound first as I'm empowering them to take the action they feel appropriate. I did it as well in the past, and it kind of worked, but not at its best. It's not the same amount of information you're exposed to compared to the team's exposure. Because you are in a higher role, the information you have after designing the first two parts of the Engineering Strategy makes you the person to develop coherent actions. At least the first ones to set the proper steps and then delegate more. Design some coherent actions to show the path with the teams. Make them real actionable, something like: Direction: Enhance our Testing Practices Coherent Action #1: Add a test step into our Continuous Integration Pipeline The tests are sorely unit They cover the use cases A, B, and C Coherent Action #2 Add an E2E step into our Continuous Integration Pipeline We use Cypress for E2E tests They cover the critical use cases X, Y, and Z. Make the dependencies explicit between Coherent Actions The same as I suggested with the direction about giving focus applies to Coherent Actions. You need to limit the Work In Progress to finishing the actions instead of parallelizing too much. I would suggest having 1 or 2 things in parallel at max. Also, share the dependencies between them, like, we can start Coherent Action #4 after finishing the #1 and #3. Use the Coherent Actions as a Pull System Just telling people to execute the Action might be the "easier way" but not the ideal. Instead, present the Actions using a collaboration tool as Miro and then ask the team members. Who wants to lead this Action? Who wants to help in this Action? You will find the early adopters of the initiatives, those who enjoy joining you in improving the Engineering and becoming the task owners. Also, the Coherent Actions can be an excellent opportunity for those team members to promote to the next position. Showing that they can lead (not that they do it alone!) and helping the team members successfully articulate an Action can be a good showcase of what this person can accomplish. Start With Why. Build the narrative. You have a complete Engineering Strategy after sharing it with everyone and having a good narrative of Why follow it. If you only share the last part, the actions, people don't feel ownership of why they should do it. They lack the purpose of the Engineering Strategy. Instead, share with them all the process you did to get there and how they played a crucial role in getting into it. Sharing the Analysis, the Direction, and the Coherent Actions plus allowing questions and debate will create the right feeling of shared purpose and ownership. You did the design part of the Strategy, do not forget about the execution. A good Engineering Strategy is critical but executing it's as essential as the design part. You will achieve nothing by sharing a good Engineering Strategy and not following it. Documenting, showing the progress on the coherent actions, and keeping this information centralized in your knowledge system is a good starting point. In my experience, the necessary skills to execute the Strategy are more similar to a Project Manager than a Product Manager. Things like: Planning Risk Management Dependency Management Proper follow-up Those skills are in your day-to-day to ensure that all the team members appropriately execute the Engineering Strategy. It's easy to lose focus when you are in firefighting mode. That's when you, as a leader, need to help the team to keep focus and not lose track of what's important. We all have been in situations where we only spend hours on urgent things and miss the important ones. Engineering Strategy Workshop You reached almost the end of this posts series. I have a question for you. Are you interested in assisting an Engineering Strategy Workshop based on this content and being hands-on? Books Start With Why In this case, I will only suggest you this title. You need to properly communicate the Engineering Strategy to everyone and create an impact to inspire people to take action in the right direction. If you only share what you need from them, you're doing it wrong. Instead, please share why you found that direction and some coherent actions and listen to their feedback. If what you shared resonates with their day-to-day and they see the value plus business impact, you made a good Engineering Strategy! Meme for you Index Part I. What the heck is Strategy? Part II. Understanding the high-stake problem. Part III. Giving direction and coherent action. [This post] Part IV. Executing an Engineering Strategy License This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.