Login to Plato

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Don't have an account? 

Achieving Alignment and Efficiency Through a Technical Strategy

Sharing the vision

21 June, 2020

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.


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.

Actions taken

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 ([ ]) (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.

Lessons learned

  • 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

How to Drive a Team Vision as a First-Time Manager
23 February

Paras Doshi, Engineering Manager (BI & Data) at Amazon, recalls how he successfully drove a team vision as a first-time manager who took over a team without the vision and roadmap.

Sharing the vision
New Manager
Paras Doshi

Paras Doshi

Engineering Manager (BI & Data) at Amazon

A Lack of Clear Vision and the Team Morale
29 January

Naveen Veeravalli, Engineering Manager at Uber, discusses how a lack of clear product vision impacted the morale of his team and shares what he did to improve their engagement.

Sharing the vision
Naveen Veeravalli

Naveen Veeravalli

Engineering Manager at Uber

How to Drive Product Strategy in a B2B Sales-Driven Company
20 January

Paul Sicsic, Life & Health Product Manager at Shift Technology, explains how to drive product strategy in a company that only starts building a product after a customer is secured.

Sharing the vision
Paul Sicsic

Paul Sicsic

Life & Health Product Manager at Shift Technology

One Culture, One Organization, One Mission… Post-Acquisition
30 December

Wadah Sayyed, Director of Engineering at HPE, outlines all the actions he took to ensure the successful integration of two teams following the acquisition.

Company Culture
Sharing the vision
Wadah Sayyed

Wadah Sayyed

Director of engineering at HPE

How to Spot Key Issues
30 October

Alvaro Moya, VP of Engineering at Wefox, explains how to spot key issues when joining a new company and what actions should be undertaken to solve those issues.

Team processes
Sharing the vision
Alvaro Moya

Alvaro Moya

VP of Engineering at Wefox

You're a great engineer.
Become a great engineering leader.

Plato ( 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.