Here at Angaza, we appreciate the craft in our engineering work. We strive to deliver life-changing products, while caring deeply about the process we use to create these products. We don’t just want to “do engineering,” but rather, we aspire to master the art of engineering. We want to adopt principles and employ practices that are considered state of the art, enabling us to build robust, usable products in a strong, thriving engineering culture. But this aspiration raises the question — what are those principles? For us, the answer can be found within our engineering constitution.
The Engineering Constitution Process
In 2017, our CTO Bryan Silverthorn brought the idea of an engineering constitution to the team suggesting that it be a long-living document that doesn’t list everything we do, but it does list the things that we always do. The goal was to document a set of principles that every engineer could internalize, and the document would be resilient in our ever-evolving engineering environment. We outline this goal and the process for amending our constitution in its Preamble:
Preamble
1. This is not a comprehensive list of everything we do, but these are things that we always do.
2. Amendments to this document can be proposed during our periodic retrospective meetings or via email.
3. If we ever find ourselves in violation of a principle listed below, each engineer has the authority and responsibility to bring attention to the violation and aid in rectifying it.
4. If any two principles below appear in conflict, the principle that appears earlier in the document takes precedence.
In addition to creating a robust document, we wanted these principles to reflect the unique challenges that engineers at Angaza face. So, an immediate question became: “What makes our environment different?” Here are a few examples of what we came up with:
- We are a B2B company, and our partners depend on our products to operate their business. They have no workaround when our products fail.
- It can take hours to fix a defect in our hosted software, days in our mobile software, and months in our embedded hardware and software.
- Our customers span at least three major geographic and cultural areas. No one person at Angaza has a background similar to that of the majority of our users.
- There can be five or more hops between us and a user’s daily experience.
- Our customer team is not co-located with our development team.¹
Keeping these goals and challenges in mind, we began to discuss the content.
The Content
We decided to further the constitution analogy by listing our top-level, general principles as Articles:
Article I. Never Compromise Quality
Article II. Focus On Our End Goal
Article III. Pick Team First
These top-level articles give a high-level view into what we value² as an engineering team. Without listing each principle here (there are ≈30), I’ll pick a few that resonate with me specifically:
Principle I.7: We have a strong bias towards clarity over complexity, simplicity over cleverness. This preference covers not only the actual implementation, but the creation and review processes as well. The onus is on the author to present with clarity, and for the reviewer to relentlessly request it.
For me, this principle highlights two important things:
- We aren’t trying to show off how smart we are when we write software or design hardware. Often the most challenging part of coming up with an elegant solution is making it simple. To quote Steve Jobs: “Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
- The author of a change is responsible for making the intentions and implementation details of the change easy to understand. When a change is submitted for review, we take great care to make the review process easier by including context and reasoning up front.
Principle II.8: Questions around who is going to buy the product, how is it going to be distributed, and how distributors and their customers will interact with it are as important as, if not more important than, the engineering questions during product development.
Our team values empathy — both empathy with other Angazans and empathy with our end users³. We, as an engineering team, are full collaborators with product management. We are responsible for fully understanding the problems we are solving, how new features are going to be used, and what impacts these features may have on other users of our products.
Principle III.6: Every retro closes with appreciations. Every sprint finale opens with shoutouts.
Appreciations are the life blood of a team. Creating a safe place for sincere, positive feedback is critical for building a high-functioning, successful team. These short, thoughtful sessions are often the highlight of my week, and I love the support that we show for our teammates.
The Outcome
Each engineer signs the constitution. Here, you can see Davis Shih (left) and Alison Polton-Simon (right) in action.
We are Angaza Engineering, and this is how we build things. When a new engineer joins the team, they read, internalize, and sign the constitution during a ceremony at an office-wide meeting. In PR and design reviews, we advocate for a particular point of view by citing principles from the constitution. We’re still not perfect (there are a few principles that we’re striving for but aren’t quite there yet), but we’re moving in the right direction.
¹ We’re changing this! We’re hiring in our Nairobi office. If you haven’t reached out yet, you should!
² Not to be confused with our company-wide values. These engineering-specific principles strongly complement our company values (e.g., “Never Compromise Quality” ⇒ “Deserve their trust”).
³ One of our company-wide values is “Innovate with empathy.”
