Building at BV: How we work - What’s important
I've been at BrandVerity for almost 3 years and I'm really proud our willingness to try new things.
When I joined our process was pretty informal. We used a poster board and moved sticky notes in a kanban type setup. Everyday we'd have a stand up and we'd talk about the tasks, sometimes in great detail.
If something was urgent we'd add it to the board. If one of the engineers thought something needed to be done, they would do it. To be honest it worked pretty well for the small size of our team (5 developers at the time).
Fortunately, we were able to keep growing and we quickly discovered that the stickies on the poster board didn't quite work for us anymore.
As the team/company has grown we’ve tried several new processes. Some of them we’ve kept, some didn’t work for us. But we always try to meet these high level goals:
Dev Process Goals:
- Self Direction
- Low Overhead
- Longer Term work over Short Term work
- An Easy On-call
In the next post I’ll go through the nitty-gritty of our current process but for now I want to touch on these high level goals.
We value self organizing and self directed people. We start by agreeing on high level priorities then allow every engineer to self select tasks they are going to work on. This allows for people to self manage both time and individual priorities.
We also don’t write up detailed specs for every single task. Some tasks are more of a general problem ‘Why didn’t we crawl this’ or ‘Why did our system find this’. We look to each engineer to take a look, understand the problem and collaborate with the team to get it solved.
We also encourage people to pick up tasks outside their area of expertise. I like picking up bugs/small tasks in parts the code I don’t usually work in so I can learn about them.
We don’t want to be spending time on processes - we want to build things! We’ve done this in a couple of ways:
- Avoid lengthy discussions in planning about things we know we are going to do (such as security updates)
- Don’t spend longer discussing a small task than it would take to do it
- In scrum or planning we’ll pause longer conversions and have them after the meeting.
We want to be able to adapt to changes. If a customer request comes in or there’s a new feature that’s important to do soon we’ll get started on it right away.
This also means being flexible and not worrying if we have to change plans.
Long Term work over Short Term work:
All things being equal - we’d rather be working on longer term problems, problems that give us an edge and are interesting technologies instead of doing small, random changes all day. Sometimes we live with things being not quite perfect but that means we get to work on hard, interesting problems.
An easy on-call:
- On-call is a shared burden for the dev team, but we invest in making it easy.
- We build our systems to be resilient (learn more about our architecture)
- We invest in fixing kinda-broken systems
- Alarms that are just noise we either fix or silence
On-call is a blog topic in and of itself, but because we are serious about great work/life balance we invest in making sure that being on call isn’t a burden.
In the next blog post I’ll get into the details of how we choose our work and how we organize our teams. Stay tuned!
If the way we work seems interesting to you - come join us! We’re Hiring!