At Isometric we talk a lot about Do it Fast, our Operating Principle which expresses that speed of execution is one of the defining characteristics of how we get things done. This informs how we organize internally, how we plan and execute work, and how we hire.
Before explaining how we work at a high velocity, it is important to note we think about fast as delivering value to users quickly, at a speed that can be sustained over time. Fast is not a rapid dash to the end of a project, at which point your people collapse due to workload and your systems buckle due to poor technical choices. Rather, fast is a sustained, user-focused, stretch in which, no matter how well you are doing, you always look for ways to deliver things faster today, faster next week and faster every week for the next 12-18 months.
There are a couple of axes on which Isometric strives to do this. Firstly, we look at the speed of technical delivery and how we can optimize the time from an engineer starting work to it being in production. We look for incremental, compounding time savings, which quickly stack up to hours and days. We try as much as we can to auto-generate boilerplate and avoid repeated toil —we have completely auto-generated docs, to give one example. We leverage rich and strict static types in order to make code easier to read and understand. We depend on comprehensive unit tests so you’re less likely to have to go back and fix regressions (we also do this), but also have a strong bias against long-running, non-deterministic and flaky tests that lead to lengthy Continuous Integration and a slow feedback cycle.
When development speed slows down, we make concerted efforts to address it. It might be by implementing setup scripts that mean that everyone has a consistent, easy-to-maintain local environment so minimal time is spent debugging avoidable dev environment issues. That might be investing time in better parallelisation of unit tests to cut their running time in half. It has even included upgrading M1 laptops to M3 laptops early for engineers where this would have a significant impact on their development velocity.
Additionally, we look for optimisations across the software delivery lifecycle, from idea through to measurement and to evaluation. Some of the things that we do that have been consistently present across the high performing teams I’ve worked in are:
Only build the things we need to build
We try to have a highly focused approach as to who we’re actually building for. For example, our verification API was built with specific users in mind. By continually bringing discussions back to the user, we avoid slowing down delivering user value via building the wrong thing. Furthermore, all of our product team have significant exposure to the real users we’re building for. It’s not unusual for each engineer to spend one or two hours a week joining calls with carbon removal suppliers.
Prefer to collaborate as soon as needed
Great people try to solve problems as close to instantly as they can - they kick down roadblocks to get things done. Often teams create processes to make things less chaotic. Instead of having on-demand discussions around blockers or uncertainties, they are batched together into a meeting. Hearing ‘lets save topic X for our scheduled weekly meeting’ can rapidly devolve into people waiting 4 days until a weekly meeting to expose an idea, give feedback on a proposal or tackle a problem. Process exists to reduce variance in speed and quality of output, but it also reduces the space for people to excel? If you can nail anything else by having smart, highly-aligned, autonomous engineers, you need a fraction of the process you might expect.
Hire people who understand what it means to build things fast
We intentionally only hire experienced engineers who can make mature, balanced technical decisions. We don’t compromise our standards on who we hire, even if we feel an urgent hiring need, or even if someone has a lot of great traits but not the full package. Hiring teams need to deeply understand that the cultural characteristics to hire for aren’t just people that seem nice and friendly. We’re looking for people with high intrinsic motivation; people who appreciate simplicity and despise over-engineering and premature abstraction; who love technology, but for what it enables us to do, not in and of itself.
Give a high level of autonomy when executing on the details
This relies on nailing the above two things, and having a high level of organizational alignment, so that you can grant people autonomy to execute without fear or needing continuous approval. Sometimes organizations don’t want to give autonomy because they are worried that their people will build the wrong thing, or maybe aren’t even capable of building the right thing. However, if people need to check every detail with a gatekeeper, a lot of time ends up spent on process, discussion and iteration. And within these discussions, the final outcome may be slightly better, but the juice is not worth the squeeze. And the end result of it all - delivery slows down.
Empower people to succeed
One of the reasons individuals slow down is due to uncertainty over how their peers, managers and the organization might react to their work. Fear that one might be punished for getting something wrong leads to over-checking, self-criticism, and a need to form a shield of consensus rather than act decisively. Instead, people must be empowered to act decisively, with the understanding that occasionally, they will get things wrong, but all the other times, if alignment is here, and user-focus is clear, and the people are senior and skilled, they will get things right really quickly.
All of this isn’t to say that we’re perfect at Isometric. There are tasks and projects where we don’t go as fast as we like. When this happens, we act with a high degree of trust, give well-considered, deep feedback on ourselves and each other and retrospect on what can and should be improved for next time. We're always looking for engineers that fit these criteria. Check out our Careers page to learn more.
