Skip to Content

Blog Archives

Team extension: How we more than doubled in size yearly, while bootstrapped, since 2009.

Team extension (noun):The service category of helping companies scale their staff with remote contractors who integrate into the current business process.

So where did this term come from? Back in 2009, after a few months of working part time on my first software product, my company announced a voluntary layoff program, due to the excess software engineers in the organization. Within a day, I signed up to sign off. With some self funding, I had an 18 month window to try to find a profitable business after I found a technical co-founder.

During that time period, we killed off one product, started a second, and finally found a working business model, by paying attention to how our business was actually performing. So how did we get to 12 people on payroll from just 2 co-founders in a little over 2 years? Here is the story of team extension, the foundation of TangoSource’s growth.

Lessons learned from a rocky start with consulting

After our first product failed, we wanted to lengthen our runway by doing outsourced contract work. TangoSource already had a couple of advantages from having an office in Mexico, namely time zone, and software developers with an understanding US culture. Sometimes things went well, other times we had plenty of room for improvement. There were a couple important commonalities that I noticed in projects that didn’t meet our standards.

1. Outsourcers hate losing face. As Malcolm Gladwell mentions in his book Outliers, many cultures recognize status differential more profoundly than people in the US or Europe do. This often comes to light when an outsourced dev should mention an issue, but instead tries to think his way out of the situation. They spin their wheels trying to solve the issue themselves, whether it was a bad requirement, an architectural error, or a mistake that they should have owed up to a long time ago.

2. Fixed scopes create adversarial situations, instead of building teams. From the Thoughtbot Playbook:

“We don’t do fixed-bid fixed-feature-set proposals. This contract style sets the vendor and client working against each other instead of with each other, right from day one. Instead of discussing how a feature should be built, or what assumptions were wrong, you spend time negotiating about what was meant in a document written a long time ago. But it’s worse than negotiating – it’s retroactively discussing something that no one will remember the same way anyway.”

Nowadays, we offer a free 20 hour trial, that would otherwise be spent making estimates. This is in alignment with Agile Estimation and Planning, one of my favorite PM books, which digs into a strong alternative to running fixed bid projects, by using empirical data for each project to reasonably estimate future performance.

Concept origin

In early 2011, at the Launch conference, I ran into someone who would fundamentally change the way we were doing business. I mentioned my access to tech talent, and that we were doing contract work on the side. After keeping in touch over the course of a few months, we started an engagement with one of Seattle’s premiere Rails consultancies.

What I noticed a couple months in, after nailing down communication, process, and training our developer in unit testing, was the gradual decrease in time commitment from our leadership. This engagement was profitable, and easily maintained, and I realized I had a scalable business model. After some soul searching, we decided to shift to a service model, since we didn’t see anyone doing similar work in the marketplace, and saw a serious need. That initial engagement has been ongoing since then, and we have fostered others like it, thereby allowing us to focus on recruiting and training, while having high utilization.

Team extension benefits

So why did we decide to specialize in a new service category? According to much of The 22Immutable Laws of Marketing, it’s important to be seen as first in the market in some way or another. There’s also a long term strategic benefit to becoming the authority in a category, particularly one that generates value for everyone involved. So what’s in it for our customer?

  • We can scale more cheaply, and pass those savings on to the customer. Because Team extension is a high utilization business, the customer doesn’t have to pay for our marketing efforts, or our down time.
  • We focus on team building with the customer. Instead of arguing over a spec, the customer is with us each step of the way, looking for ways to improve productivity, and everyone benefits.
  • Ongoing engagements engender trust. When developers trust the customer, face saving issues don’t come up as often, and the team is more efficient.
  • We’re able to guarantee developer time. As a project grows, it’s important to make sure it has a stable development engine. Due to ease of forecasting, we can maintain grow with the customer smoothly.

Team extension best practices

There are a lot of choices from the toolbox to run a project. Some tools, such as project management (eg: Pivotal Tracker, or a variety of Kanban SaaS) mean picking a single tool for the project. Other times there are a variety of tools that can be used, and it’s a question of using the most lightweight ones that get the best outcomes. Here are a some of the practices that have helped for Team extension:

1. Pair programming. Pairing helps developers work out more complex code issues, by creating a social environment where two people focus deeply on code, as well as easing knowledge transfer. For Team extension, it has a key benefit of allowing a team to take collective responsibility for rough patches in the software development process, instead of an individual spinning their wheels, trying to figure out a way to avoid losing face. Additionally, two minds mean that it’s less likely for there to be an issue to get stuck on in the first place.

2. Text standups. Having minutes of what people have accomplished, what they’re planning on accomplishing, and where they’re stuck can be helpful for Team extension. First off, sometimes customers can’t always attend a SCRUM standup. Second, some devs may have good written English, but are not easy to understand via voice. This practice has helped avoid a lot of miscommunication.

3. Use a good task tracker. Transparency is key when building teams, possibly more so when certain members are remote. Being able to see what’s going on with a granularity that’s helpful, but not onerous, gives PMs and product owners the chance to help clear roadblocks to productivity.

There’s also a bit of secret sauce that goes into setting up projects, managing software development, and training developers. I’ll probably write a separate Team Extension best practices article sometime in the future.

Wrapping up

