How to Attain Alignment of Vision and Strategy in the Engineering Organization

Problem

The main issue was how to influence the center of gravity of the engineering organization, especially the technical leaders, to achieve alignment and singularity of actions toward a set of common objectives. It was also critical for any transition to infrastructure, process and tooling to be done in a way that would gain approval and receive broad acceptance in the shortest time possible.

Actions taken

Coming into Pebble as VP of SW Engineering, my goals for the organization were quite clear in my mind from the outset - where the organization would go, and how we wanted to grow from a structural, infrastructure and process perspective. As expected, the existing software engineering team had their own vision, processes and practices, unique sets of issues and problems to address, and their own opinions on the path forward (primarily formed by senior leaders that had trickled down to the rest of the organization). Additionally, some existing problems regarding tools were already known but not broadly communicated or given proper attention. Regarding processes and practices, as a positive reception and adoption (especially by the thought-leaders within the engineering organization) to process and tooling changes was critical to our long term success, I undertook a methodical approach to:

• get buy-in from the CEO of the level of investment that the company was willing to make in improving the team's efficiency, and communicate the impacts to the rest of the executive management team;
• to the technical leaders within my team, surface and highlight the issues with existing processes and tools;
• surface options and opportunities for improvement that would visibly improve the efficiency of the team (and our capabilities when working with other parts of the company);
• communicate my overall vision and goals (without going into the tactical specifics) to the team on multiple occasions, over a sustained period of time. This ensured that the process and tooling changes being instituted were in the context and complementary to the larger vision for the organization;
• to allocate time for technical team members to explore the options themselves (even if I had a strong preference or desire for one particular option). This often involved trying out possible solutions first on small scale before bringing them into production;
• and finally to drive to a decision (where the technical consensus almost always aligned with my original plan anyway!). Through this process, the engineering leaders gained buy-in to the underlying issues, were knowledgeable and supportive of the chosen solutions, and became advocates within the broader organization of adoption and use of the solutions. These changes meaningfully improved the efficiency of how my team did our work, and how we interacted with other parts of the company, and our customers. An alternative approach would have been to institute the changes top-down (to dictate the solution, to force through the adoption, and to mandate the utilization). Precisely because we needed to keep the software production engine moving and because we were a growing organization back then, I felt that the cultural disruption, pushback from the team, and probable detrimental impact to our shipping schedules from a top-down approach far outweighed the benefits of faster "on-paper" adoption. My "strong-buy-in" approach was cheaper and more beneficial overall than to dictate a top-down approach and encounter infighting in the process and resistance to implementation. Getting alignment on Vision was a separate but parallel process. After establishing my own credibility within the organization (the topic of a separate Plato story), I undertook a layered approach to disclosing and executing my vision. To the CEO and my colleagues, I communicated the long term (2-3 year) goals and benefits, and the implications on their organizations and the company as a whole. Given the high level nature of the conversation, I was able to communicate the broad strokes relatively quickly after arriving into the company. I had many conversations the senior technical staff over a longer period of time, where I gave them a more detailed perspective, including technical opportunities, challenges, tradeoffs, and benefits. While aligning the discussions around the goals that I wanted to achieve, I worked with them to find areas of individual ownership of portions of the vision, where their personal success (and in many cases growth) could align and support our broader goals. It was important to adjust the communication style to the sensitivities of each team member. Even for the technical leaders, some became overly concerned about timeframe, or side-effects, or workload, or technical details, so my delivery and conversations (and timeframe for disclosure of some parts of the plan) varied among individuals. With the broader team (after at least starting the alignment process with the technical leadership), I laid out the overall vision, then jumped right down to smaller near-term implications. This avoided them being overwhelmed or distracted by every detail of a multi-year plan, and kept them focused on the next few steps that they could contribute to.

Lessons learned

Achieving alignment to a changing vision and goals is always a challenge in any organization because of the existing culture and status quo. It often helps to have transparency and engagement from team leaders for changes in practices and tools, and to get everyone involved from the beginning, as this significantly enhances acceptance and future adoption. For these sorts of changes, empowering the team to collaborate and get to the right solution works far better, and keeps them more motivated, than directing them with what to do. It is important in any transition that the technical leadership buys in, takes ownership, and becomes a group of advocates that drive change throughout the organization.