Scaling up your engineering organization, part 2: Keeping high tech standards

This post is a continuation of Part 1.

You’ve managed to get to a point that your organization can scale by adding more teams that are fully responsible and accountable for the things they develop. The teams are organized as feature teams and their goal is to deliver product increments. But how do you keep your code base at a high technical level? How do you balance between timelines, the need for fast delivery, and the need to improve the tech level in order to move faster in the future?

Principles:

Tech investment can be bucketed into 3 main areas:

1. Code/architecture quality: Teams working and building features and products are oriented towards delivery. There needs to be a continuous effort from the organization to balance that.
2. Long term tech projects: In the described method, the teams are optimized for delivering product increments. There’s a challenge in leapfrogging and building new infrastructure.
3. Developers toolbox: How easy is it for a development team to create a new feature in the given architecture? Should anything that a feature team bumps into when developing a feature and that takes a long time be improved?

Let’s dig into the implementation of the tech investment in our organization.

Implementation:

While all engineering managers are aware of these challenges, we decided to appoint a few parts of the organization as evangelists that will help push these agendas:

Architects lead by the Chief Architect are responsible for:

1. Tech education & best practices: This includes new employee training, internal workshops, code retreats, maintaining an internal dev best practices repository, holding tech talks, and more.
2. Joining complex projects: While the team owns it all (from design to production), an architect that joins the team can help in making better long term decisions and making sure company standards are applied in the team.
3. Designing and POCing long term investments: This could be business requirements without a clear solution (e.g. we need to make our analytics system 10x faster) or agendas the tech organization evaluates and agrees on (e.g. implementing an API gateway to allow building external APIs more easily).

Engineering Productivity organization:

Prioritizing between engineering productivity and features is impossible. The recommendation is to dedicate part of the engineering headcount into engineering productivity teams. The backlogs of these teams should be driven by aggregating the needs coming from all teams, and building tools or automating processes to make them move faster.

Here’s a few examples we’ve invested in Kenshoo over the past few years:

1. A platform for managing the micro-service life-cycle, allowing teams to focus on the business logic. This platform allows a developer to create a new micro-service in an hour.
2. Reducing the time from merged code to production.
3. Providing tools for data analysis to allow faster discovery when developing new features (like Airflow, Jupyter notebooks…)
4. Building an API Gateway to allow developers to easily expose their feature using API without considering all aspects like rate limits, authentication, monitoring, logging….

What’s the takeaway?

Always remember that as an engineering leader, you’re accountable for the long term. There’s no one to your left or right that fully understands architecture, code quality, technical debt, and its impact on the future of the company, so make sure you’re investing into it as much as you’re investing in delivering immediate business needs.