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 (16)
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.
This is hardly a radical technique. It is the standard technique of a self sufficient engineer. Has been for eons. I remember early in my career as a software engineer I once designed and prototyped an 8 bit multi channel communications controller, designed the double layer PCB for it using red and blue mylar tapes and then wrote the firmware using a combination of assembly and C. This was all par for the course. Debugging interrupt service routines with a logic analyser was used as frequently as the software debugger.
A team of just five talented polymath software engineers willl achieve better results than a team of 50 coders, architects, front-end specialists, rear-end specialists and their hangers on.
It is no different from the case of a modern professional musician who today must be accomplished not just in playing music but with digital audio technology, MIDI and mastering.
Andy-
I just wanted to say I had a chance to use your TripAdvisor product(s) on a recent trip, both for booking / research as well as City Guide while international.
I was *so* impressed with your product and data that I actually looked y'all up to see where you were located to see if you had offices in my area. You didn't. :-( But... great products, and I'm happy this "front-to-back" development methodology works well for you, it sounds like it'd be a great environment to work in as well, apart from a great product to work *on*.
Please pass along some positive energy to your dev team(s) and let them know their care and attention to the product shines through.
If they're looking for some feature ideas...
* Transit layer on maps (ie: subway route lines / stations at least for cities with offline city guides) ... super helpful for savvy travelers when researching hotels in a big city. I ended up toggling back and forth between google maps + transit and your site in order to match up how far away the hotel was, and what lines / connectivity it had.
* Histogrammish of "cleanliness" instead of only "overall rating" ... important to keep my germaphobe wife happy!!! (maybe left/right arrow or swipe on existing ratings histogram to change what's histogramm'd). You have great detail, if a hotel is in the top 20%, but bottoms out as "terrible cleanliness" it's not going to pass, and it's impossible to expose that data currently without randomly opening a bunch of positive and negative reviews to get a sample of what the happy / unhappy people felt about how clean the place was.
* Add metro stops as artificial "points of interest" on offline city guides so I don't have to find a restaurant *near* a station in order to use the "point me there" feature
* Add "view on map" or filter for "just the things you've starred" list for the offline guides (City Map => Filter => Things You've Starred)... we would sit down Monday and star things while eating lunch (what we wanted to do / were thinking about doing), and then have a tough time finding them on Tuesday because you had to zoom in / out / scroll in order to see if any starred things were in the area you were in now.
The quality of your work is inversely proportional to the nit-pickiness of the feedback you get. These are all really nitpicky things, which speaks to how well you're handling the basics! Thanks again!
--Robert
BREAKING NEWS: TripAdvisor only hires code monkeys: unable to architect large systems. Great success was achieved with small feature driven development. Looking forward to outsourcing all software development...... Ok, so how is this news again?
I find it hard to believe that back-end developers (server-side logic) almost always have the same talents as front-end developers (HTML, CSS, presentation layer). The latter discipline, in my opinion, requires at least some design skills, and therefore is not attainable by everyone, especially back-end developers. But the again, what do I know?
Front End Developers and Back End Developers are two different animals! While one can have skills of the other, a truly proficient and useful front-end developer has bounce rate, conversion, GUI design and other things in mind while a back end developer make it all work together. The key phrase here is proficiency! Yeah, anyone can figure things out but you end up paying more for your end-product by having one jack of all trades! It's better to have pros!
It's like having a quarterback catching the ball he or she throws! Short passes yes, game winners no!
This is EXACTLY what is wrong with AMERICAN COMPANIES engineering model and why we continue to fall behind Asian countries such as Japan, Korea and China. What is described here is neither AGILE nor SCRUM but a classic description of UNSTRUCTURED PROGRAMMING where no one really specializes in anything or knows how to do anything PROPERLY. This situation always arises in companies where MANAGERS and PMPs run the organization instead of an ARCHITECT. Without a technical background, said managers appoint themselves as visionaries capable of all tasks. They hire entry level, offshore programmers who do not know anything. Then they task them with specialized tasks which they reply back with,"it's not our role.". After several frustrating negative responses, the managers tell them it is their role and they need to learn it.. Then the half assed project moves forward to being a full blown failure. Then come the layoffs eg. Cisco, HP, AOL and on and on...