Increasing Productivity in Outsourced Teams

Around 11:00pm, April 7th, 2010

My phone alarm blares at 11:00pm ringing to the tune of The Imperial March. I grab my laptop bag, hop in the car, and head home from a wireframing session at Pickwick Pub. A new feature concept served over two Firestone DBAs waits to be shared. Again, my alarm rings at midnight. I log into a Go To Meeting conference to meet with two offshore development teams in India. Together, we build and design CRM and web development solutions for one of the largest SEO companies in California. My first question to them: “Guys, are we on track?”

They say, “We only have a few pieces to work on, but everything else has been pushed to test.”

Another Bug?

“Great,” I say, “let me take a quick look.” By the time the clock hits 12:05am, I realize that our project requires at least another week, maybe even two, before we are “on track.” Nothing works. Bugs abound. I am overcome by a strong desire to blind myself when looking at the user interface. What went wrong? Maybe I am just not cut out for product management. Then I think, “Sure, India is cheap, but you can’t get anything done right. We’re sacrificing productivity to save a few bucks.” No reason to bring up that new feature I designed at the pub.

My future self looks back in time thinking, “What a newbie?!”

I spend the following week researching process methods, development methodologies, and even personal habits for product managers trying to find a solution. I need stuff built, and fast. I know that working more hours only puts a Band-Aid on the real problem. Deeper issues require my attention. My team and myself struggle to be productive.

Why? The first question I ask myself. I need to understand why we are unproductive before I can make us productive. I analyze the team’s productivity over three metrics: Communication, Scope, and Timeline. Intuitively, it seems that working effectively within these three themes yields a successful project. I write those three words on my white board and start taking notes.

For Communication:

“We meet about two times a week. Daily emails. Send frequent UI updates. Only get questions/concerns brought up during meetings.”

For Scope:

“Very big projects. Game changers for sales department. New launch of customer portal. Little attention on quality.”

For Timeline:

“Quarterly deadlines for launches. Always comes down to wire or gets postponed at least two weeks.”

Major issues exist in the current development process. Even more, these issues represent deeper issues with my personal productivity. I notice a few key problems holding us back:

  1. I need to communicate better with my team so that they really understand the requirements that they receive. About 93% of communication happens through tone and body language , yet most of my communication to the team occurs over email. How much information gets lost?
  2. I create tasks with massive scope for the team. Often, these tasks appear overwhelming, complex, and too difficult. Furthermore, setting reasonable deadlines on large tasks always fails. We almost never hit our deadline. A lot of research shows that massive tasks lead to procrastination . As I research Agile methodologies, I discover a huge amount of information around how to size tasks and how to break tasks down to create better development cycles.
  3. Setting quarterly deadlines allows work to pile up to the very end. This method leaves little room for changes and quick adjustments mid cycle. I know the team needs shorter deadlines. Looking further into SCRUM, I read countless articles about two week sprints, and decide to implement a SCRUM framework with my team.

On Monday, the following week, I held a Skype session with team and sent the following memo:


I want to make the following adjustments to our processes moving forward. Please see below. Let me know if you have any thoughts.

1. We will have daily meetings using video chat.
2. We will set 2 week deadlines and complete our tasks during each of these sprints.
3. We will discuss all the requirements and tasks at the beginning of a 2 week sprint.
4. We will agree on what should go into a 2 week sprint before we start.
5. We will only allow tasks in a sprint that can be finished in half a day or less. If it can’t, then we will break it down further into two or three tasks.
6. We will not consider a task finished until it is fully tested.

I hope that this will improve our workflow. Please hold me accountable for creating good processes for us to follow, and I will hold you accountable for writing good code.


The next day, we all joined our first SCRUM meeting. We got off to a rocky start. Several developers still needed web cams. Some did not have tasks assigned to them. Our efforts to change process started slowly, but ultimately snowballed into big changes that swept the organization. We introduced Agile development to the rest of the company. Going forward, in our daily meetings, my first three questions to the team never changed:

  1. What did we get done yesterday?
  2. What are we working on today?
  3. Are there any issues blocking progress?

Implementing these basic project management processes created a much more productive development group. While domestic costs increased due to the amount of time spent in meetings and project management, our output nearly doubled. The company was able to outsource more development tasks and create faster turnaround in product testing.

Do you have any nightmare scenarios that you turned around? We’d love to hear them in the comments.

Ethan Lieber

Ethan Lieber is a founder at ZeroToComplete where he focuses on leadership and entrepreneurial productivity.

No Comments

Leave a Comment