LinearB may not be for everyone
We’re building the most helpful tool we can for engineering leaders and their teams. But nobody’s perfect.
Git tools are code-first and designed for developers and team leads. Project Management tools are plan-first and designed for PMs. LinearB is for the engineering leader who must move beyond “In Progress” to understand how things translate into efficiency, cost, and business impact. Our founders Ori and Dan, who were engineering leaders before starting LinearB, were frustrated they had nowhere to go every morning to see what was happening with their orgs. They also hated answering (really guessing at) the same questions over and over again:
- “When will this feature be ready?”
- “Can we speed this up and deliver this month instead of next?”
- “Can you take on this other ‘high priority’ project?”
- “What is this project going to cost and what will our ROI be?”
- Lack of visibility. Most teams aren’t great at project hygiene which means the board is outdated and incomplete.
- Lack of detail. “In Progress” means 100 different things so you have to piece together the details from different people and tools.
- Lack of insight. Dev leaders can only solve problems if they know where to look. Without seeing the bottlenecks, you can’t fix them. Many of the tools available today only provide shallow visibility into operational metrics–starting and stopping with DORA or measuring lines of code.
- Lack of alignment. Translating engineering to executives is hard enough. Without concrete data about how your team really spends their time or how they’re allocating their resources–and how those decisions impact the business–it’s impossible.
- Lack of workflow optimization. Other tools made specifically for devs are overly focused on helping them code better–which is only about 25% of their day. The non-coding work–meetings, status updates, planning sessions, housekeeping, code reviews, and meeting merge standards–is what needs to be streamlined to maximize productivity and keep devs coding (their happy place).
CI/CD tools can’t identify bottlenecks in the first 50% of your delivery pipeline. With LinearB, you extend your team’s ability to program workflows back to each pull request to unlock efficiency for every contributor in your org. The biggest problem with CI/CD tooling–along with git, PM, and other SDLC tools–is their fragmented nature. They provide an incomplete, disjointed picture of engineering health which negatively affects a leader’s ability to make correct decisions and effectively plan their strategies. LinearB correlates data from all these tools to provide holistic visibility (as well as proactive improvement suggestions) across the entire SDLC.
Our dev team has the exact same problem with our project management tool. As flexible as many project tools can be, they are not developer-first so they can force dev teams into a workflow that does not necessarily reflect how they really work. We solve this by learning how you work and adapting to your processes across team structure, policy, and release strategy. In other scenarios, like teams that develop mobile apps, the standard application of things like DORA metrics may not make the most sense. Rest assured that LinearB adapts to you by offering:
- Flexibility in how to detect releases with a powerful API
- Automatic outlier filtering so data is always accurate
- Customized views of your metrics
- Automated pattern recognition and visualization
Good news: there’s nothing here to manage. Once you connect your Git and project systems, LinearB just runs with zero manual inputs. In minutes you’ll be able to start building an engineering metrics program with DORA metrics, leading indicators, and benchmarks that tell you how you’re doing. But that’s only the visibility aspect of the platform. We then help your team align on improvement goals, set data-backed OKRs, and keep those initiatives front and center. We alert you to important updates, risks, and blockers right in Slack or MS Teams. We also enable devs to review, approve, and merge code from Slack and Teams. And we’re always looking for ways to get closer to where developers do their work – namely the IDE – to help them ship higher quality code faster. It is definitely another thing to look at though. In fact, we think it’s the layer of context and streamlined operations between project and code that dev teams have been missing.
Feature delivery is shared language between engineering and the rest of the business. Now you don’t have to wait for quarterly retrospectives or QBRs to see and present this data. Engineering metrics–especially quality metrics (code churn, change failure rate, mean time to restore) and efficiency metrics (pull request size, cycle time, deployment frequency)--translate to predictability (new features delivered, promises kept). And predictability translates to business outcomes (read: the things your CEO cares about): ROI, added revenue, better CSAT scores, and higher retention. LinearB makes it possible for engineering leaders to become more predictable, accurately forecast delivery dates or delay risks, and showcase business impact metrics in real time. Now you’ll land the message that engineering health is business health and have the data to prove it. LinearB helps teams find bottlenecks, set goals to improve, automate good habits, and become more stable and predictable.
Unfortunately out-of-the-box reporting from your project management tool is....not great. It only accounts for the data within that tool, unlike LinearB which correlates data points from across many tools in your stack. Without multiple data points, you won't have a holistic view of what is actually happening and why. Compare your current project board to the LinearB dev board. Notice anything? Better yet, pull up your current board and see if you can answer the questions below. Questions:
- Which devs are contributing to this feature?
- What branches and PRs are associated with this story?
- Have we actively worked on the branches and PRs for this story every day this week?
- How close are we to submitting this branch for peer review?
- Which PRs associated with this story have been merged and released?
- Which project issues are experiencing delays or have risks?
That’s true. The problem is, project management statuses are shallow. “In progress” and “In review” don’t really tell you much. Most of the time new features are made up of multiple branches being worked on by multiple people. In order to know the real status of your feature, you need a lot of info – What is the detailed status for every branch and PR? Is any of the work high-risk or blocked? What dependencies are likely to slow us down? What PRs have already been released? We automatically show you how all of that detail affects the thing you care about: when the new feature is going to be released.
It’s great that you’ve gotten some visibility into your processes and now have a baseline of your team’s cycle time. Quick question: Is your 8-day cycle time good? What about the individual metrics that make up your cycle time (like pickup and/or review time)? Do you have visibility into those metrics? If you do, are your team’s metrics in-line with your peers in the industry? LinearB not only provides metrics into all of these lagging and leading indicators of pipeline health (not to mention automated workflows to improve), it also provides your team with context and a baseline of what “good” looks like. Check out the Engineering Benchmarks, which are built right into LinearB. These metrics benchmarks come from analyzing thousands of dev teams and millions of branches. They provide teams with an understanding of the metrics that matter most and what success in each of these areas looks like.
Totally. Other tools have some cool Slack alerts and Teams channels can now subscribe to Github activity. Those are great features and, when it comes to alerting you about PRs that are stuck and need attention, we have some overlapping features. But we go much deeper. When it comes to real-time alerts, do three things that are REALLY special: We analyze your code to find risks. For example, we know that a high number of code changes combined with a high rate of rework has a high correlation to bugs. So we look for that dangerous combination and alert you when that “high-risk code” is present so you can assign additional reviewers. Our alerts correlate your code with your project stories. So, for example, we highlight when you have several blocked PRs and high-risk branches that are all related to a single feature. This helps you see the bigger picture risk to your deliverable that a single alert would not help you see. When an alert is fired by LinearB it provides lots of context about the PR–including who owns it, what’s in it, how long it will take to review it, and information about any improvement goals you and your team have set for yourself (like picking up PRs in a day or reviewing them in two days). And our PR-Policy-as-Code tool, gitStream can do even more–helping you build consistent and standardized merge policies for a smooth and scalable PR process.
In other words, this feels big-brothery. We totally get it and LinearB could not be further from that. We firmly believe that no-one wants to be tracked on an individual basis which can be used for culture-killing stack ranking. LinearB is all about team improvement, so naturally we are strongly opposed to Git analytics tools that focus on individual performance metrics and stack ranking developers. We’re hyper-focused on using data to help dev teams to deliver more value as a team. And we have absolutely zero individual performance stack-ranking in the product. In fact, LinearB has tons of features to help you deliver better that have nothing to do with performance metrics. Look closely and you’ll see we’ve built in guardrails to ensure your devs feel comfortable with LinearB and your managers are using their new power for good.
We believe you. It’s just really hard and time-consuming. Our founder Dan had to allocate one day every week for one of his data engineers to pull data and organize it the way he needed. If you’re lucky enough to have a dedicated data engineer, compiling reports is probably not the best use of their time. Most teams don’t have that luxury. With LinearB, building a comprehensive metrics dashboard with the information you want can be done in a few clicks.
We have a rule at LinearB: no shelfware. In that spirit, we want to make sure that anyone who buys–or tries–LinearB moves beyond just visibility and metrics and actually does something with these metrics to drive meaningful improvement. Check out how you can use LinearB to build your first metrics program and improve in one one of these key areas:
Fair enough. It’s really great that things are going so well on your team. But here’s the thing, because LinearB correlates data from several sources and automatically surfaces insight, it can shine a light on bottlenecks you didn’t even know you had. So it can remove the “pretty” and replace it with “extremely. ”As an engineering leader, you’ve got a tough job–which is really two jobs. You’ve got to drive operational excellence with a budget that is either flat or shrinking–so more headcount is probably out of the question. The only way to meet this mandate is to find inefficiency wherever it exists and improve your processes. You’ve also got to drive revenue by delivering on promises and aligning to the priorities of the business. You can only do this with data that cuts across engineering and the rest of the business. In down markets, tools that improve your existing processes and help teams scale efficiency aren’t nice to have. They are imperative.