The Plot technology strategy

Technology strategy series:

  1. The importance of solid technology strategy and principles
  2. 4 steps to create a solid technology strategy
  3. The Plot technology strategy

Plot logo

I wrote this article as part of my role as VP Engineering at Plot. I wanted to share it here as an example of what a technology strategy could look like. It was our best guess at the time and by no means perfect!

At Plot, we want a world in which technology enables everyone to design learning experiences that accelerate human thought, action & achievement.

That is our product vision.

Our product mission is to achieve this vision with software.

🌍 Gathering context

The technology vision & strategy is at the service of the product one, so that was the natural starting point. We will build software that enables everyone to design learning experiences that accelerate human thought, action & achievement.

Next, I looked at the time horizon. How long-term should our strategy be? Should we plan for one year? 2? 10? Given our early stage, I set a 1-year horizon.

What followed was a context-gathering exercise involving conversations with team members in and outside of engineering.

🤔 Problems and opportunities

Thinking about the challenges ahead will help us de-risk and overcome them.

🎯 Goals

What goals do we need to hit to make significant progress toward our vision?

🛣️ Roadmap

What are we aiming to build?

During Q1 2022, we will build a slice of our tech product, which will allow learning designers to create and sequence content, activities, and assessments.

Once we put the product in front o users, gather feedback and run more interviews, we will decide what comes beyond. It’s okay. We accept that uncertainty is high now and are ready for that!

📊 Strengths and weaknesses of engineering

What skillset and expertise do we currently have? What are we missing? Teams with a clear insight into this will be better equipped to plan and align company needs to folks’ development interests.

Strengths

Weaknesses

🙌 Principles

Following the above context, we established a basic set of principles.

🔭 The vision

We landed on the following technology vision with all of that context, which we believe will lead us to realise the product vision.

An Engineering team that can move lightning fast to create and continuously deliver a high-quality technology tool that makes anybody a world-class learning designer.

⛵ The strategy

The following areas will help us become a team that can move lightning fast to create and deliver a high-quality technology tool that makes anybody a world-class learning designer.

⚙️ Infrastructure as a service

We will invest heavily in Infrastructure as a Service (IaaS). We are happy to pay more per unit of compute and give up some flexibility by using managed services, as long as it helps us spend close to 100% of our time building the product. This is particularly true when the service has a migration path to a cheaper, self-managed alternative.

Pricing models for services like Vercel and AWS Lambda are all usage-based. Having an expensive infrastructure bill because we have too many users will be a great problem to have. Not getting enough users because the team spent weeks setting up and scaling infrastructure is unacceptable.

For example, we chose Vercel and serverless because they make zero-configuration continuous deployment and scalability very easy.

🚢 Continuous deployment

Continuous deployment (CD) means that every time a developer makes a code change, a new version of the application is deployed automatically with zero human intervention.

The time between code change and a new version being deployed should ideally stay below 5 minutes.

Additionally, we will leverage Continuous integration (CI). As changes are incorporated, we run automated tests that validate them.

Finally, we will use feature toggles to deploy partially completed features without releasing them to some or any users.

Some of the benefits of the practices above are:

Thanks to CD, we are deploying code to production over eight times a day on average.

Plot DORA metrics

👩‍💻 Excellent developer experience

We will not invest in complex solutions too early and strive for simplicity at all times. However, we will invest in excellent developer experience by choosing pit of success tools, i.e., tools that make it very hard to do the wrong thing.

Here are a few examples of what this looks like.

These practices increase developer productivity and shorten feedback loops. As a consequence:

At the moment, a developer can set up their development environment in 15 minutes, and a build/test/deploy cycle takes 3 minutes.

Plot CD pipeline

🏦 Technical debt

We are a new organisation working on the first iteration of a greenfield product. Unlike us, most organisations are slowed down by piles of tech debt. There is certainly a balance to be struck between moving fast and incurring too much technical debt. As Martin Fowler writes, no technical debt at all is bad!

Tech debt quadrants

We will ensure that the debt we incur falls within the Prudent and Deliberate quadrants. A few of our delivery process practices, including pairing, technical discussions, code reviews, and our definition of done, help us avoid the Inadvertent and Reckless quadrants.

Whenever we want to address the technical debt that we do incur, we will do so in one of two ways:

  1. Following the scout rule as we work on the codebase.
  2. As a preparatory refactor. Since preparatory refactors can take a bit more time, they require the team’s agreement, including PM and Design.

💎 UI strategy

Plot will have a rich UI that needs to feel great to use and have a consistent aesthetic. Our technology choices must enable us to move super fast, as time to market is of the essence, and feedback can potentially result in significant changes.

Our bet is TailwindCSS combined with HeadlessUI. The consequences are:

🤗 A trust-based inclusive team that is continuously improving

We are fortunate enough to have a diverse engineering team in a few ways, including educational backgrounds. As we build an ed-tech product, this can be a competitive advantage. However, taking advantage of this does not happen by default.

Through strong but loosely held opinions and recognising our mix of expertise, we will make better decisions and reach better outcomes. Truly listening, allowing others to voice their opinions, and sharing knowledge are part of the core expectations of engineers in the team.

We commit to regular retrospectives to continuously iterate and perfect how we work together to achieve our goals.

Individuals in the team will frequently pair to share knowledge, learn from one another and streamline development as no peer review is required in those cases.

📈 User analytics

At Plot, we want to foster a data-informed culture, where anyone in the company can self-serve usage data from our tech product to inform their decisions. Be it making changes to the tech product itself or deciding on copy for the marketing website. At the same time, we don’t want to spend any time at all, if possible, setting up a custom analytics pipeline.

We are taking a few actions to achieve this:

🙌 Hope this was useful.

It was amazing to see the team come together, show exceptional ownership, and make critical technical decisions based on the principles we set. Solid strategy and principles genuinely are one of the most effective ways you can scale yourself!

comments powered by Disqus