Our role as engineers is fundamentally one of service, to our customers, to our product, and to our future colleagues. Our goal is to foster the long term health of Assemble’s code and technology.
We design software with the end goal of delivering value to our customers. Sometimes, that means choosing new technologies to help us move fast or building technically impressive solutions for unique problems. More often, it means choosing simple, maintainable solutions and continually pruning complexity.
We take pride in building Assemble but resist compounding ego into the process. While we like to recognize personal accomplishments, we value Assemble’s overall success above individual performance.
We must act quickly to accomplish our mission. However, we operate in a world of unknowns and ambiguity, and moving indiscriminately can also put our goals at risk. So we mindfully take frequent small steps, prioritizing continual progress over perfection up front. While mistakes are inevitable, we can learn from them and adapt.
Unknowns are a fact of life, and we cannot afford for them to paralyze us with planning. We execute quickly on the details we know, while learning more about the big picture. We take risks when the tradeoffs are worthwhile.
Product and features are important, but we can only keep going as long as our team is strong. While sometimes it may seem simpler to go it alone, we can go faster and further together. We take the time to ask and answer questions, provide and appreciate feedback, and teach and learn from each other.
We build each other up. Rather than taking a sink-or-swim approach, we focus on how we can each contribute positively towards Assemble’s and our own growth goals. We treat each other with empathy and approach challenges with curiosity.
It’s not always true that if you build it, they will come. Building software alone is not enough; we must deeply understand the problem behind our solutions. To that end, we clarify our assumptions and give feedback on product and design. By shaping what we build, we manage complexity over time and enable ourselves to continue shipping quickly and sustainably.
Part of shaping the solution is suggesting a path forward. That could mean proposing a data model out of a set of alternatives, or it could mean identifying the questions that need to be answered to make that choice (and who could help answer them). By exercising judgement and forming opinions, we build ownership over the end result.
We can only move quickly if we trust each other. Trust takes time to grow, but we can support it by treating each other with respect. We aren’t scared to be wrong, and we own our mistakes in order to build an amazing team and product. Because individual performance is less important than trust in that individual, we don’t choose the easy, fast option for ourselves when we know it will create more work for the team overall.
As a distributed team, we recognize that we face some obstacles to trust. We communicate confidently with one another and take the time to respond rather than react. We use asynchronous communication, especially written, to downscale urgency and share ideas across time zones and with our future selves.
Our customers also trust us with their data and business processes. We need to continually earn that trust, and we do that via our deliberate approach to communications, security, and engineering.