I always hear this question in regards to services, or infrastructure. But will it scale? You shouldn’t worry until you should.
But as services and infrastructure, there comes a time when a team needs to scale. Will it scale? Well, we’re a 2 person team of architects for the engineering organization of about ~400 engineers and ~20 Product Managers. We serve more different customers than that, but this is mostly our day-to-day interactions.
As we were finishing the year with our 2020 roadmap, and 2019 retrospective. It became clear that we needed to scale, and we’re at the point were we should start worrying about it.
Two of us is definitely not enough for all the org initiatives that need to be helped, teams and software that needs to be guided in some capacity.
We’re trying to find the best ways to help others, advance and guide org architecture and find time to do team projects through the year.
Some ideas that have been popping into my head, as I look more into this topic now and during 2020.
Document common questions (AKA FAQs)
Every day there are people asking about how a certain part of the systems works, or how to implement a certain functionality, or when extending a sub-system where should certain changes go, or which service they belong to.
While it may take the team less than 2 minutes to answer, it might be best to document all common questions, curate them and keep the up to date, or even make other members of the org update it accordingly.
Document “how it works” for different views of the system
A lot of product and engineering questions comes from trying to understand how a subsystem works. How a certain process we do works currently.
The company has been growing and adding more services to the overall system. But generally, the overall process we do is basically the same.
We’re going to document stuff ourselves, and ask Subject Matter Experts (SME’s) to document parts of the system they understand how they work currently.
Our current plan is to use the C4 models, and provide different levels of granularity in regards of the architecture.
Define a set of architecture principles
This is to guide day to day operations, and questions when people are starting new services, should they be java, node? Should it be REST or GraphQL?
Principles should help teams take as informed decisions as possible. If we’re facing something completely new and unknown then our input and collaboration with teams should help steer direction of a project.
Hopefully collaboration will bring new documentation, principles or both.
Scaling ourselves, or the team, mostly means not doing something and being able to delegate it to either something (like documentation) or someone else (an SME). A set of principles put in place should help others take decisions without much need for our team, and keep projects under their control for as long as possible.
This is to free us from the trap of feeling productive due to doing a lot of small tasks one after another. Allows us to focus on what’s important for the team, and help the org move along as fast as possible.