Category mgmt

Joining a Distributed Team

With software development talent harder to come by in hotspots like Silicon Valley, companies are looking for talent wherever they can find it. Distributed development teams are becoming more common. As a developer, joining an established distributed team can be a challenge. Aside from the technical challenges, such as learning an existing code base and processes, you also have to socialize with your new team.

When I joined Nodeable‚Äôs distributed development team a few months ago, the team was already in place and processes were defined. I had to quickly adapt to developers that had worked together for over a year and start providing value immediately. These are some of the things I did to acclimate to my new team. You may find these helpful if you’re in a similar position.

Start Early

A few weeks before starting, I learned about the development and deployment processes. This allowed me to ramp up on any tools I may not have been familiar with. There were very few in this case, but the opportunity was there to close any gaps.

Additionally, I started reviewing the bug database. This provided two advantages. First, I could figure out how the team used Jira. Is it just used for bugs and immediate work items, or for broader road map items as well? The second advantage was less obvious. From looking at the bug database, the history of the team as apparent. What areas of the application underwent significant change or were abandoned? Which ideas looked promising but were later dropped due to changing priorities or pivot? This doesn’t seem important but it can give you insight into how your new team works. And when you’re not seeing them in person everyday, every piece of data is helpful.

Avoid Cost Center Work

This point isn’t isolated to distributed teams, but I’ve found the impact of working on cost center stuff to be greater when working remotely. When you join a new team, distributed or not, you want to avoid working on tasks not directly related to the product road map and/or a profit center. Cost center tasks are things like chasing obscure bugs, anything related to devops, or writing unit tests. (Sorry, but unit testing is a massive cost center.) While you can’t avoid cost center work all the time, and you shouldn’t, it’s better to avoid it when starting in a new position. It’s demotivating and helps to erode that crucial honeymoon phase at a new company.


Refactor Fridays

The topic of slack time came up recently with some colleagues and I described how I’d introduced something called “Refactor Fridays” on a client engagement. While most people have heard about Google’s 20% time or Atlassian’s 20% time experiment, understanding and developing a slack time program isn’t easy. This post looks at some of the theory behind slack time and offers some guidelines on implementing slack time in your team.

What is Slack?

In a traditional, organizational economics, sense, slack is defined as any excess capacity of an organization’s resources. This could be a machine running at only 75% capacity or extra capital not being put to use. Regardless of the context, slack is some amount of uncommitted resources. Historically, slack was viewed as a wasted opportunity, but this view is changing. Instead of being seen only as a waste of available resources, slack time can be viewed as a cushion against sudden demand spikes or as an opportunity for grassroots innovation.

What Slack Isn’t?

A common way to view slack is as padding when determining timelines. If a developer believes a task will take 10 hours but she says it will take 20, the padding isn’t slack since the developer is still committed for the 20 hours regardless of how long the task takes. Slack is a supply of uncommitted resources, not conservative resources.


My client’s situation wasn’t typical for organizations looking to adopt a slack time policy. The startup team was (and still is) distributed, feature velocity was extremely demanding and the competitive landscape was (and still is) changing rapidly. These factors combined to introduce technical debt, significant stress within the engineering team and little product innovation outside of immediate customer requests. The goal dedicated slack time was to address each of these issues.

The slack time program started by defining what tasks would fall under the program. We specifically targeted addressing technical debt as the primary goal and non-essential feature development as secondary. Non-essential features might include adding JMX functionality to core components or dropping in some AJAX to improve the user experience. With an agenda in place, the next component was some way to verify what was being done to ensure the company was getting value by allowing developers free reign on Fridays.

“Look at What I Made!”

Proving the value was always the easiest part. The projects the team undertook on their 20% time were interesting, making Show & Tell a common occurrence. When people are interested in what they’re working on, they want to share it. By getting immediate feedback, the idea can be shaped by emerging business requirements. However, we were a small team and justifying effort was easy. Your organization may require more detailed reporting requirements.

Dedicating slack time for your developers to work on personal projects may not appear to be a good use of time and money. Every project has technical debt, and every developer has an idea on how to improve the current product. By allowing your team to experiment in a structured way, you can clear some of your debt and support incremental innovation in your application. Most importantly, your team will appreciate the trust you’ve put in them.

Have you implemented some form of structured slack time for your engineering team? If so, how did it work out? Let me know in the comments.

Copyright © Nick Heudecker

Built on Notes Blog Core
Powered by WordPress