LinearB — The Quest for Engineering Productivity 🔮
The story of the company that wants engineers and managers to work well together.
When Ori Keren was a child, he made a promise to himself: “when I am a parent, I will never forget how it was to be a kid”.
He has two kids now, and that promise has stayed with him ever since.
About 20 years ago, when he started his career as a software engineer, he also made another, similar promise: “when I am a manager, I will never forget how it was to be an engineer”.
And a few years later, he was put to the test.
He rose through the ranks, first as a team leader, then as a manager, director and, later, VP of Engineering—twice—leading teams of up to 100 developers. Over time, he went from solving problems for himself, to solving problems for other engineers, to solving them for managers.
Eventually, he decided to build a product to do so at scale.
LinearB is a peculiar company and one of my favorite tools. I met Ori and his co-founder Dan Lines when they started the Dev Interrupted podcast. I thought it was smart how they engaged with the engineering community and used those conversations to shape the product. I was a guest and we've stayed in touch ever since.
Over the last two months I sat down with most of their team to learn more about how they work and how they think about all things engineering.
So, this article is a deep dive into LinearB’s culture, processes, and product. Or I should say products—plural. Here is what we are going to cover:
🔮 Vision — an opinionated vision about the future of collaboration between engineers and managers, and how software should help.
🎨 Product — how LinearB is executing on that vision through a clever suite of tools designed to help people across the whole org.
🔄 Processes — a case study on the workflows of a tight-knit product/engineering team, navigating a very complicated space.
Let’s dive in!
This piece was written as part of the 🌀 Refactoring Partner Program.
The program is an opportunity to work with exceptional engineering teams and write deep case studies about the way they work.
You can read about the guidelines I adhere to in the link above. I always note partnerships transparently, and only share my genuine opinion.
Feel free to reach out to share your feedback about the piece!
🔮 Vision
As a manager first, and manager of managers later, Ori spent most of his time figuring out how to enable other people to do their best work.
Over time, he created a simple framework for this. It is called ETA, which stands for Experience, Tempo, and Alignment:
💻 Developer Experience — for an engineer, bad DX is like death from a thousand cuts. Good DX, conversely, makes people happy and enables their growth.
⏱️ Engineering Tempo — tempo is about efficiency. You want to ship fast and often, break down work into small items, and recover fast from mistakes.
🎯 Business Alignment — going fast is only helpful if you are going in the right direction. Alignment is about knowing what you spend your time on, to intentionally balance your engineering investment.
Experience, Tempo and Alignment live on a spectrum that goes from mostly engineering-related, to mostly business-related.
The idea behind the framework is that a team works well only when all these parts do. Likewise, the relationship between managers and engineers is a partnership: it works when each side does its own part.
Today, optimizing ETA is the north star of LinearB, but, back in the day, things were not easy for managers who aspired to be data-driven. In Ori’s own words:
I am a data person, so I wanted to collect data about how we were doing on any of this. But there were no tools for this. So I started collecting data from JIRA and Github manually, to analyze where people were spending the most time, and figure out how I could help them.
But it was hard — I would have wanted to have this on a daily or weekly basis — but I barely did it once a quarter because it took a lot of time.
LinearB started as a reporting product, where its audience were managers, like Ori, trying to improve engineering productivity.
Over time, though, they figured out that this wasn’t enough. To help teams truly grow, they couldn’t focus on one side only. They had to address the workflow of the whole engineering team — both engineers and managers.
And that’s what makes them unique 👇
🎨 Products
The engineering analytics space is very young.
I tried the first reporting tools about 3-4 years ago: they provided a lot of data about so-called engineering productivity, like the number of commits, PR turnaround time, code churn, and more.
The problem, though, was how to use this data for good.
Eran Shitrit, VP of Product at LinearB, echoed this when I talked with him:
The biggest challenge at the beginning was market education: tech leaders didn’t know they could leverage data for productivity. So we always tried to operationalise this data: to make things more standard and give people direction, other than numbers.
Data visibility is the beginning — the real goal is to improve processes.
Back to ETA’s holistic philosophy, the idea is that you can’t help managers if you are not also helping engineers — and vice versa.
So, that’s where the other products kick in. Today, LinearB’s brain is split into two halves:
📈 Reporting tools — to help managers figure out where to improve. Primarily through the flagship LinearB product.
🔨 Workflow tools — to help engineers focus, so they can write better quality code, faster. Through the free helpers WorkerB and GitStream.
This may seem like a daunting portfolio for a still small team of ~30 developers, but this team has a super power: they are their own first users. Gal Rubin, Senior PM, weighed in on this:
We are able to do this because there is a close intimacy with our customers. We are just like them, so we dog-food our tools all the time. We primarily design tools to fix our own problems.
To counter the risk of spreading too thin across many products, they strive to create synergies so that each one makes the others better and more useful.
Let’s see the three products that make up LinearB’s engineering efficiency platform:
LinearB
LinearB is the original tool that the company developed. It is a reporting solution for managers and tech leaders to increase team productivity.
Following the ETA framework, LinearB helps with Tempo and Alignment.
Tempo — it measures Engineering Metrics, like DORA, to identify bottlenecks and opportunities to improve.
Alignment — it includes a Project Tracker that connects to Jira, Shortcut and others, to automatically provide a breakdown of the investment profile, planning accuracy, people effort, and more.
For each metric, LinearB also provides industry standards and benchmarks, based on data from their own customers. The goal is to help you assess where you stand and what you should aspire to.
WorkerB and gitStream
WorkerB and gitStream are, instead, genuine developer tools. They help optimize the dev process by automating manual tasks and standardizing best practices.
They were born out of LinearB’s experience analyzing the metrics of hundreds of teams, to figure out how they could help further. And, for most teams, it turns out that the biggest bottleneck of all is around pull requests.
This is unsurprising. I spoke with several teams myself when I wrote a previous article about code reviews, and most were unhappy with their process. Many of them have great CI/CD pipelines to deploy code in a few minutes, just to see the same code sitting idle for hours (or days!) waiting for review.
So, WorkerB is a helper, that lives inside the team’s chat, to streamline simple tasks, like approving small PRs, finding reviewers for unassigned ones, reporting those merged without review, and more.
gitStream, instead, lets you define workflows around reviews, based on a PR’s content.
You can configure rules based on factors like PR size, sources, or missing tests. These rules, in turn, can trigger actions, like auto-merging, assigning custom labels, requiring specific reviewers, or automated change requests.
gitStream can also figure out a bunch of stuff by itself, like the best reviewers, based on past contributions 👇
🔄 Processes
At the time of writing, LinearB has around 90 employees, out of which 30 are engineers. 6 PMs work with engineers across the three products.
In product / engineering, there are two main teams: one that owns the traditional reporting product (LinearB), whose audience is managers and tech leaders, and another that owns workflow ones (gitStream & WorkerB), whose audience is developers.
These teams are largely independent but share many of the same practices. Let’s look at them.
Remote work
LinearB is a hybrid-work company.
In their Tel Aviv HQ, they allow for 3 remote days/week, plus 2 days at the office. One of the two office days is the same for everybody, which is helpful for bonding and to execute stuff that requires big gatherings, while the other is free for anyone to choose.
They also have a distributed US team that has the option of coming into WeWorks, but is fully remote by default. They are also hiring.
Dev Process
All teams in LinearB work in 3-weeks sprints. For them, this strikes the right balance between being able to work on big features, and steering the ship fast when needed.
Releases, though, are not done only at the end of each sprint, as in classic Scrum. The team makes 3-4 releases a week, with ~7-8 deployments a day.
Sprint ceremonies are kept to a minimum: at the start of each new sprint there is a 1-hour planning session, and a review + retrospective about the previous one.
They prefer to hold reviews and retros at the beginning of the next sprint instead than at the end of the current one, because during the latter people are usually busy with wrapping up tasks and they don’t feel like spending time on ceremonies.
Teams generally don’t do standups, but these more granular routines may vary based on the work to be done, and are left to individual teams/sub-teams judgment.
Planning
LinearB plans work on a quarterly basis.
Items on the product roadmap combine feedback and insights coming from four main sources:
🗺️ Company Strategy — the main line coming from founders’ long-term vision.
📣 Customer Success — feedback from current customers. Crucial to retain customers.
💼 Sales — feedback from prospective customers. Crucial to acquire new customers.
🎽 Team — bottom-up ideas coming from the team, as first users of the tool.
Combining these sources is not easy. Especially because inputs come at different times, with different granularity, and different urgency.
The result is that, with respect to an initial plan, the actual work can change a lot during a quarter. When unexpected opportunities come up, the team may jump on them and ditch part of the planned items.
While this may feel frustrating for those who like a well-made plan (myself included), it is also 100% healthy. Sticking to a plan is only good if what’s in the plan is actually better than what is not — and in a startup environment, there will always be opportunities you are not able to anticipate.
In my previous startup, we did quarter OKRs and we eventually settled on allocating 50% of the team’s time on them. We knew that if we planned for more than that, we would either 1) fail them, or 2) win them at the expense of other, possibly better items.
Teams should always give themselves a bit of slack to avoid tunnel vision and retain the mental agility to find new ideas.
Product / Engineering Relationship
Avishag Sahar, Engineering Team Lead, explains to me that for new features, engineers on each team talk with product from day one.
This is crucial not only because it leads to better scoping and specs, but also because, in this case, engineers are actual domain experts for the product.
While this synergy is particularly strong because of LinearB’s space, this is more generally how successful teams work. In the best teams, good prod/eng relationships are not a one-way handoff — that is, designers pass requirements to developers, and developers just write code. They are a continuous back and forth collaboration, in what Brad Frost calls “The Hot Potato Process”.
Scoping / Estimates
At LinearB, product people iterate with engineers on a cycle that tries to stay one week ahead of the actual development sprint. When a feature is planned for the sprint, scoping and estimation is already there, so the sprint can focus on implementation and refinements.
When it comes to scoping, Avishag tells me that the #1 obsession of the team is breaking down work into small tasks. They actually call them microtasks, because they strive to keep each of them within 1 working day.
They also do estimates using story points, where each point roughly equates to 1 working day, and use this to get a ballpark of what can fit into each sprint.
The core of planning, though, is the microtasks practice. Breaking down work makes the estimation process trivial and… peaceful. Engineers stay in charge of estimates and there is virtually no negotiation, avoiding the vicious cycle of inflated estimates 👇
❤️ What makes you the most proud?
I asked this question to every single person I interviewed at LinearB. Here are the two most common answers:
1) Product scope
LinearB’s vision of developing products for the whole team, both managers and developers, is unique, and people at the company love it. LinearB’s people genuinely feel they are on a mission.
2) Collaboration
People are happy with how they work together on the product. This is thanks to 1) a transparent roadmap that everyone can see, 2) product people working with devs from day one, and 3) scoping and estimates being peaceful and owned by engineers.
🔨 What is something you should improve?
If people had a magic wand, here is what they would make better:
1) Maintenance
In a fast-growing startup, maintenance is tricky. Requirements change all the time and it’s hard to keep tech debt in check.
LinearB’s team spends a full week on quality every two sprints, but they feel they can do better. In the future, they want to invest in a dedicated backlog of maintenance tasks, and create a lane of work dedicated to DX.
2) Communication
The most challenging issues that come from growing rapidly are about communication.
While it used to be easy to keep stakeholders aligned about the product, things are harder now that the company is almost 100-people strong.
Product people have three main communication duties:
🗺️ Communicate roadmap (future work)
🚥 Communicate status (current work)
🆕 Communicate new features (past work)
This used to be done on simple slack channels — now it is a fully-fledged process that involves product, engineers, sales and support people.
For each new feature, the team needs to:
Provide ETA expectations for sales
Write docs at different level of granularity for the various stakeholders
Train sales and support people
Announce to customers and reach out to them to boost adoption
This is a complex process that is being continuously refined.
📌 Conclusion
I spent several weeks researching and talking with people on LinearB’s team.
Given how much we hear around engineering productivity, it feels strange to say that this space is still very early. Yet, that’s the truth. Most tech companies out there do not use engineering analytics tools, nor make an intentional investment in the DX of their team.
This is bound to change in the coming years. There will come a time where we will discuss engineering metrics and practices in the same way we do with CPA or LTV with sales people — that is, as standards.
This is already happening. In the last few years we got the DORA metrics, cycle time, and today, for example, some healthy conversations about PRs.
LinearB is on the right side of history, but it will be a bumpy road. To be successful, they have a two-fold task:
Educate customers about the best way to build software
Create a product(s) that helps them with that
Doing both is hard.
The beauty of early spaces, though, is that they grow fast. So they may be doing a supremely hard thing — but with the wind in their sails.
This, to me, feels like the true essence of startups 🚣♂️
If you want to try LinearB, as a Refactoring reader you get 20% off on any annual subscription 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️
Luca