TripAdvisor Strategy: No Architects, Engineers Work Across the Entire Stack
Friday, July 1, 2011 at 10:54AM 
If you are an insect, don't work at TripAdvisor, specialization is out. One of the most commented on strategies from the TripAdvisor architecture article is their rather opinionated take on the role of engineers in the organization.
Typically engineers live in a box. They are specialized, they do database work and not much else, and they just do programming, not much else. TripAdvisor takes the road less traveled:
- Engineers work across entire stack - HTML, CSS, JS, Java, scripting. If you do not know something, you learn it. The only thing that gets in the way of delivering your project is you, as you are expected to work at all levels - design, code, test, monitoring, CSS, JS, Java, SQL, scripting.
- We do not have "architects." At TripAdvisor, if you design something, your code it, and if you code it you test it. Engineers who do not like to go outside their comfort zone, or who feel certain work is "beneath" them will simply get in the way.
A radical take for an established organization. We've seen companies where backend engineers are also responsible for front-line site support, but I don't recall, other than for startups obviously, where engineers have such breadth and depth of responsibility. It's not right or wrong, but something outside-the-box to consider, especially if you are an Agile shop.
Reader Comments (10)
There are places even in Microsoft (however rare) where this is true. It's hardly radical.
We prefer to do it this way as well, even though there might be situations where a "specialist" is required. About 80% of the work can and should be performed by anyone on the team, while the remaining work may involve a specialist.
In the news. Startup reinvents wheel, declares it to be round, waits for accolades
Not *that* radical. This is the concept of a "feature team" in scrum - everyone who is needed to get a feature done is on the team. People have T-shaped skills - deep in one thing, able to do anything. This eliminates handoffs, which are the source of inefficiencies, delays, and errors (see "telephone game").
It's something we kind of do in my current job (could do better) and were moving toward in my previous job.
Maybe unusual but not radical.
At my previous employment we worked like this. It's very nice and you REALLY get a team spirit. Everyone helps everyone.
We did however let people lean towards certain specialities. Some front or backend but in general everyone could do work anywhere.
I think it's great and again, really builds a friendly helping team.
When I changed jobs I was actually chocked it was so devided. People didnt even know how the other part of the application worked! For a team of three!
Being the author of this article, I want to thank Todd for publishing this.
I do want to make it clear that I do not consider our approach radical , nor are we by any stretch of the imagination the first to do this. And this way of working existed at TripAdvisor before I joined (and was a significant factor in why I joined) - I thank the technical founder for that.
Every startup does work this way (or, imo, should do this). What I am most proud of is keeping this culture and scaling it to over a hundred people. Every company, as it grows, has to decide what is important to them and focus on keeping that intact, and this way of working is what is important to us at TripAdvisor. It has its pros and its cons, as will any approach. It is a bit unstructured, and there is often "ramp up time", and we do not always have the "experts" working on their area of "expertise" - but I am happy to pay those costs in return for keeping people challenged and focused on the big picture.
And, of course, every rule is made to be broken - we do have specialists - for example, tech ops, desktop support, machine learning engineers, and others who have valuable skills and do not "work across the stack". There is also me, who no longer works across any stack.
I think what people are missing here is the fact that TripAdvisor is large and as a rule of thumb, larger companies tend to specialize people. It is easier to hire for, easier to train for, but for your better than average developer, less interesting. Startups and smaller companies, by definition, require individuals to work across the stack. Is the notion radical, no. Is TA doing something unique, yes, only in that they are keeping the startup mentality for as long as they have.
It would be interesting to get the authors view on when this breaks down. From my perspective - this is fine when your team remains small and the technology remains homogeneous. It's a non-starter when you have 800 engineers across 3 continents using lots of different technologies (mainframe, SAP, etc.) What's the breaking point?
Jeff
Hi Jeff,
A very good question, and one that we have asked ourselves every year since I have been working here, back when there were 10 engineers. Will this scale to 800 engineers ? I really do not know, but I do see a path through the next couple of years.
As we have grown, we have faced the issues you have mentioned. We do have some development in the UK, and there is also a team in China, so we are on "three continents". We have also opened up new business units (independent sales/marketing/product management/engineering) that have their own engineering teams, but still work on our common source base. Two of these teams uses a different tech stack, PHP. We have worked out these challenges, which are invariably culture/process challenges, one by one. If you add up all these teams, there are actually about 150+ engineers involved in building our site. For now, I do not see a scenario where we need to use a lot of different technologies: the back office systems are very separate and are managed outside of the engineering team, and our tech stack (linux/apache/java/postgres) should be all we need to build anything we want to build. Fact is, you can build and scale a web site with pretty much anything (Java, PHP, Perl, Python, Ruby) - its all in how you use the tech. We will continue to opportunistically add new tech as it makes sense.
Some things that have helped us get to this point :
- We are building a consumer media web site that grows mostly horizontally in terms of features. I have done boxed software and enterprise software (boxed and hosted) in the past, and would not consider using our current approach in either of those settings. We are doing some Saas and transaction products, and take a somewhat different approach in these areas.
- When we do need to go "deep", it is done in one or more of our services, which imo, is key to large scale modularity.
- We do not have dozens of teams blindly building in and checking code. Our senior tech leads and managers monitor and tweak the order of projects being checked in. When two or more projects that leverage a lot of the same code are scheduled for the same time, they are re-ordered, pushed out, etc. If there is a very large project, we will minimize what goes out that week (we will also take a different, deeper, approach to testing).
- Since each team is responsible for end to end development, this creates horizontal modularity as the organization grows - not much different than minimizing dependencies between software modules. And it helps that our site is pretty modular from a business and technology perspective.
- We are using API's more often, especially when it comes to mobile development, and it is becoming possible to build "full sites" in a completely different tech stack in a different hosting environment. We provide our API's, data feeds, and commerce functionality to a number of other companies, both within the TripAdvisor family of companies, and also to outside companies.
Many of the more serious challenges involve cross-cutting concerns that cannot be modularized within one team: Supporting 30 points of sale (and growing) across almost 20 languages, SEO, social networking, analytics, and of course, the build/test process.
For example, last year we ran into the "wall" of having too many projects being checked into our source base each week. We have a "merge" machine where you update your code from the main source, run all of the tests, and then merge back into the main source base. This is automated, but does take a few hours. Since this is one machine, and is synchronized across all the check-ins, this creates a growing bottleneck - how does this scale to more and more projects ? One of the traditional ways to solve this is to create a hierarchy of check-ins, which is not very palatable, and would probably end up slow things down. So, we simply created two merge machines, allowing two streams of check-ins to go in parallel, and are willing to deal with the occasional collision. So far, this has not caused any problems for us.
Hardly radical - just best practice.