Engineering culture
Last updated
Last updated
We came up with our as a team. We live them daily with every action. Engineering does not have a different culture but what we do is different enough that we want to call out its quirks and specialisations.
Engineers are warriors. We hone our craft over years of careful study and practice. We want to win the respect of our fellow warriors but, more importantly, we want to fight alongside warriors we respect. It is important for us to know how our fellow warriors operate.
Do they obsess over the shiniest new weapons or do they stick to rusty old tools?
Do they rush into battle or do they while away hours debating at the war table?
Do they go for individual glory or are they mindless cannon fodder for the general?
This document details how we warriors work.
We do not expect our teammates to tell us what we can Google. We learn most everything on our own and rely on our teammates for the extra special something that only they know.
We are proud of the work we do. We are happy to receive every code review comment we get and every bug someone finds because it makes us better. But it hurts that someone else found it before us.
We do not stick to our sandbox. We fix something that we see broken even if it is not our code because it is our code and our product.
We do not shy away from hard problems or rusty parts of our codebase. We find a way through them, not around them.
Duct tape and chicken wire can only take us so far. We aim for durable solutions that stick around for a long time. Rewrites are fun but they also mean we messed up the last time around.
We measure twice and cut once. We are thoughtful about architecture, scale, usability, and testing so our users always smile and our on-call never frowns.
We work on projects that we are passionate about instead of tasks that someone happens to assign to us. This means we raise our hands and pick projects. Even better, we come up with projects that make a difference to users and our team.
We go on quarterly hackathons, where we take on fun and ambitious projects and work on them at a kickass venue. Our best features and friendships have come from hackathons.
We use any opportunity we get to give ourselves the technical edge. This can mean building new technology from scratch, coming up with novel algorithms, or warping existing tools to solve problems they were not meant to solve.
We try to be the engineer others in the team look up to. We want to think deeper, have better ideas, test more, and ship faster.
We are voracious learners. We learn from books, courses, and videos like everyone else. We add to this learning from other engineers, other teams, and users.
We seek out the tough code reviewers and product users. We walk them through our code and features so we make them even better before shipping.
We ask for feedback that helps us become better. We do not wince at tough words but welcome them with open arms. Feedback is a gift that we never refuse.
We keep things as simple as possible be it in architecture, code, user experience, or words. Complexity is a shield that we do not hide behind.
We avoid premature optimization and over-engineering. We ship incrementally so we get quick feedback and users get quicker value.
We are in touch with the latest tools, techniques, and technologies. We bring them in when it is the right time even if it means a whole lot of unlearning for the team.
We voice our questions, concerns, or alternatives before it is too late. We prefer a quick discussion early instead of a complete rewrite later.
We understand projects deeply before we start them. We ask a lot of whys so we believe in the work we are doing. We push back until we are convinced of the impact, scope, or timelines.
We share improvements to features, technologies, or processes. Our best ideas have come from passionate engineers regardless of their designation or tenure.
We spot issues and difficulties early on and communicate them fearlessly. We defuse a ticking bomb, not run away from it.
We share the good news and progress on our work just as regularly. This ensures that we get more feedback and generate more excitement for the launch.
We are in touch with the code, tools, other teams, and users. This means we are in the best position to challenge assumptions, ideas, and processes. We take this responsibility seriously.
We keep an open mind to new perspectives and ideas even if it means changing how we work or killing our favorite ideas.
We give as much as we take. Even the most junior team member teaches the most senior team member something useful.
We follow a straightforward framework to think about everything we do - Problem -> Feature -> Impact. We start with the problem we are trying to solve for someone before jumping into implementing the feature. We then measure its impact to validate if we got it right.
We share. A lot. Slack notes, screen recordings, wiki pages, and more to help others know what we know even if they join years later. Our first instinct is to search the wiki rather than asking the person next to us.
We do not look at someone's designation or seniority before listening to them. Anyone is free to praise the good and share the not-so-good.
We do week-long on-call rotations where we are in the line of fire for issues and outages. This creates a deep empathy for our users, customer-facing teams, and other engineers who face the heat because of our coding mistakes.
We do not rely on filtered inputs from other teams. We get on calls with our users to understand how they work and how our product solves their problems.
Rocketium is a product company and so engineers are the heart of the company. We build the features used by leading business and design teams around the world. We are responsible for delighting or disappointing our users. For delivering or delaying business results for our customers. We do not take this lightly.
Our product makes our users be more productive and work more creatively. And that is why we keep reflecting on and sharpening how we work. We will keep updating this document as we learn more in the coming days.
We make mistakes that we feel bad about. But instead of just beating ourselves up, we go deeper into what caused it. Not just the immediate reason but what caused the immediate reason. And what caused that reason. Until we find multiple improvement areas. More at .
Lead contributor -