At one of the places I was working, I noticed there was a lot of friction when it comes to day to day work. Some developers were not enthusiastic. The velocity was suffering. The issue? Uncontrolled context switching. I would personally put context switching as the biggest productivity killer. It is extremely costly to business.

And it’s not just about moving between tasks; it's about how much time it takes to get back into the flow state once you’re interrupted. It's something we don't really think about actively. The constant switching between responding to ad-hoc requests, solving bugs, and engaging in discussions was costing us far too much in developer hours.

One of the primary sources of this chaos was a Slack channel used by non-engineers and marketing folks. They’d drop all kinds of bugs and problems there, but the signal-to-noise ratio was completely off the charts. You cannot expect a non-engineer to translate their problem into actionable items. And knowing which team is the right team for the issue.

It wasn’t an efficient system. People would then take these messages and transfer them into an Excel sheet, manually assign tasks, and forward them to the relevant teams. A process that should take seconds was stretching into hours.

I knew we could do better.

Enter - Linear

My first step was to move all the teams to Linear, a task management tool built specifically for product teams. Not only was it cheaper, but it was miles ahead of the tool we were previously using in terms of usability and workflow management.

Linear is well-known for being fast and clean, helping teams stay organized and efficient. I reached out to their community slack and Casey quickly came on board and helped me pitch the product to the company. We first did a slack-connect and he became the defacto person in case there is any friction in getting the PMs onboarded and help in answering any questions they may have.

Introducing Triaging

Once we were set up in Linear, we introduced the concept of triages and introduced the Triage Inbox of Linear to the teams.

In simple terms, triaging means sorting and prioritizing issues as they come in, so the most critical ones get immediate attention. This helped streamline the flow of work. Triaging also meant that engineers were no longer bombarded by random Slack messages. Instead, issues were funneled into a more organized system.

Change is usually uncomfortable. But the team quickly caught up to speed. I like to think the reason for it were 3 things magically mixed together:

• excellent PMs who cared about productivity
• excellent engineers who could quickly learn and adapt
• excellent onboarding and UX of Linear

Automating further with a Slack Bot

Now that the team was getting accustomed to Linear, I wanted to eliminate the remaining inefficiencies. One of the key pain points (then) was that Linear’s built-in Slack bot didn’t allow non-Linear users to create issues directly. That would mean we would have had to ask the marketing and sales folk to use a PM tool - something I didn't think would fly well.

Unfortunately, Linear informed me that they were workinig on it and is not to be released anytime soon.

But we didn’t have the luxury of waiting.

So one night, I sat down and built our own Slack bot. A deno server hosted on slack leveraging Linear's webhooks.

This bot allowed anyone— regardless of whether they were a Linear user or not to create issues directly in Linear's triage inbox. All they needed was to be a part of the slack channel.

The results were instant.

Not only did this reduce the noise on Slack, but it also allowed for two-way duplex communication. For example,

If an engineer reacted to an issue with an 👀 emoji, the bot would

• automatically assign the issue to them in Linear and move it to their team’s backlog
• open a slack thread and reply there that this person is looking into it
• tag the issue opener so only the required people are notified

If someone would respond with a ✅

• it would move it to the team's "Done" stage

If for some reason, no one had picked it up

• it would put a ⏳emoji in a thread.
• the bot would comment in the Linear task with a permalink to the slack message

Productivity off the charts

Our productivity skyrocketed 🚀🚀🚀🚀

Developers were no longer distracted by random requests, and issues were properly tracked and prioritized. We had finally created a smooth, uninterrupted workflow. We soon felt the need to do a duplex communication on slack too.

For example, if someone would comment in Linear's issue, it should show in the slack thread. I was so happy about this that I decided to open-source the bot.

However, just then, Linear officialy launched their new feature -

Linear Asks

Submit requests directly from Slack and automatically send them to the relevant team in Linear. Eliminate cluttered channels and reduce context switching.

This feature essentially validated the solution I had built but it came with superpower steroids!

I'm super happy as I write this post. ❤️ Linear to the moon and back.