I have questions before I purchase a Flow business subscription

Traditionally, engineering has relied on narrative and subjective metrics like story points and tickets cleared to demonstrate business value.

Flow is an organizational tool, pioneering a different way of measuring and communicating about productivity in software engineering. 

Imagine the airplane pilot who has been flying by feel, finally having the instrumentation to make the flight more predictable and reduce risk. 

Flow provides engineering leaders with metrics in context to ask better questions and advocate for the team with substantive data:

• How much of your team's burn is going to refactoring old code?
• Did the change to our sprint cycle have a net-positive effect?
• How do Wednesday all-hands meetings affect productivity?
• How well do we share knowledge in code reviews?
• What did engineering accomplish last week?

By mining data in Git, we are able to increase visibility about team contributions, see where the biggest impact is being made, identify areas to give concrete feedback, and help teams understand how process changes impact the team’s effectiveness.

Flow is designed for leaders of software developments teams, including CTOs, VPEs, Directors, Engineering Managers, and Team Leads.

Basically, it's for anyone who is responsible for leading a software team—and tired of the interruptive shoulder-tapping, narrative accounts, and subjectivity of the past.

Managers tend to lose the intuition and visibility as their teams scale. I know the pain first-hand, because I used to be one myself. The larger the team, the harder it is to answer questions like:

• What did we deliver yesterday?
• How much burn went toward paying down technical debt?
• Why is the release running late?
• Did the process changes make things better?
• How do I know when someone is struggling, and how can I help?

This is why we built Flow—to finally answers those seemingly impossible questions. Flow is the tool of choice for data-driven leaders and helps software teams reach their highest potential.

Our pricing plans are described on the pricing page. 

Pricing tiers are based on the number of people actively contributing to your codebase, and the number of repos that we process. 

If your team doesn't fit neatly into one of the tiers, that's fine—all exceptional pricing is handled on a case-by-case basis.

All plans include a 15 day free trial.

Flow introduces a bunch of new ways of seeing and measuring software engineering work.

In the early days, when people tried the app without a little training, the most common response was: “This is cool, but what can I do with it?” 

Then we noticed something; our biggest fans and most successful customers had been personally on-boarded. So now everyone gets the white glove treatment. 

We want to be successful too, so I'm asking you to trust us on this one.

The demo takes 15 minutes, usually less.

From there, you'll get an invitation link to connect your repos and get started with a free trial.

We personally on-board everyone to make sure you get started on the right foot.

You can request your demo here. 

After the demo, you'll get access to a 15 day free trial.

Flow works with your current process, so there’s nothing to change in your workflow.

All of our reporting is automatically generated when your developers check in code. No more bothering people to update tickets, or interrupting people to ask what they’re working on.

Flow works with any Git repository, no matter where you host it. 

If your repos are available in the cloud or behind a firewall we will be able to connect to your codebase.

Flow is fully integrated with the following Git Hosts:

If you host your code in any of the below Git hosts, we will ingest your commit data, pull request data and tickets/issues. 

• GitHub cloud
• GitHub Enterprise
• GitLab cloud
• GitLab Enterprise
• Bitbucket cloud
• Bitbucket Server
• Azure Devops (VSTS)
• Team Foundation Server (TFS) Setup

Flow also works with the following vendors via HTTPS or SSH: 

• Assembla
• Beanstalk
• Kiln

Yes, we offer an on-prem solution for enterprise customers.

• 100% on your network. Flow never phones home and cannot transmit any of your information.
• Works with most cloud providers' VPC's and most operating systems.
• Setup wizard makes configuration easy.

We are language agnostic, so any coding language checked into a Git repo will work.

This question comes up quite a bit, and the answer is… please do! 

Let’s take a look at what gaming the numbers on a few key metrics might look like:

Unreviewed PR’s. Unreviewed PR’s is the percentage of merged pull requests that did not receive comment from the team. We want to establish a healthy review cadence to ensure that unnecessary risk is not introduced into the codebase. A focus on this metric also encourages knowledge sharing - Engineering organizations have world class minds who can aid in growth and career development. Gaming this metric ensures that we are catching bugs ahead of production, while making the team stronger along the way.

New Work percentage: If you’re a senior engineer, chances are you have higher than normal Legacy Refactor in your statistics. This is awesome, but it will naturally cause lower New Work ratios. The best thing to do here is pick your favorite junior engineer and help them get into the maintenance business with you: stop taking on all the risky work and spread the load! By doing this, you’ll be able to take on more New Work, which will re-balance your work trend numbers and ensure that new features contain healthy patterns for others to follow (reducing the amount of “other” work for the whole team, not just you!).

Coding Days: This one is easy — just push your work every day. No need to merge into a particular branch, Flow will see anything you add to the repo. As an added bonus, this is really good practice anyhow, since it increases visibility and makes sure your work is saved somewhere other than your local machine in the event of a hard drive crash. 

Time to First Comment. This metric encourages you to grab PR’s in a timely manner. Eliminating costly wait states is primarily a courtesy to your peers. Delayed PR review either creates a blocker for individuals on the team, or results in task switching which is arduous and inherently error prone. 

Churn: The most reliable way to game the Churn metric is to be methodical about incorporating any recurring feedback from your code reviews. Before checking in a commit, give your code a once-over and make sure you’ve handled anything that commonly comes up in your pull requests. Focusing on clean PRs is a great way to reduce Churn: pre-PR edits will nearly always show up as Churn in the reports. 

Time to Resolve. Time, in hours, it takes a pull request to be resolved (either merged or closed). Unresolved PR’s are costly to the business, and long running back-and-forth discourse has a tendency to become unhealthy. Establishing resolution targets helps to verify our work is not done in vain. Attention placed on Time to Resolve results in a decrease to delayed releases. 

So, can you "game" the system? 

Absolutely. The point is to "game" the system.

Consistently maintaining “good marks” in Flow, gives you a way to show, not tell, that the team is focused on the right areas and delivering meaningful solutions in the most efficient way possible. Ultimately it offers a path to reducing the miscommunication and political overhead that can come from working on things that are invisible to the rest of the business.

Well, sure you count lines of code, but why would you want to do that? 

As demonstrated by this story from the early days at Apple, managing by lines of code is kind of ridiculous. And it's not even clear how you would do it if you wanted to.

Reductionist metrics like LoC are incomplete ways to think about software engineering. After all, writing more lines of code isn't the same thing as forward progress, and doing more with less code—or removing code—is often the goal.

We believe your data has far more interesting story to tell. For example, we think that Impact is a better way to think about codebase change. The metrics in Flow have accounted for this false path and we do not emphasize lines of code as a meaningful metric.