August 7, I joined the Office Hours our Developer Relations team runs on a weekly basis, to talk about how we work at k6. We are growing rapidly, and are a little unconventional in how we organize ourselves, so I thought it would be a good idea to share in more detail how we build and ship software, being a remote-only company.
We're Hiring!
We currently have 17 open positions, across the organisation - mostly in Engineering, but also in Sales, DevRel, etc. We're at 30 people now, so that's quite the explosive growth we have ahead of us. In this post we will explore how we aim to achieve rapid growth while staying productive.
About a year ago we changed the way we work. We needed to change the way we organize ourselves because we outgrew the previous system. We have noticed that every time the company doubles in size, the system we use at that time stops working for us: time for a change.
It turns out you can’t run a company of 30 people the same way you run a company of 15 🤷
Throwback time!
When a company has 4-5 team members, very little organization is needed. Everyone knows what to do because everyone can speak directly to everyone else. At this size there is no need for a formal process.
However, when k6 grew to 10-12 people, that model stopped working. Before we knew it, we spent half the week just talking to each other.
At this point we tried many different things: 2-week sprints, 4-week sprints, sticky notes, standups, Scrum, estimates, flows, streams and an endless number of ticketing systems. Most of these processes and tools sounded good in theory but for whatever reason didn’t work for us.
What ended up working was: a clear vision shared by all team members and one Trello board implementing Kanban. Our lists were: Incoming => Backlog => Doing => In staging => Done (in production).
Everyone knew what to work on (top of Backlog), everyone was able to see what others were working on (Doing) and what was close to being released (to staging). On top of that, the system required minimal maintenance, so it was always up-to-date.
Individual impact on the product roadmap
At k6, developers build tools for developers. We are the target audience for our own product. As a result our Product team may own the strategy and long term vision for k6, but our engineers are empowered to drive smaller scale projects and individual tasks themselves.
We do not spend much time writing down detailed requirements. We discuss larger projects with individual engineers, and leave it up to them to fill in the details and to come up with solutions. It’s common that an 8-week project will have only 2-3 sentences of high-level requirements.
Individual engineers have real impact on the product roadmap, and make nearly all decisions about the details of implementation themselves. Managers don’t drown in tickets and minutia.
Happy little estimates
We continued with the above mentioned Kanban system until we reached about 25 people. With Kanban developers can take their time, because the work is only released when it’s done.
The downside then of our Kanban system was that it lacked time limits and scope of tasks. We acknowledged that it’s not possible to accurately estimate any non-trivial task, so we gave up on estimates.
When there are no estimates, no deadlines and no limits on scope, before long the scope extends and tasks take ever more time. We had a few “runaway” projects that took 6-9 months to complete. One monster project took 18 months to complete, and that was the trigger for changing how we work again.
Software Engineers are optimistic people, we often give estimates that have nothing to do with reality.
Whenever we give an estimate that sounds too good to be true, we know we're not likely to make it, but we're optimistic that in this instance we actually might.
The optimism often stems from the assumption that this time the development will go as planned, and we won’t encounter any surprises. In most cases that turns out to be false. Then we say things like "If I didn't have to do this other thing that just fell in my lap, it would be done already" or “This other feature needed to be added because it just makes sense to do it at the same time” or “If we are adding this feature, we must refactor X because otherwise it’s going to be too much maintenance in the future”.
From the technical perspective all these explanations are true, but then there's holidays, hiring work, and we're all swamped with urgent-but-not-important work. Maybe so much time has gone by that merging / integrating has become non-trivial. By that time you sank so much time into this project already, you can't just drop it. I mean, what's 4 more weeks after 6 months?
I love deadlines. I like the whooshing sound they make as they fly by. Douglas Adams, The Salmon of Doubt
For our open-source product our no-limits kanban process resulted in irregular and infrequent releases. Between July 2018 and July 2020 we had only 5 releases.
In July 2020 we amended the process to address two problems:
- Make releases regular
- Get more control over “runaway” projects
Enter the 8 week cycles
We now work in 8 week cycles. We have decided that 8 weeks is long enough to produce a new k6 version. It’s also short enough that we have to prioritize and spend the time on what matters.
Six weeks of the cycle are dedicated to implementation. The remaining two weeks are for cooldown. During cooldown we plan the next cycle, as well as work on technical debt, refactoring and other tasks that are not driven by business. The 6+2 cycles create a balance between business-driven projects and developer-driven projects.
We have picked up this idea from the Shape Up process.
We noticed that stress levels reduced dramatically now that it was clear when implementation ends. We don't automatically extend the timeline for a project that isn’t finished within those 6 weeks. We have a hard look at it and decide whether it's worth it to continue working on it or if we should scrap it. That has been our biggest take away from Shape Up, and it greatly reduced runaway projects.
Each team is responsible for the prioritization and their own backlog. We expect that the k6 mission - providing the best developer experience for load testing - guides decision making. Robin (Gustafsson, k6 CEO) and I then look over the list, and offer feedback because we have that high level / meta hat on.
We create Slack channels for the different projects (#proj-xyz), and ask engineers to update those channels for higher level management to get a feel for the status. Not a single team has a standup, and with regards to tooling or meetings we believe in self-organized teams.
Red, Yellow, and Green 🍏
At our fortnightly company sync we use green, yellow, and red indicators. Those are estimates for the likeliness something will be released into customers hands at the end of the cycle. Until the last day of a cycle engineers tend to be convinced they'll have it ready.
Finished is not just "works on my machine", that's why we do the evaluation every 2 weeks. Still it's a forecast, not a promise. The tendency to expand scope is smaller because you might turn a project that is green into a project that could be red.
We release extensions and services all the time. Those don't have to wait until the end of the implementation period. The Frontend team for example ships to Prod 2-3 times a week. The Backend team at minimum once a week. And peer reviews are done within the team, according to the 4 eyes principle.
What's next?
After a year of experimenting with this method we feel like it works for us. Sure, we could do better in terms of shielding the cooldown period from being used for runaway projects / scope creep. There's also a risk of using this time for writing documentation or release notes, while really those tasks should be part of the implementation phase.
As a next step we'd like to get better at telling the community what we plan to work on, instead of just marking tickets with milestones (here and here). We encourage you to hold us accountable!