Palantir keeps it lean and mean on five-year journey from zero to 150 employees

[Editor’s note: In January, author Jeff Widman discovered a blog called “Startup Lessons Learned” by Eric Ries, advocating the idea of a “lean startup” as a “learning organization.” Inspired by the topic, he also audited a class on customer development given by entrepreneur Steve Blank. Below, is the first of several profiles by Widman on companies that are actually implementing the lean model.]

Palantir Technologies is relatively unknown in Silicon Valley — it keeps a low profile and doesn’t seek much press. But in the five years since its founding, it’s grown to over 150 employees and maintained a very profitable business model. In this column, I will take a closer look at how Palantir has adopted the “lean startup model,” drawn directly from Ries and Blank — a model that allows companies to eliminate excess weight (unnecessary personnel, wasteful expenditures, etc.) while sprinting ahead with limited risk.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":105777,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"D"}']

The backstory

In 2004, several ex-Paypal engineers teamed up with Stanford computer scientists to build advanced data analysis and heuristics software for government agencies, hedge funds and financial institutions. That package became the foundation for Palantir.

Unlike most software companies, it still ships a physical product because several of its customers have “air-gapped networks” — for security reasons, their internal networks are disconnected from the rest of the web. Examples of Palantir’s work include the Center for Public Integrity’s sub-prime lender study, an analysis of Somali piracy and a study of Hezbollah. It also provided the platform used by researchers to uncover the GhostNet cyber espionage ring covered in the New York Times.

Here’s an example of one data model, a heatmap of Baghdad:

Getting to know its customers’ needs

Palantir began as a group of software engineers who understood how to manipulate large chunks of data, but had zero knowledge of government intelligence agencies. From the start, they had to learn what this new type of client wanted from a software package, as well as how to sell into the government contractor approval process and navigate security clearances. They began by working closely with target customers to refine the product’s features. According to Bob McGrew, director of engineering for Palantir’s government division:

We literally flew to a prospective client, showed them ten features in a live demo, and they generally liked one or two, so we’d toss out the rest. Painful, but we became very skilled at building just enough of a feature for them to decide whether they wanted it. We also found that live demos were worth the extra work over screenshots because it created a more transparent experience for our customers, which in turn allowed them to provide better feedback.

As the feature set came together, Palantir offered its clients free training before any contracts were signed. This allowed the company to stick close to its customers, respond quickly to bugs and forge valuable relationships. When it finally ramped up its sales efforts, the majority of the intelligence community already knew about the company through word of mouth.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":105777,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"D"}']

Working the “Five Why’s” process

In the last six months, Palantir’s engineering team has instituted what Eric Ries calls a “Five Why’s” process to respond to bugs and other problems. The system is designed to turn potential crises into learning opportunities. The core idea is that it usually takes five questions to unearth the root cause of a problem. For example, if a web site goes down, the company should ask why. If the answer is that CPU usage spiked, it should ask why. If the spike was linked to specific code, it should ask why that code was inserted, and so on until it becomes clear how the problem originated and what it will take to prevent it from occurring in the future.

Palantir has implemented the “Five Why’s” across all departments, even facility operations. There was once a report filed with the title “Horrific smell in the kitchen,” and facility operations used the “Five Why’s” process to identify the underlying cause and ensure that it would never happen again. Foul smells aside, the company says the system has noticeably improved company cohesion. Whenever a staff member submits a bug report, they now receive a summary of the “Five Why’s” analysis — including details on how the bug was fixed. The procedure for this has been stored as an internal wiki for all to see.

The employees involved in resolving a complaint don’t simply ask “Why” five times. A “Five Why’s” master is appointed to lead the discussion of the problem and to record results. The answers to the questions are used to generate action items that are then assigned to specific individuals with deadlines. The master then writes up a brief report on how the process was applied to arrive at a solution. That report is sent out to concerned parties and posted on a central wiki for future reference, actively building institutional memory.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":105777,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"D"}']

You can see exactly how Palantir implements the Five Why’s at the end of this post.

Short release cycles

