Creating a technology team that scales
Anyone who has consulted with the technology folks at an agency has probably heard some version of “we don’t use that programming language / framework here.” That is for a seemingly good reason — the average lifespan of a JavaScript framework seems to be about 6 months these days. Whenever possible, engineers are encouraged to avoid learning curves and harness the efficiencies that come from repeated use of the same technology. If we invest for someone to learn Django, the next few Python projects better be in Django.
However, efficiencies are not the only consideration. By sticking too closely to a given framework, we put ourselves in danger of missing out on important advances in technology.
Learning
One of the main objectives of my college education was to learn how to learn.
At Matter Supply, we also view constant learning as an investment that pays off by creating a faster and more effective learners. Learning is a skill that only gets better with practice. With the ability to learn more effectively, our people come to the table with a variety of perspectives that are not bogged down in any specific technology or fad.
The real world
Of course, we have to balance learning with the demands of day to day work.
We strike that balance by building upon a set of principles and concepts we created as a team. Our list doesn’t focus on specific technologies, but on higher level principles and architectural frameworks.
The specifics of these principles will be clearer to programmers, so those without a technical background need not worry about the details of each. What is important to understand is that all of our principles are meant to ensure that code is reusable, robust, easy to understand, easy to navigate, and testable in small pieces.
The following is a sample of what’s working specifically for our engineers:
Principles
Don’t repeat yourself (DRY)
Ensures maintainability and robustness.Separation of Concerns / Single Responsibility
Ensures testability, reusability and ease of understanding.Inversion of Control
Ensures robustness, testability and reusability.Design by Contract
Ensures robustness, testability, ease of understanding, ease of understanding.
Concepts
Clean Architecture
A concept developed by Robert C. Martin, ensuring that dependencies are unidirectional and each layer has a single responsibility.MVVM
An architectural style that allows multiple developers to work simultaneously on the logic layer and the layout layer but defining proper interfaces. Also allows testing of individual layers.Unidirectional Dataflow (Flux)
A concept developed at Facebook, allowing interface driven applications to reason about actions and state by avoiding unwanted side effects. This ensures deterministic output based on the current state of an application.Reactive Programming
By treating events and inputs as streams, we can provide deterministic transformers to reason over an input stream. Provides a clean path where data is flowing and shows what parts react to specific data updates, making large code bases easier to understand.
Obviously, some concepts are prone to change as the industry evolves, but these concepts have proven themselves valuable over at least the past decade or more. Our concepts are just one possible way to apply our principles, but they have helped us create solutions that meet our principles intrinsically.
To help illustrate the point, imagine if every car manufacturer had to reinvent where the doors + windows were located — we could never build an automotive ecosystem. Advances in drive trains, experience and interior design — all are more valuable innovations than constantly changing where doors are located. By agreeing on principles we can focus our attention on these more important advances.
Benefits
Agile
To create great products, it’s important to bring good ideas to the table and look at the product from various angles. Technology needs to inform the process from the beginning. Our principles are designed to find efficiencies by considering technology solutions early in the process. Too often the visual representation of a product drives technology choices. We look for ways to match functionality to strategy, even before designs have been finalized.
As a team, we want to iterate fast, try new ideas, and dedicate the necessary time to ensure a high quality product. We often run small tests for user interactions to make sure they feel right before we deploy them across an application. For example, in a mobile app we might test the effectiveness of features such as “swipe to minimize” or “long press to refresh” before using them in the final application. This test and iterate cycle is truly agile, allowing us to continuously inform small pieces of designs before scaling anything.
However, experimentation is not without its costs. Experiments are by nature unpredictable and can lead to cost overruns, security vulnerabilities, confusing code, and instability. Therefore the majority of our code is built with proven methods. Experiments are limited to areas where they are most likely to add value, and new solutions are monitored closely, documented extensively, and are built based on established principles.
Typing is cheap, ideas are expensive
Most of our concepts and all of the principles above work in all of the technologies we use. It’s easy to convert a solution from one technology platform to another, allowing us to use the best tool for the job. We maintain the same solution in different languages with the same interface and logic to increase productivity and maturity.
Learn how to learn
New technologies are always exciting. Building upon set principles from one project to the next gives us more time to work on fun challenges and lets us try out new technologies. We don’t expect everyone on our team to come in as an expert in all of the concepts. Instead, we allow people to learn them from others on the team, helping everyone grow. We also require new hires to bring new ideas to the table that we hadn’t thought of. This creates a constant flow of new ideas to learn from.
A common set of criteria
It’s hard to judge if a particular concept is sound or not, especially when seen in a pull request — and concepts sometimes end up becoming a subjective belief system, not unlike like tabs vs. spaces. Having a common set of concepts and principles allows us to use specific criteria to judge a solution. It’s easy to see how not everything can be judged by our current principles — the tabs vs. spaces debate for example (hint: it’s language dependent). It’s important that we align on big items, evolve the principles, and find new concepts as we move forward. However, having a way to communicate those principles is invaluable to actually discussing new criteria and ensuring a common standard of quality in our products.
Scale
Most of our team members have recent large agency experience — working with hundreds of engineers — and we now find ourselves working as a small team. A small team makes it easier to create a common understanding of our concepts and principles. However, as the team grows, we cannot assume this level of mutual understanding will remain intact. Whether that system breaks down at ten or 100 engineers, we want to ensure that everybody has an equal opportunity to be evaluated with a set of common values. As our areas of focus grow, we want to make sure we can architect solutions that make it easy for team members to help one another as needed. This is a necessity for the ability to share people across projects.
When building a team of generalists, everyone needs the ability to join a project and get up to speed quickly. If the high level concepts are the same across projects, the learning curve is limited to the differences in programming languages and libraries. This allows for much faster progress. When people can be productive immediately instead of spending days going through a large code base the experience is far more rewarding.
Conclusion
When we started Matter Supply, we intended to up-end the belief that we need to focus on a small set of languages and tools in order to be successful. We instead decided to focus on finding the best generalists + tinkerers and to allow them to continuously learn and grow.
By focusing less on specific niche technologies and more on a culture of learning and clearly defined technological principles, we are building teams that self-organize around solutions rather than technologies. This gives us the benefits of process specialization without losing the ability to learn and grow as technology continues to advance.
