Achieving Alignment and Efficiency Through a Technical Strategy
21 June, 2020
A common problem for fast-growing companies is "a lack of clarity", too many things are always happening at once. In our case, there was a lot of confusion about what was coming in the future and that made us slow and inefficient in making technological decisions. Teams were uncertain if they should be using a particular technology because they didn’t know if that technology would be supported in the future, they were uncertain if they should be building a particular product in a certain way because they didn’t know if that approach was aligned with our long-term technical strategy, etc. Obviously, this generated lot of inefficiency -- decisions were either made to be later revised or postponed because of insufficient information. This was happening across the organization affecting all teams and Engineers at all levels.
We believed we needed a long-term direction that explained how to approach the technical implementation of problems today and how to bridge the gap between our initial situation and the future vision. More precisely, we needed a documented technical strategy that would detail what we should and shouldn’t be doing to be successful in the long run.
I started off by thinking extensively about the problem. I reached out to different people to better understand the reasons behind our slow decision-making. After talking to a great number of people I learned that all of them have been exposed to inconsistent information, and rumors, which made them afraid of making decisions, e.g. I heard the company is going for X in the future or I heard this particular technology Y is not going to be supported. A lot of confusion was caused by a particular rumor that we were going to support a certain customer need and its technical implications. People kept hearing about it, but concrete plans were never announced. I wrote down these issues, connecting all the dots and aiming to translate that information into knowledge. I realized we needed both short and term ways of solving the problem.
Long term: I came up with a set of topics that I believed the company needed to make decisions about. I tailored my presentations to suit two different audiences -- executive and technical. For the executive audience, I developed a succinct presentation, applying non-technical analogies and explanations, and providing actionable solutions. The technical presentation was much more detailed and included many technical terms. I used nemawashi ([https://en.wikipedia.org/wiki/Nemawashi ]) (an informal process of quietly laying the foundation for some proposed change or project, by talking to the people concerned, gathering support and feedback, and so forth) and shared with my VP of Engineering, other execs, my peers, and other senior leaders through to get buy-in before formally making a decision. More specifically, I approached people asking them for their thoughts and opinions securing the buy-in, so that by the time we met to discuss our decisions, they would be already in favor of the strategy. We finally met, discussed tradeoffs, and arrived at a set of decisions. All decisions were documented in a decision log and we committed specific owners -- in writing -- to carry them forward.
Short term: We had to fill the gap of uncertainty relating to some more urgent and short-term matters. Teams needed to make technical decisions and couldn't wait for a full-fledged technical vision and roadmap. We also realized that once we had that long term vision and decisions, there would naturally be the need to review decisions for specific exceptions. I put together a "design and architecture" (DNA) group formed by experienced engineers and established a process for teams and DNA to collaborate on designs. DNA also wrote guidelines and recommendations, including "approved" technology choices, to guide teams towards independent decisions that don't require review.
- The process of developing a strategy takes both time and patience. As engineers, we are often used to the short feedback cycle of coding whereas developing a strategy takes place at a slower pace and involves talking to and convincing a great number of people. The outcome itself is immensely rewarding, but it is also time-consuming and requires strategic thinking and a long-term focus.
- Secure buy-in before the decision-making meetings happen. Naturally, some decisions will be made in the meetings, but those should be tactical level decisions. Ensuring support from key stakeholders and people who are emotionally attached to the issue before the first meeting is of critical importance.
- Reviewing past decisions, even those that might seem "set in stone" is very important. In fast-growing companies, many things happen because of implicit understanding and inertia, not necessarily intentionally. Bringing those to light and challenging them is a part of growing and becoming more efficient.
- Customizing content for different audiences is a must. Executives would be perplexed if I would only talk about scale and performance internals, as much as engineers if I would only talk about the benefits of predictable costs.
- Document all the decisions and guidelines as clearly as possible explicitly outlining things that should and shouldn’t be done. The strategy should also include the things that shouldn’t be done as that equally helps teams to make their decisions.
- To scale decision making, provide teams with guidelines and recommendations for the most common things, and have a process to deal with exceptions.
Agata Grzybek, ex-Uber Engineering Manager, outlines her efforts to inspire mission-driven culture among engineers on her team.
Engineering Manager at ex-Uber
Damian Schenkelman, Principal Engineer at Auth0, shares the fundamentals of developing a technical strategy and explains how that process helped him improve the overall efficiency of his engineering organization.
Principal Engineer at Auth0
Vijay Gill, SVP Engineering at Databricks, emphasizes the importance of organizational alignment and thoroughly explains how to achieve it.
SVP Engineering at Databricks
Tim Sears, now partner at tweag.io, talks about his time spent as Vice President of Data Science & Engineering at Target. He tells us about the challenges he faced while helping Target build Machine Learning into many aspects of their business. A key component of his solution was to find a way to bridge communication gaps and ensure all the important things *do* get discussed.
Vice President, Data Science & Engineering at fp4ai
Frederic Cerdan, Director of Engineering at Payfit, shares his story of how he helped establish a career path at Payfit. It was a challenging process because establishing a career path with a younger company requires you to start from scratch. The career path he would create would impact everyone at Payfit, making it a constant guess to figure out the next step. He learned a lot along the way including what to do, and what not to do.
Director of Engineering at PayFit
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.