Working with a distributed team: Why?
Distributed team are part of the essence of Internet start-ups nowadays. Here’s why, in Blackfire’s context.
This article is the first of a series of 2, on working with distributed teams.
At Blackfire, the team is distributed all over the globe. Well, at least, we have permanent locations covered in France, United Kingdom, US east & west coast… and as we travel a lot around the world, there’s often one of us somewhere we don’t have an actual office. Did I mention we’re looking for a DevOps to join us from Latin America?
And though we work with Scrum. Why do I mention that? Scrum is an agile (software development) methodology. Even internally, we sometimes believe we’re not that good in being agile. But let’s face it: we all strongly believe in the 4 key agile values and all of the 12 agile principles. Even the following one:
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Why be distributed?
Let’s start with some business requirements. We’re delivering a Software-as-a-Service: a product which is mainly available to our users online. Our users subscribe to the service, may it be on free or paid subscriptions. It is a productivity tool to the extent that, even if it most of the time isn’t a critical element in a development workflow – you still can write code without Blackfire, it makes development team’s work much easier when it comes to managing performance. And it is a technical tool. That translates in the following constraints:
- we must distribute our product around the globe (with a certain focus on US and EU but you know… it’s Internet after all);
- we must ensure the highest possible Quality of Service to offer a near 100% availability, around the globe;
- we must ensure support, as much as possible, around the clock, around the globe.
Yes, there’s some repetition of “around the globe” in my list here. And the nature of our market leads our organization. We have to be where our users are.
More importantly, we have to experience what they experience. We follow the “eat your own dog food” principle, and we would be pretty bad at it if it were only from our Paris office. Different parts of the globe have different constraints. It may be simply in terms of Internet access, but it especially is in terms of business specificities. Development frameworks and tooling have different market shares across countries. In relation, countries have different buying habits…
In other words, we want to provide you with the best possible answer to your app performance problems, and that can be done only by sitting next to you.
How to work like that?
Check back next week for a follow-up on this article! 😉
We’re an Internet start-up. We care about our users worldwide. We’re agile. We learn from our mistakes. We make it possible to work as a distributed team.
Good luck to all distributed teams in internet businesses!