Why Slack Alerts Went To #1 On Our Roadmap

We launched a new feature last week. Slack alerts.

LinearB now alerts users right in Slack when there is a branch or PR that needs attention.

Three weeks earlier it was not #1 on our priority list. It was not even #2 on our list. It was somewhere in the middle of a big story backlog. Planned for sometime in the second half of 2020.

But then our dev team was thrust into 100% work-from-home. And our customers were too.

We like to think we’re “agile” so we put that theory to the test.

What can we do to help?

Every day more and more teams were becoming remote. So we asked ourselves…

---

“What’s the #1 thing we can do to help work-from-home dev teams?”

Our people had a lot of ideas. We started working the question from another angle…

“What’s the biggest thing dev teams are going to lose by not being in the office?”

Of course it was face-to-face interaction. But what was the outcome of that loss for devs exactly? We took a step back and looked at each phase of our software development process.

Cycle time is one of the most important metrics tracked in LinearB.

We started talking about everything that happens during coding time (fun time), pick-up time, review, time, etc. We realized that when things are going smoothly, our devs tend to just keep going. But when they’re blocked… that’s when they seek out a peer or manager.

We asked around and found that when they seek out help, here’s what they do…

Step 1) Remove Bose noise-canceling headphones.

Step 2) Swivel around SecretLab Titan gaming chair.

Step 3) Tap Oriel (the handsome dev pictured below), Roy, or Zuki (or other smart dev) on the shoulder.

For devs at LinearB, and we theorized for devs at other companies who work in the office, help is just a swivel and shoulder tap away.

How do we replace the shoulder tap?

LinearB already identifies dozens of situations where developers may need help like:

-Branches with high code change rate combined with high refactor or rework
-PRs sitting in the review process too long or going through high interaction
-PRs hanging for too long before getting picked up
-Substantial PRs merged with very little review
-PRs merged without any review at all

This is useful for work-from-home teams but there were two challenges still to be tackled:

-LinearB is mostly used by CTOs, VPs and team leads.
-You have to login to the LinearB platform to see data.

To help replace the swivel shoulder tap, we needed to make this information useful in real-time for the entire team.

As we were contemplating this, at some point our dev lead Ariel blurted out “Slack”. Of course, what he meant was “let’s show dev teams opportunities to help each other by alerting them in a Slack channel” 🙂

Heads were nodding including most of our developers so we got to work right away. We had less than three days to get this ready for our next sprint.

Background and context

Here’s a few more details about our typical sprint planning process to give you more context… We work in agile scrum. Our sprints are two weeks long. All of the following milestones must be complete before we start the sprint:

-Personas defined
-Stories defined
-Requirements doc written
-Graphics ready
-Interactive mock-up ready
-CEO approval
-Customer review done
-Dev review done
-Marketing review done

Timeline

Monday, March 9th
-Our dev lead (Ariel), CEO (Ori), and I started planning an internal work-from-home test day for our entire product and dev organization for Thursday the 12th. This is when we first started thinking about what our own dev team would need to be successful working remotely.

-Later over Slack, the discussion about what our own dev team would need continued and we started thinking about how this would apply to customers also.

-So many ideas were flowing about what we could do to help work-from-home dev teams that we decided to schedule a brainstorm meeting for the next day.

//Tip: We get a lot of great inspiration from our internal dev team. They are power users of our product and we consider them “customer zero”. If they want something or find value in something, we know there is a good chance other customers will. If you make a product that your internal team can use (any department), consulting with them when you’re looking to get quick feedback is a great way to find out if you’re going in the right direction.

Tuesday, March 10th
-During the brainstorm meeting, we accomplished a lot including 1) agreeing Slack alerts would help us and our customers, 2) getting buy-in across departments to move it to #1 in the upcoming sprint and 3) deciding on an important high-level requirement

---

“It has to be useful to everyone in the engineering org including devs, team leads and execs.”

-I ran out of the meeting and locked myself in our conference room to “figure out how to get all of this ready for the sprint in two days”.

-After furiously writing a new product requirements doc, I emerged later. It was dark. Everyone else was gone 🙂

//Tip: It’s hard to get every department on the same page. Even at a start-up. The brainstorm meeting was scheduled super last minute. Our sales and marketing teams could have easily opted out for pre-existing commitments. But every department joined and I think that was the key to our success. Why? Part of it is that we have a strong culture and helping each other is normal for us. But I also took the time to write every department head a personal note about what was going on and what it meant for their team. I think that helped get them to the table with the right mindset.

Wednesday, March 11th
-I stay up all night updating our roadmap to highlight the impact Slack alerts has on other feature priorities.

-Our UX designer Dana also doesn’t sleep and puts together examples of what the new screens might look like.

-We had a meeting across all departments to review the PRD and screenshots and collect feedback. We get a lot of good questions like “what happens when a dev who is not registered in LinearB tries to click a link in the alert?” and “how do we find the balance between sending too many alerts and making sure the most important alerts always get through to the team?”

//Tip: You can’t add something without taking something away. Otherwise, you’re setting everyone up for failure. This didn’t just apply to the dev team. We had to work with marketing and every other department to adjust their projects to fit Slack alerts in.

