I’ve recently become a mentor at the plato network. As part of that I’ve worked with them to write down some stories about my experience at Auth0. I thought it’d be interesting to share those stories in my blog as well. Originally published this one here.

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