Anti-FAQs
LinearB is not for everyone

Our founders Ori and Dan, who were dev team leaders before starting LinearB, were frustrated they had nowhere to go every morning to see what was happening with their teams.

Git tools are code-first and designed for developers. Project Management tools are plan-first and designed for PMs. Dev leads live between those two worlds and have to blend technical and business together to make decisions and hit delivery deadlines.

Other dev leads they talked to described the same problems:

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.

Lack of alignment. Translating engineering to executives is hard enough. Without concrete data about how your team really spends their time, it’s impossible.

LinearB was built to solve all four of these problems.

There’s nothing here to manage. Once you connect your Git and project systems, LinearB just runs with zero manual inputs. Many of our users never even login to LinearB. We alert you to important updates, risks and blockers right in Slack. It is definitely another thing to look at though. In fact, we think it’s the layer of context between project and code that dev teams have been missing

Maybe. But not easily. And not in a way that is purpose-built for the meetings you run every day and the decisions you make every hour.

Compare your current project board on the left to the LinearB devboard on the right.

Better yet, pull up your current board and see if you can answer the questions below.

Bonus question: How many clicks would it take in your current project management system to get answers to all of these questions?

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 effects the thing you care about – when the new feature going to be released.

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 we really work.

LinearB solves this by actually learning how you work. We adapt to your scrum, kanban or customer process. We learn how you do releases. We accommodate every possible team structure including squads, guilds, tribes and every combination thereof.

Absolutely. Git tools have some good data. But those metrics lack awareness of what’s happening with projects, features, bugs, etc. So they don’t help you see how Git work is effecting project delivery. We take Git analytics to the next level by correlating and analyzing Git data plus actual code, project data and team interactions. The result is metrics that are team-oriented and focused on project delivery.

Totally. Pull Panda has 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, we do two things that are 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 bigger picture risk to your deliverable that a single alert would not help you see.

In other words, this feels big-brothery. We totally get it and LinearB could not be further from that.

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.

Things are great on your team. That’s awesome. There’s one use case where LinearB universally adds value… the daily stand-up. Check out this article 16 ways to make your daily stand-up better with LinearB. We guarantee you’ll find a few ways to make your daily meeting more efficient and more dev-friendly or your money back. Ok… LinearB is completely free for individual teams, but you get what we’re saying 🙂