Back to resources

Achieving Alignment and Efficiency Through a Technical Strategy

Sharing The Vision

21 June, 2020

Damian Schenkelman
Damian Schenkelman

Principal Engineer at Auth0

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.

Problem

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

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

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

Guiding Your Team Through a Data-Driven Transformation

2 June

Philip Gollucci, Director of Cloud Engineering at CareRev, shares his tips for managing people amidst a significant data-driven transformation.

Innovation / Experiment
Changing A Company
Sharing The Vision
Data Team
Philip Gollucci

Philip Gollucci

CEO/Founder at P6M7G8 Inc.

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Here to Make a Recognizable Difference: How to Develop Teams

5 May

Eric Merritt, VP of Engineering at Whitepages.com, divulges on the many complexities of developing teams in management by solving problems according to their needs, and empowering teams.

Leadership
Impact
Sharing The Vision
Coaching / Training / Mentorship
Eric Merritt

Eric Merritt

VP of Engineering at Whitepages.com

How to Foster and Reinforce Your Company Culture

25 April

Alex Bekker, Former VPE at Cresta and HackerOne, shines a light on how to preserve company culture throughout a growth phase and shares actionable insights on reinforcing your core values.

Mission / Vision / Charter
Company Culture
Meetings
Sharing The Vision
Performance
Alex Bekker

Alex Bekker

ex VP of Engineering at Cresta