If you’d told me 3 years ago if I’d be running a service business, I’d have been incredulous. Once I saw what was happening objectively, with a reality check from mentors, I was able to lead the evolution of an advantage into a working business. If you happen to lucky enough to be able to validate a business model, I suggest you press every advantage available to establish your position in the marketplace.

0 0 Continue Reading →

Coding for a cause: Benefits and Pitfalls

Does free work sound like a bottomless pit of time expenditure, with no chance of compensation? Have you ever wondered how to do pro bono work in a way that not only improves the world but helps out your bottom line? Our team just released some pro bono work for Vittana, which I think was time well spent. Below you can find out how it came about, why it was worthwhile, and read some lessons learned to improve the odds of success for your next pro bono project.

Discovering the project

When I ran into my friend Kenji at a mixer a couple weeks ago, it seemed like a usual incidence of our paths crossing, given that in one recent week we ran into each other 4 times at various tech events. Little did I know that the project I’m posting about now would be revealed. Kenji mentioned trying to raise awareness for Vittana as a means of making a difference, via a blogger challenge. For those not in the know, Vittana provides microloans to students in the developing world, and donors can choose how funds are distributed, as well as distribute funds each time students pay back their loans.

Over drinks, Kenji and I bounced around a bunch of ideas and eventually we came together with a plan to create a blogger challenge with a leaderboard sorted by tweets and dollars lent through the challenge. It took a bit of back and forth, but eventually we were ready to rock.

Working with Another Team: How we did it.

In order to keep the project from spiraling out of control we:

Defined Scope:I’ve talked with people who have done pro bono work, and one of the worst outcomes is ever expanding project scope, with no end in sight. To prevent this, we established some ground rules to keep it from getting out of hand. By the time that the contest started, we agreed that we would hand over the code, and give maintenance responsibilities to the Vittana team.

Established the Concept:Our first task was to establish the concept before any serious coding began. We wanted to create some background tasks that made Twitter API calls to search for number of retweets associated with a given blog post. To narrow the search down, we suggested using hashtags. A possible side bonus is that we could create a trending topic and create some buzz.

Minimized Reliance on the Vittana Team:To ensure we didn’t have to take a deep dive into their code base, the Vittana team gave us JSON feeds containing all of the necessary fields (including donation totals) for each of the bloggers. Given the nature of the work, we were able to have a quick pile on of a few developers, giving them a change of pace for a couple days, and then allowing them to move on cleanly.

Why did we do this?

First off, I’m always happy to make my friends look good and improve the chances of a successful project. Given that the Vittana team was already slammed, I saw a great way to help out a friend. I was also able to do some good for a cause that I care about personally and professionally. TangoSource trains developers in our locale to increase their odds of professional success after college.

We also have a few developers that we’ve been training and were just about ready for production quality code. I believe that real work is more interesting and effective in training junior developers. This seemed like a good opportunity to expose some guys to a real world project.

Finally, we were presented with a chance to expand our business. Despite being relatively young, Vittana has a strong brand with a lot of awareness, which was a chance for great exposure. The possible value for the TangoSource brand seemed significant. Here’s a screenshot of the link we were given on the contest page:

Cause-Img

I also found out recently that the Vittana team is interested in discussing TangoSource doing paid work. This should not only provide us a means of growing the business, but also help us do good at the same time.

Lessons learned

1. Don’t rely on others to test your code.To a certain extent, we assumed that the other team would test our code on production. We ended up having to do some last minute patching that would have been more efficient if encountered earlier in the development cycle. Initial testing also exposed some places where the interaction design was broken on the admin side that would make further testing difficult, and we had to code out a much more involved administration panel. This was an affirmation of test early, test often, with a realistic scenario.
2. Remember to nail down the environment before writing a line of code.In this case, we assumed that Vittana was using the same database as what we were testing for in our local environment. That mistake was an fast way to waste a couple hours. Also, unit test your code regardless of the scope of the project. We wasted a fair amount of time on regression errors.
3. Whenever possible, try to limit scope in a way that’s win-win.It makes sense for the Vittana team to take ownership of our code. The more complex our product, the more work needed on their side. Also, since this was a new type of initiative, we were able to execute a lean exercise for them without too much investment for either party.
4. Networking is valuable but often in an intangible way.Deeper connections are more useful, but take work to find and cultivate. For me, this means meeting plenty of people to find those that I connect with. Afterwards, there’s the enjoyable investment of staying in touch, which helps create opportunities.
5. Genuine altruism is a great business strategy.You never know what might result from doing good. After starting work, I ran into the some of the Vittana leadership, who mentioned they might need some development help on future projects. This was confirmed in later communication, after they performed some code review.

Final results

With 90 hours of work total, I feel this was a worthwhile way to spend our time, even not including the chances to grow TangoSource’s business. From a purely utilitarian standpoint, this effort will probably pay out regardless. Subscribe to our blog to find out!

Stay tuned

During the course of the blogger challenge, check out Vittana Twitter and the leader board we helped create:
http://www.vittana.org/make-a-difference
Be sure to spread the word to help fund students around the world.

Also, we’re planning on releasing a Rails gem that does the majority of the Twitter heavy lifting, so keep an eye on the TangoSource blog if you want help automating the tracking of tweets.

0 0 Continue Reading →