Scroll through your recent Slack history and look for conversations that begin like this:
"Who do I ask to spin up a new client pipeline?"
"I have a new developer on my team, how do they get access to the VPN?"
"How do I create a new team in JIRA?"
"Where is that documentation for upgrading node on a service?"
"I have a question about [THING], what team owns that?"
Even if your company is full of friendly, helpful people, and all of these questions get resolved a few minutes later, these questions should ring warning bells. Each of these questions is turning an inherently asynchronous process into a synchronous one -- someone that was actively working on a task (onboarding a new software engineer, creating a new pipeline, etc.) has stopped working on that task to ask a question, and likely won't be able to continue again until someone appears to answer it.
In a small company with just a few teams, where everyone is in the same time zone, those few minutes of extra waiting don't seem like a big deal. But as a company grows, both in team size and in number of time zones, the number of questions and the amount of time waited can explode. In a company that has become remote, that spans 3, 4, maybe even 10 time zones, stopping and asking a question on Slack isn't just a few minute wait; it often means that task is now blocked until the next day.
If your company is full of synchronous workflows, a software engineer's day quickly becomes an exhausting series of task-switching exercises, pushing a little bit further on each of their many blocked tasks, rarely being able to pursue the thread of a single task to completion. It's hard to be happy as a developer when you end the day feeling like you haven't accomplished something -- it will kill your productivity just as quickly as a slow CI build or broken bug workflow will.
If you recognize some of the questions above in your own company's chat log, prioritize fixing it! What needs to be fixed depends on what kind of questions are being asked and why people are blocked.
Technical Solutions
You've always intended to create an automated script, or service, or Jenkins job to do this task for developers, but in the meantime, it's easier to tell people "just slack Bob the name of your new service and he'll set it up for you". This kind of issue often naturally gets resolved technically, because Bob gets sick of doing it manually, but maybe it's time for the team to prioritize that automated workflow, or CI pipeline generator, or whatever other tools your company needs.
Documentation
You automated all your stuff years ago, but people are still blocked in Slack just because they don't know it exists. Make sure the services you offer your software engineers are documented, and that links to that documentation exist in a place that makes sense. Ask people where they looked, or what they searched for, and bridge those gaps for next time. Build automated replies in Slack if you have to! Do whatever you can to connect people with the information they need, without waiting for another human to show up and help them.
Consensus Building
This is a special case that often happens to engineers new to a company -- you need to write a script, or build a tool, or add a feature to a product, so you ask a seemingly innocuous question. "I see repos with both Mocha and Jest, which do people prefer here?", or, "The generator says I can use Terraform or CloudFormation, is there a preference?"
Instead of an answer, you find yourself in the middle of a heated debate, with conflicting responses from people more senior than yourself. In this case it's blocking you from even getting started on your task, but it might block you in the middle too -- for example, you put up a PR with code changes recommended by one team lead, only to be blocked by a different team lead demanding a different approach.
This issue is common on rapidly growing teams and you should consider it especially alarming, as it has the potential to be exponentially frustrating and tense for engineers caught in the crossfire. Take the people with strong opinions and get them into a room or a meeting to hash it out, or task a key decision maker with gathering opinions and making a decision; however you accomplish it, it's critical to prevent these kinds of situations from becoming the norm at your company.
And more...
Here's a thought exercise I like: imagine you wake up at 4am and can't sleep, so you decide to get a few hours of work done early. Look at your current work backlog -- what tasks could you do, alone, right now? What tasks need to wait until one (or several) of your coworkers are online?
Some tasks do require "synchronous communication", like sitting down with team members to brainstorm or chatting about a proposed feature. But for those that aren't inherently synchronous, what would be required to make it asynchronous? Is it a technical solution, is it missing documentation? Whatever it is, chipping away at those edges in your company will slowly and surely reduce the number of times your developers end up blocked each day, increasing their happiness and their productivity.
Top comments (0)