//Tip: A killer UX person is a not-so-secret weapon. Our feedback meeting would not have been very productive without screens to look at. People are visual. Make sure you get one that is talented and who is willing to work 12-hour shifts on a moment’s notice – only every once in a while 🙂

Thursday, March 12th
//side note: Our dev team is mostly in Israel and our workweek is from Sunday – Thursday so this was the last day to get everything for the sprint which was starting Sunday the 15th. This was also our “test” work-from-home day. Or so we thought. Over the weekend we made the decision that work-from-home would be permanent so we never actually returned to the office.

-We met with a few customers and partners to validate the idea and the user experience. Thankfully they loved it because we had very little room for substantial changes at that point 🙂 Here’s some quotes we got back:

“Sign me up! When is beta available?”

“I’ve been trying to get more of our people to look at LinearB. I think this will help.”

“This is what we need. We’ve been chromecasting LinearB onto the TVs in our office area so everyone can see hanging PRs and changes to cycle time and all of that. We need a replacement.”

-We were having a problem with where the Slack alert configuration should go. There was no good place for it. So, Dana, Ariel, and I got onto a Zoom to figure it out.

-I led one final meeting with the dev team to make sure they were ready to start work on Sunday morning.

*//Tip: Customer validation could have been a major fail point for us. The key to success was having customers that A) could get back to us right away and B) were able to have a conversation about a feature really early in the process (versus when there was a working beta they could play with). We make a habit of bringing customers in very early on almost every new feature so they’re used to this. And we communicate with many of our customers through text and on Slack so it’s easy for them to get back to us quickly.

Sunday, March 15th – Monday, March 30th*
//side note: Our sprints are normally two weeks but we extended this one by two days to spend a little more time on user experience and quality.*

-Our devs kicked ass. Especially when you consider they were adjusting to work-from-home.

-Our marketing team hurried to illustrate the value.

-I got talked into writing this blog 🙄

-On Wednesday, March 25th we implemented an early version of the new feature in our own LinearB and Slack account – drinking our own champagne is important to us. Customer zero.

-On Thursday, March 26th our dev Oriel merged a PR with a lot of code changes with no review. That’s a no-no at LinearB. The team was alerted in Slack and was able to get a super quick turn around on review so we could keep moving. And they also gave him a really hard time 🙂

Shortly after we rolled out the feature internally, our team was busted merging a PR without review!

*//Tip: At multiple points in the sprint, our devs pushed back on scope. “Do we really need this for MVP?” Sometimes as a product manager holding the line is the right thing to do. In this case, I had to allow more de-scoping than normal. Without that I don’t think we would have delivered anything useful in our time frame.

//Tip: We used a progressive roll-out. First an early version to our own internal team. Then a beta to a few customers who we consider design partners. Then a more open beta, under a feature flag, to any customer that wanted to participate. Then GA. This was a great way to get the feature into the hands of customers to get feedback while also limiting risk. *

Compromises

To make this work, we had to make a lot of compromises across both our process and the feature itself.

Feature compromises: We did not ship the version of this feature we were planning to ship in Q3/Q4. The core functionality is there but we sacrificed some configurability. In the future, we hope to invest more time into letting teams decide how to weigh each type of alert and how many they want each day per type. We also plan to bundle different alerts together that relate to the same branch or PR.

Process compromises: We bypassed some of our normal checks and balances to get ready in time for the sprint. Here’s a few examples of steps we had to skip:

-We normally hold multiple internal stakeholder review meetings throughout each step of the process. We did meet with our teams (as I mentioned above) but not individually like we normally do.

-We always do multiple customer review meetings throughout the process. Here we met with customers but only at the beginning and the end.

-We normally create fully interactive mock-ups for major features. Since people are visual, this really helps in getting feedback from internal and external stakeholders. But it takes a lot of time. So we had to settle with static graphics.

Outcomes

So how did it all end up?

For starters, we shipped a new feature from idea to release in three weeks! Check it out. Our own dev team and customers use it every day which I think is a good sign we stayed true to our goal of helping to replace the swivel shoulder tap.

We proved to ourselves that we could deliver during a time of extreme change. The abrupt shift to work from home didn’t stop us from delivering our sprint. We’re pretty proud of that.

We were able to deliver despite cutting some small corners because we had super tight communication. Great communication will make up for a lot.

Final thoughts

This is proof that, for us, it is good to take a hard look at our priorities occasionally, be willing to challenge our own thinking and not be afraid to pivot when the data and circumstances call for it.

There was a celebration over Zoom after the feature shipped and our first customers started getting alerts and taking action on those alerts to help their team. But what we delivered this week is not the end. It’s only the beginning.

Desperate times seem to have brought the best out of us. We tested our agile scrum approach under extreme conditions and it actually worked. And we did that without too much internal drama or churn. It makes me wonder how I can help recreate this camaraderie and teamwork and tight communication throughout our normal process. It makes me wonder if we need to take a hard look at our “normal” process. We’re agile after all and this is a start-up. Change is what we do.

Ready to see alerts about your dev team right in Slack? Start your trial of LinearB.