When you join a new company, especially a startup with a small team and a fluid, fast attitude, it can be hard to understand what is the shared vision that you’ll be involved with. Each team will want to do the best job possible to benefit the business, but what are the guiding principles on which to base our decisions?
Being a software engineer: coffee, pizza, and trade-offs
One of the core aspects of this job is that whatever you do, you can never have your cake and eat it. Any software engineer who has spent enough time on the job will have encountered the CAP theorem. That’s the perfect exemplification of the kind of choices we face on a daily basis. There is almost never a “one size fits all” answer for any of our challenges: the context we’re in will heavily inform us when we strive to find the best possible solution for a problem. I’ve recently joined Driftrock and I set the personal objective to underpin a set of guiding principles for our team, so that whenever we need to make a call on a certain trade-off, we have a North Star to inform us.
The process started by gathering feedback from the rest of the team. We devised a form with aspects of the job we value, and allowed only a handful of them to be picked by the respondent. Some aspects emerged very strongly, showing we already had a common vision of what’s important to us. We then discussed the results, to confirm that everyone could relate to them, and check whether there was something clearly missing from the list. This is what resulted out of the process:
- Data should guide our decision-making
- Our product should be easy to change, simple, testable, maintainable
- Deliver value, early and often; gather feedback; repeat
- Our opinions should be strong and weakly held
- We value automation
- We want to always measure and improve (ourselves and what we make)
- Don’t shy away from debate, and agree to disagree
Out of sight, out of mind
While these all seem obvious Good Things™ that any team would try to achieve, what happens in the negative space is just as important. To an extent, this list emerged in contrast to other values that were seemingly as important, but weren’t prioritised. For example, you might notice that being on top of the latest tech advances is not part of the list: while we’ll do our research on new stuff, we will prefer something battle-tested for our production stack. Another notable absence is performance: we’re still growing (fast!), and while we keep an eye on bottlenecks, we don’t feel the need to spend weeks optimising everything to shave those 2 milliseconds off a certain endpoint. Another example: while we like Go, we’re sticking with Ruby as we don’t need the performance boost (not just yet, at least).
A useful exercise
I thoroughly enjoyed the process of coming up with this list. Spending a bit of time on this yielded some excellent returns. This kind of exercise can help to shape a shared view on the job, and bring a team closer together.