When Palantir first demoed its product for customer feedback, it operated on a two-week release cycle (meaning that it introduced new features every two weeks). As the product became more and more complex, that cycle got longer and longer. “Eventually, we had one cycle that took six months,” McGrew says. “That’s when we decided it was getting out of hand. A short release cycle forces us to maintain high quality code and quickly illuminates when we’re building features that customers don’t care about.” Today, Palantir pushes new features internally at the end of every month. It hopes to soon be doing so every three weeks. Externally, customers receive product updates every two to four months, which is still incredibly fast for a software package that requires physical installation.

Tight discipline, no PowerPoint, short meetings

[aditude-amp id="medium3" targeting='{"env":"staging","page_type":"article","post_id":105777,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"D"}']

Despite its rapid growth (or perhaps because of it), Palantir runs a tight ship, providing vital information on an internal wiki, keeping meetings concise and striving to hire candidates with “an engineering mindset, even in our administrative people,” McGrew says.

The division of the company devoted to government products has only one ten-minute meeting every week to make sure developers and managers are on the same page and to discuss prospective customers. There is also a company policy against using PowerPoint decks. Most communication takes place via email lists, instant message conversations and face-to-face discussions.

The company is also unique in that it doesn’t have any soft-skills marketing or sales personnel. All customer-facing employees have degrees in computer science or symbolic systems — generally from a top-ten university — and are capable of walking customers through software installations and debugging. This has helped Palantir build tighter relationships with its clients.

“Our marketing is mostly having really smart CS folks represent us in the field,” McGrew explains. “And then we work hard on the feel of our software. For example, we wanted to make our software feel like something out of James Bond, so we modeled it after the software you see in the movies.”

[aditude-amp id="medium4" targeting='{"env":"staging","page_type":"article","post_id":105777,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"D"}']

Constant communication with customers has not only resulted in a successful product, but has also molded Palantir into a learning organization. It has been forced to continually reinvent its product and its processes for greater efficiency and appeal. In turn, the company has become a formidable player in the bureaucratic world of government contracts. it sounds counter intuitive, but the red tape associated with federal agencies has actually honed it into a leaner startup. As McGrew explains:

There have been several hoops that we’ve jumped through that afterward we said, “That took WAY too long. How can we adapt and get through that hoop quicker next time?” And now those hoops serve as barriers to entry. Five years ago, all of our friends were out starting social networks for consumers while we were taking on this old-school industry with entrenched companies and system administrations who slowly built what their employees needed. We’ve brought the Silicon Valley, venture-capital funded, iterative model and completely disrupted the industry.

Tips for using Five Why’s at Palantir

1. Schedule a meeting or VTC with all the affected parties.

– Part of the goal of Five Whys is to get the people who were involved in the error involved in creating the solution. They are the people most able to discover a good solution and understand the root of the problem.
– If you are doing a Five Whys report on a product failure that occurred in the field, be sure to involve at least one representative from both the development and the implementation teams; preferably QA as well.

2. Appoint a Five Whys master to lead the discussion – keeping it moving, writing down the results, and making sure action items are assigned.

[aditude-amp id="medium5" targeting='{"env":"staging","page_type":"article","post_id":105777,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"D"}']

3. During the discussion, try to keep the Five Whys in a public place, like a whiteboard – it helps prevent people from talking in circles.

4. Finish the Five Whys step before creating action items – it helps keep the discussion focused.

5. Make sure each action item is assigned to a specific person to do. Also make sure it’s a real action item, not a general best practice for the future. (It should be possible to verify that an action item is done within the week.) For “lessons learned” sorts of items, try tasking someone with writing up a best practices page for their task.

6. Within 24 hours, the Five Whys master should write up the report on the wiki using the Five Whys Template and mail out the full text plus a wiki link to [e-mail address]. Each report should be added to the Five Whys Archive.

7. Participants have one week to echo back to the Five Whys master that the action items have been completed. (In the case of a bug, you could echo back the bug number and Fix For version.) The Five Whys master should check back 7 days after the fact (just flag the e-mail for follow up 7 days later and check your Outlook To Do bar).

8. As a best practice, assign Jira issues where possible as a simple way to close out action items. A Jira issue plus a Fix For version is a sufficient receipt to mark the action item done on the page. This works because we have a lot of processes that make sure that Jira issues are fixed on a regular basis; for non-Jira issues, the Five Whys master is responsible for seeing that the issues get fixed.