Productivity isn't this magical trait you are gifted with when you're born. I believe it is a trait that you develop hours and hours of relentlessly practicing it and aiming for it.

It is hard, and therefore, it is good.

When there are low levels of productivity in any team, I have observed in all the places I have worked, hints of demotivation. Albeit, it affects our motivation in other fronts also. The Engineering Manager gets a hit, the team gets a hit, and thus we fall in this foggy environment which starts reflecting in everything - even in the very lines of code we produce.

At one of the startups I joined, I noticed similar traits. Of course, there were multiple reasons for sure (it's a startup afterall!), but it takes some time and some mindfulness to understand these signs. For example,

• there was a lot of friction when it comes to day to day work
• low enthusiasm in delivery
• low velocity

One of the core problems my guts would tell me was uncontrolled context-switching. I think it's one of biggest productivity killer. And it is extremely costly to business.

It’s not just about moving between tasks; it's about how much time it takes to get back into the flow. It's something we don't really think about mindfully because it's harder to be mindful.

The constant switching between responding to ad-hoc requests, solving bugs, and engaging in discussions was costing us far too much in developer hours.

When I focused more into what was really the root-cause of the problem. It was this peculiar slack channel.

This channel was very heavily used by non-engineers and marketing folks. They’d drop in all kinds of bugs and problems there, but the signal-to-noise ratio was completely off the charts. As engineers, we shouldn't 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. EMs would then take these messages from the slack channel and:

• transfer them into an Excel sheet
• make tickets out of it
• manually assign context
• forward them to the relevant team

A process that should take seconds was stretching into hours. I proposed to the teams that we streamline the whole process and automate everything that can be automated. But it had to be done in steps.

Enter - Linear

My first step was to move all the teams to Linear, a product 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, workflow management and developer experience.

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 de-facto 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 teams 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. Also something, that would push the cost up.

Unfortunately, Linear informed me that they were working 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 app hosted on slack and leveraging Linear's webhooks. A small Next server which would act as a relay between Linear's webhooks and slack.

This bot allowed anyone— regardless of whether they were a Linear user or not to create issues directly in Linear's triage inbox (ofcourse with their API key and the whole nine-yards). All they needed was to be a part of the slack channel.

The results were remarkably 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 so all the relevant people would get a notification
• 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.

I'm happy that this feature essentially validated the solution I had built but it came with steroids.

Super happy as I write this post. ❤️ Linear to the moon and back.