Plus Plus from Palantir.net

Collaboration Tools

Director of Operations Colleen Carroll reveals some of her favorite collaboration tools in this week’s episode of the Secret Sauce.
TRANSCRIPT
Allison Manley [AM]: Hello, and welcome to the Secret Sauce, brought to you by Palantir.net. This is a short podcast in which we offer a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, Sales and Marketing Manager at Palantir, and today’s advice comes from our Director of Operations Colleen Carroll, who talks about how the right collaboration tools can make everyone’s workday go a whole lot smoother.
Colleen Carroll [CC]: Hi, my name is Colleen, and I’m here today to talk about collaboration tools that we use here at Palantir.
We use many different tools here at Palantir, but the ones that I’m going to be focusing on the most are the ones that are basic to being a Palantiri — the tools that we use to communicate and collaborate effectively as a remote-first culture.
Some of the tools that are pretty essential to being a Palantiri are really the Google suite. And by that I mean that we use email, through Gmail of course. And that works, that allows us to communicate with each other. But it’s really all the other things that come with the Google apps domain. We use Google Docs for everything. We don’t have Microsoft Office or anything really installed on the computer. We rely on the cloud, we rely on Google Docs in the cloud, to hop in a document together, to draft a note together, to put draft agendas together or to take minutes together. We also use Google spreadsheets and Google presentations. If we can’t get in a document and look at it together, it’s almost as though we’re missing a critical function. We’ve been using the Google suite for many years now.
One of the other critical parts of the Google suite that we use is Hangouts. We use that for lightweight video conversations. Because we’re not all here in person sometimes, it’s important that everyone who’s on a meeting be able to see each other, and to be able to talk at balanced and equal volume so that everyone can hear each other. And to that end we also require that people have really good headsets and microphones. So much so that if you’re on a Hangout with a Palantiri, they will correct you and stop the meeting to help you tweak your audio settings so that they can hear you well. Because we have such an inclusive culture here, we want to make sure that everybody has an equal place in the conversation. And you can do that with Google Hangouts by seeing every person and hearing them.
One of the other nice things about Google Hangouts and, really, many of the video chat tools now, is that it allows you to share your screen. So it’s another way to collaborate. Let’s get right to it, what are you seeing, let me see that, oh, I know what that means. It allows us to really have a much more informed conversation.
Another Google tool that is crucial to our day-to-day is Google Calendars. Because everybody has a Google account, they can easily subscribe to any other Palantir team member’s [Google] Calendar. They can see where they’re at, they can schedule a meeting, they can ask them if they can move a meeting. It makes it really easy to get things scheduled, because we aren’t all here in person and can’t stop by somebody’s desk. By providing that information on demand, it makes it easier to collaborate.
The last Google-related tool that I think really empowers the sharing of information and greater ability to collaborate is the Google Drive. Obviously when you use a Google Doc, a Google spreadsheet, a Google presentation, it puts it right up into the Google Drive. But the Google Drive is only as successful as it is organized. And so one of the things that we’ve done is to create a Palantir shared folder, and tried really hard to organize it so that people can easily find things. Again, that on-demand nature is important to our culture because — I don’t always know what people need and at what point in time. I can certainly send an email communication saying, here’s that presentation I made, or, here’s that 360-degree review form. But people don’t always need it right then and there. However, if I have a folder structure, you can kind of consider it like a library that’s easily browsable and accessible, they may find, oh, there’s that 360-degree form, or, look, inside there is that presentation that’s a quick-start guide on how I can solicit 360-degree reviews from my peers.
So we try to organize and present information in a way that’s easily accessible and shareable, and in a format that’s easy to collaborate. So to use the 360-degree form again, sometimes people on the team want to create a 360-degree review, but they may want some help drafting questions — creating questions that give them the right amount of constructive feedback. So if they create a document on the Google Drive, they can share it with me and I can coach them through maybe some different wording, help them redefine their goals. It’s not only them being able to create the form themselves, but them being able to share it with me very easily allows for a stronger collaboration and a more effective outcome.
One of the last tools that we use, really for communication and collaboration but most for communication, is HipChat. It is essentially our water cooler. It’s our primary mode of having conversations with each other. Inside of HipChat we organize conversations into different rooms. We have a general Palantir room that’s usually the laughter and giggles room, where we share images and videos with each other, and talk about day-to-day things. But then we have more topic-based rooms like a sales room or a design room or a coders’ lounge. We have a social room, we have a spoilers room for people who are all watching the same television shows, and other things that help build our unique culture here. We have HipChat set up so that all things are available to all Palantiri, and again that helps spur conversations that are important to the team and are share those with other members of the team, and aren’t pushed from the top down. They’re not structured in any particular way.
At Palantir, the ability to collaborate virtually is key, especially as a virtual team. We wouldn’t be able to do that without these tools, without the Google suite, using Docs, presentations, Hangouts, Calendars, the Google Drive and the shared folders. There are much more tools within the production team as well that help facilitate peer programming, and I think you should stay tuned for a further podcast to hear more about those tools. Thanks!
AM: Thanks Colleen. That’s the end of this week’s Secret Sauce. For more great tips, please check out our website at Palantir.net. You can also follow us on twitter at @palantir. Enjoy your day!

Documentation and Training

Senior Engineer Ryan Price dives into the importance of documentation in this week’s episode of the Secret Sauce.
TRANSCRIPT
Allison Manley [AM]: Hello and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a little bit of advice to help your business run better.
I’m Allison Manley, an Account Manager, and today we have Senior Engineer Ryan Price talking about the importance of documentation and training.  
Ryan Price [RP]: My name is Ryan Price, and I want to talk a little bit today about documentation and training. Probably the key person that I think about when I get into the role of writing documentation for a project is future me. Who is the person that will be reading this later, and who is the person that’s going to get the most benefit out of it? Then I sort of go from there, because the more people that get involved with the project — whether it’s someone on the client side, whether they’re technical or non-technical, whether it’s other members of the development team, or maybe my project manager — all of those people are going to read or edit or touch the documentation of a project at some point.
And on a lot of projects I’ve worked on in the past, I have been in the role of training the new people who are going to be using that project, whether it’s other developers or the content editor who’s working on the client side. And all of those people need to know what this website is supposed to be doing. Beyond just the business goals, there’s lots of nuts and bolts things, and in the land of Drupal we have lots of nuts and bolts things. And for some people those things are totally new, and they have fun new words like ‘nodes’ and ‘taxonomy’ and ‘views.’ And for other people, they know those things, but they haven’t seen this way for placing blocks in this context, whatever that happens to be.
So I think even a simple project that is just a brochure site would still have documentation that needs to be written for future me. When I come back to this project, I don’t want to spend five hours remembering my motivation behind making a new field for this. It should just be there. What does this field do and why do we have it? You want to get this stuff out of your head. If you get hit by a bus, you don’t want to be the person on the project who made something that was indecipherable and everyone needs to sit around and figure it out.
And the other thing is, when you explain something, you learn it. There’s doing it and being able to do it yourself, versus having to write it down. For me, translating something out of my head into speaking is when I really understand what it is that I’m doing, or writing it down at the same time. And you can also discover things about the project, too. Like discovering when a requirement is unclear, or when a piece of work is not quite polished. Because you’re getting ready to document it, and you say, it’s supposed to do these nine things and it does eight of them really well.
So there are lots and lots of benefits to documenting your project and teaching someone else how to use it, and I think probably the key person among those is future me. Thank you for listening!
AM: Thanks Ryan. That’s the end of this week’s Secret Sauce. For more great tips, please check out our website at Palantir.net. You can also follow us on twitter at @palantir. Have a great day!

Understanding Your Company’s Purpose

In this week’s episode of The Secret Sauce, Palantir Founder and CEO George DeMet dives into the importance of being in tune with your company’s purpose.
TRANSCRIPT
Allison Manley [AM]: Welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick piece of advice to help your business run a little bit better.
I’m Allison Manley, an Account Manager at Palantir, and today we’re talking with our Founder, George DeMet. He’s going to share why it’s so critical to understand your company’s purpose. It sounds like a basic concept, but it’s important to give clarity around why a company exists.
George DeMet [GD]: In a previous installment of the Special Sauce a couple of months ago, I talked a little bit about my personal history with family-run businesses and some of the values and principles that have helped guide some of the world’s most enduring companies. Values and principles are important because they help answer the question of how we as a company strive to interact with each other, with our customers, and with the world around us.
Today, I’d like to talk about the importance of understanding your company’s purpose, or why it is that we do what we do.
Being able to say what it is that gives your company direction and purpose is vital to attracting motivated employees and helping prospective customers understand why they should choose to work with you. Knowing what you do and why you do it is essential, but so is being able to communicate that vision to others.
A core purpose can be articulated in many ways. If you’re a very small company, everyone on the team probably already knows and understands your core purpose, and you may not even need to articulate it. But as your company grows and evolves, chances are that not everyone will come in with that shared understanding, and you’ll need to find a succinct and understandable way to describe to others the reason why your company exists.
Now the flip answer is “because getting a paycheck is what puts a roof over my head and food on my table”, but I think we can all agree that that’s not enough. There are a lot of different ways to make money, and we make a deliberate choice to do what we do. Fundamentally, a core purpose is an organization’s most fundamental reason for being. It does not change, but it inspires change. And most importantly, it must be authentic to the organization’s values and culture.
Many companies have a mission statement, which is a (usually) brief and aspirational statement describing what it is that the company seeks to do. The difference between a mission statement and a vision statement is that a mission statement focuses on a company’s present state while a vision statement focuses on a company’s future.  Some companies tend to blend these statements, and in most cases, that’s okay. What’s important is that there’s an easy way for people to understand what the company is about and its approach. This is usually something that appears in the company handbook or field guide, and it’s often on the website as well. To be clear, a mission statement or purpose is something that should be distinct from your tagline or marketing slogan.
It’s my belief that regardless of what form it takes, a statement of purpose is not one of those things that you can just knock out in a workshop over an afternoon. It needs to come from deep inside you, and it needs to “feel” right. It’s also really important that the stated mission, vision, and values are be aligned with the actual culture of the company, or else they’re just lip service.
For example, Enron advertised Communication, Respect, Integrity, and Excellence as their core values, yet the actions of their senior leadership created a culture of greed that encouraged unethical behavior at all levels, using a variety of deceptive, bewildering, and fraudulent accounting practices to make the company appear more profitable than it actually was. The company’s traders were also actively involved in manipulating the energy market in California, illegally cutting power to the state and causing rolling blackouts in order to keep prices artificially inflated. Enron’s CEO, Ken Lay, even bragged to the Chairman of the California Power Authority that "In the final analysis, it doesn't matter what you crazy people in California do, because I got smart guys who can always figure out how to make money." 

I would argue that one of the most important things that the executive leadership of a company can do is to reinforce the company’s vision and values. They need to hold other leaders in the organization accountable and accept ultimate responsibility for the company’s actions. As Harry Truman famously put it, the buck stops here.
At Palantir, our purpose is to strengthen humanity by helping others discover, create, and share knowledge. This informs the kinds of projects and clients we choose to work with, and along with our values and principles, it informs the approach our team takes to helping solve problems. It’s important to note that our purpose is not connected to any specific technology or even to the web itself; we just happen to believe that at this time and place in human history, the web is the primary conduit by which knowledge is discovered, created, and shared, and that we at Palantir have a role in helping others use the web in a way that helps strengthen humanity.
Especially during times of economic and political uncertainty, it’s especially important for companies to understand why they exist. Market conditions and technology change all the time, and if you’re going to be successful in the long term, you need to root yourself in something that is more stable. In our case, that means being able to help customers understand, articulate, and solve their problems in a holistic way. We have always defined our success by the results we help our customers achieve, not by the names of the brands we work with, or the amount of profit we make.
At the end of the day, I believe that companies are most effective when they can communicate who they are and why they are here. That’s something that we try to do at Palantir every day, and I think it’s a big part of what’s contributed to our success for the last twenty years.
AM: Thank you George! For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Enjoy your day.

The State of Workbench in Drupal 8

Listen to Ken Rickard (@agentrickard) discuss some exciting new developments for Workbench in Drupal 8.
TRANSCRIPT
Allison Manley [AM]: Hello and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a little bit of advice to help your business run a little bit better.
I’m Allison Manley, an Account Manager, and today we have our Director of Professional Services  Ken Rickard talking about the state of Workbench in Drupal 8.  
Ken Rickard [KR]:  Hi, this is Ken Rickard, the director of professional services at Palantir. Today we’re going to talk about Workbench and the module suite that we developed as part of the Drupal 7 lifecycle.
Workbench, if you don’t remember, is a series of three modules that were designed to hit very common publishing use cases. Workbench Moderation is the most popular. It provides for staging previews along an approval workflow. Workbench Access is an editorial access decision module, it lets you decide who can edit content on your worksite. Workbench itself is really just a collection of editorial views to make it easier for people to find the content they need to work on.
Since our last blog post on this subject, some really fun and interesting stuff has happened in that space. In particular, if you were at DrupalCon New Orleans, you heard Dries talk about the workflow initiative in Drupal core. What’s fascinating about Drupal core right now is that we contributed a lot of code to Drupal 8 regarding how publishing workflows actually operate, and actually removed some of the barriers that made it harder to do workbench moderation. Some of those things are still there, but because we’re now following a semantic and stable release cycle, so that every six months we have a new release of Drupal that does not break backward compatibility, that means that we can add new modules to core.

And there was a movement among the core maintainers — specifically I know that Alex Pott was involved, I know that Nathaniel Catchpole was involved — and they decided that they wanted to push Workbench Moderation into Drupal core in Drupal 8.2, which is the next release that’s coming up, in order to start shaking out the rest of the issues that need to be solved in core that are really specific and relevant to the workflow initiative. The workflow initiative has some really fantastic and ambitious things that are going to be happening, but for it to work properly, all content must be revisionable, and those revisions must have the capacity to be moderated. Since we had a working model of content moderation, that’s going to be brought straight into core and then iterated on. So it’s really fascinating.
There are a couple of things that are important about that from our perspective. Number one, it really is a culmination of the work that we started, at this point, seven years ago, in order to make it easier for publishers to use Drupal to accomplish the tasks they need to accomplish. So that’s a huge victory for us; we’re really proud of that. Number two, it does show very good things about the product lifecycle and the maturity of Drupal as a project as Drupal 8 moves forward, this idea that says, hey, we can add new features without breaking backwards compatibility. We’re willing to experiment with things in core in order to improve the experience for our users. I think that’s really critical.
So the outcomes of that, which are going to happen pretty rapidly — there’s a developer named Tim Millwood . . . Tim works for Acquia, he’s been involved with the workflow initiative since day one, he’s part of the module acceleration program, and Tim’s been around the Drupal community for quite a long time. Tim’s taking over the workbench moderation in core project, which is going to be called ‘content moderation’. He’s got a first iteration that’s almost ready to be committed into core. So while Tim’s working on the code side, there’s actually part of the Drupal UX team approaching, how does workflow management affect the user interfaces that Drupal presents? And that work is being spearheaded by Roy Scholten and Bojhan Somers and the rest of the UX team. And they’re doing some really exciting stuff. I know they’ve been getting together at the dev days event that just happened in Milan. They’re collaborating quite frequently, which is really exciting to see.
So content moderation is going to go into core in 8.2, which essentially means that principal work on Workbench Moderation is going to stop. There’ll be a few bug fixes, and if a security release has to come out, that’s going to stop. But it was yesterday, as we record this, that I made Tim Millwood a maintainer of Workbench Moderation, so that he could work on a 2.X branch, an 8.2 branch of that module, which would just be an upgrade path for current users of the module when the core module goes in. So you can replace what you’re doing in the Workbench module with the core module going forward. So that’s really exciting. And like I was saying, it’s sort of a culmination of what we were hoping for with the module suite as it goes.
If you have any questions, you can always reach out to us. We’ll be happy to talk about the future of these things. But from my perspective, it’s really exciting. It’s very gratifying to see things that you thought of years ago moving through being successful in contrib, and then being adopted as sort of essential to the project. And that’s one of the things that keeps us motivated as contributors.

AM: That’s it for this week’s Secret Sauce. For more great tips, check out our brand spanking new website at palantir.net, download the Secret Sauces from iTunes, and check us out on Twitter. Our handle is @palantir.
Have a great day!

Benefits of an Iterative Design Feedback Process

In this week’s episode of The Secret Sauce, Senior Designer Ashley Cyborski discusses our iterative design feedback process and how this helps move designs forward to effectively meet our clients’ ideal results.
TRANSCRIPT
Allison Manley [AM]: Welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a short piece of advice to help your business run a little bit better.
I’m Allison Manley, an Account Manager here at Palantir, and today we’re talking with Ashley Cyborski about a good design iteration and feedback process.
Ashley Cyborski [AC]: Hi everyone,
My name is Ashley Cyborski and I’m a senior web designer here at Palantir. You may remember my other podcast about the benefits of designing in the browser. You should check that one out if you’re a web designer feeling hesitant about taking the leap to HTML and CSS.
Today, though, I want to talk about our design feedback process here at Palantir, because it is a bit different than traditional design processes.
I’d like to rewind and give you a bit of background. At Palantir we use agile methodologies during our development process. For anyone unfamiliar, agile is a 2 week cycle called a sprint where you prioritize work, complete those tasks, present the work to the client, and receive feedback which you can then incorporate into the next sprint. It is a process of continual improvement and collaboration. Our design feedback process came out of a desire to incorporate that same level of collaboration and continual improvement into the design phases of a project.
After a lot of thinking, and quite a bit of inspiration from a webinar by Dan Mall, we came up with a process that is iterative, but accommodates our clients’ needs.  The process isn’t perfect and we are continually working to improve it, but it is a huge improvement from where we were just two years ago.
The core principle of our design feedback process is iteration. Though this sounds pretty obvious, it is very different than the traditional design feedback and iteration cycle. In a traditional process you present your work, receive feedback, incorporate that feedback into the design that you had presented, and then re-present your work, around and around until the client decides to approve the design. And though that works quite well for print design, it is counter intuitive to web design, especially when paired with an iterative development process.
In our feedback process we often tell our clients to think about moving designs forward. At the start, we present 2 to 4 style tiles to the client. Then, we ask them to choose the “most correct” one to move forward with. The one they chose may not be perfect yet, but through iteration and with the proper input, we move the design closer and closer to that “ideal”.
In order to get there, we need that input. We ask our clients to provide feedback on the chosen style tile and the discarded ones. We prompt with questions like “What did you like about this design?”, “What don’t you like about this design?”, and most importantly, “Why?” Our goal is to understand our client’s thoughts and feelings, including what is inspiring them and what is concerning them.
We take all that feedback and the selected direction, and begin on the first static comp. We don’t spend our time iterating on the selected style tile.  At this point we repeat the process with static comps. The feedback received during the comp phase is worked into the prototype. From there on out, the prototyping process syncs up with the sprint cycle, and feedback on prototypes is defined and prioritized along with the remaining design tasks and incorporated on a sprint by sprint basis.
That was a lot of words to describe how we move the design process forward. You might ask, why don’t we work on one deliverable until it is “perfect” or close to perfect? Well there are a few driving factors.
First, our process becomes faster and more efficient because we don’t have to pause the project to work out small, inconsequential details that would otherwise resolve themselves in the future. The entire project doesn’t pause until we get it to some subjectively “perfect” state of design. This is important and unique to web design, because your design will appear on any number of machines, browsers, screen sizes, and with multiple variations of changing content over the course of its life. A website is a living, breathing, changing thing.
Second, we can adjust the course of our design as the project moves forward and develops. We aren’t stuck with a decision we made in week 1 of the project, when we learn something new in week 7.
Development prioritization can drive design prioritization and the design benefits from active and informed developer feedback and input. This benefits the designer, because we aren’t completing work that ultimately will not be implemented, and benefits our clients because they aren’t paying to design work that ultimately won’t be implemented.
Third, we get to the browser faster which benefits both the client and the project. I track some of these in a blog post about designing in the browser, but I’ll recap the main points here.
Clients tend to understand designs better once we get into the browser because they are more realistic and interactive which helps clients provide better, and more relevant feedback. In browser designs also foster more productive communication and collaboration with developers and reduce duplicated work. Additionally, designers have more control over the final, implemented design.
Finally, and possibly most important to the feedback process, it is easier to implement feedback and iterate on the design system in code than it is across multiple page comps. The feedback changes are instant, consistent, and more efficient.
Ultimately, this means that the client is able to provide more realistic and relevant feedback, which can be implemented and iterated on faster and more efficiently, all while the design process flexes and flows with development’s needs and prioritizations.
I think I’ve outlined a lot of the benefits of our forward moving design process, but I should caveat that we are still iterating on this process to make it even more efficient and effective.
One of the major gaps in this process right now is client education and buy in. It is often hard to convince a client, with little to no experience with web design, to adjust their preconceptions about the design approval process. It is also hard to get buy in, for example, that the homepage static comp does not have to be “perfect” in order to move onto the next deliverable. Clients fear that their feedback will be lost or forgotten or that it isn’t being taken seriously, when they do not see it implemented immediately. Clients often tend to be relatively uncomfortable moving forward with something that is not “Approved” or finalized for these exact reasons. One way we try to counteract that is with documentation, making sure we track and the requests changes and tickets.
It is up to the designer to communicate as best we can the benefits of this process to our clients upfront. I really believe that ultimately a client gets a better, more flexible end product when using this process.
I’d love to hear other’s experience with a similar process. Whether it is an issue you’ve run into and solved, or just with your own experience with a similar process as a client or designer. Leave a comment on this post or tweet to me @AshleyCyborski.
AM: Thanks for listening to this edition of The Secret Sauce. You can find more great tips on our brand spanking new website at palantir.net, and you can also find us on twitter @palantir.
Enjoy your day!

Project Stewardship and Understanding KPIs

On this week’s episode of The Secret Sauce, Joe Allen-Black and Luke Wertz explain how Project Stewards use a collaborative process to help our team fully understand and meet our clients’ business objectives and goals.
TRANSCRIPT
Allison Manley [AM]: Hi everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick bit of advice to help your business run a little better.
I’m Allison Manley, an Account Manager, and today we’re talking about Project Stewardship with Joe Allen-Black and Luke Wertz.
Luke Wertz [LW]: Hello, I am Luke Wertz. I am an senior engineer and a team lead here at Palantir.
Joe Allen-Black [JAB]: Hi, I’m Joe Allen-Black. I’m a project manager and a strategist here at Palantir.
LW: So today we wanted to take a few minutes to talk about this concept of project stewards that we have here at Palantir. When we’re planning out a project and planning for a project’s success, one of the first things that we do is try to identify individuals within our project team who will be responsible for ensuring a project’s long-term success, from the very beginning all the way through completion of the project.
JAB: What we want to make sure is that the success is defined not only by the fact that the website does everything that they hope and want it to do, and we’re able to feel great about the work that we can do, but we also want to be sure that we’re doing it within the budget constraints, within the time constraints, within whatever kinds of issues happen to be coming in — we want to make sure that we’re making the best site for all the different situations that we have.
LW: Yeah, exactly. We have come to this point of trying to identify two people to do this, from a long history of only having one person that tried to embody this from the beginning of a project to the end. And that person ended up going through some unusual changes during the course of a project, needing to wear many different hats: the business analyst hat, sometimes just having to refer to that person as an analyst, sometimes as an architect, sometimes as a technical lead, sometimes as a team lead — it got to be a bit much. And it was oftentimes difficult to transition well from the strategic planning parts of a project, that typically happen quickly very early on, and then into architecture and technical implementation. So we identified that this need arose to have two people playing this part on a project, and to work as a balance and counterbalance for each other.
JAB: What we’re ultimately trying to do is make sure that throughout the process our clients understand why we’re coming up with solutions, why we’re coming up with suggestions, as to how we can best work with them. And during the types of projects that Luke and I are on, part of my role would be to go through and determine some of the different features, some of the different ideas that we want to have the site include. And then, working with Luke, I’ll try to help facilitate the best way we can implement those in maybe the best order for those. The technical side is left to smarter folks like Luke to figure out, obviously. And then we try to make sure that together that the options are the highest-quality technical answer that fits within the constraints we have on the project.
LW: That’s exactly right. We spend a lot of time talking about what our client’s business objectives are, and their goals. And where I really rely on somebody like JAB, or somebody in JAB’s position, is to really have a deep understanding of the client’s KPIs and what those might look like in practice. And having somebody who is a co-worker and colleague who does that, and not being reliant on a client stakeholder to do that for me — it allows me to workshop ideas and to architect these incredibly huge, sometimes overly complex — some might be so bold to say, over-engineered solutions, and have a friendly face telling me, nope, go try again.
JAB: It’s friendly sometimes, you know, depending on the type of project [laughs].
LW: It’s always done in love [laughs].
JAB: We want to make sure that, when we come back to our clients and make a recommendation, we’ve been able to talk and that we understand the vantage points of both of us, and that we’re able to go, considering what we want to do. We know that we should spend a bit more time on making sure your workflow is the best, because that’s a pain point to you, and we might do that rather than spend a lot of time on some other part of the project. Or depending on the project it might need to be made sure that speed is in there, or that there’s something else that needs to be enhanced, and that might have to come at the expense of spending time on something else. What Luke and I are able to do is to make sure that we’re really keeping each other in check, and then we bring back the best possible options to our clients, to make the ultimate decisions on how they want to spend their budget and want to spend their time, but knowing that they’ve got great feedback from two folks looking at it from different vantage points.
LW: So what this looks like in practice for us is, starting from the first inkling of a project, when we’re still just in the very early stages of talking with a client about the potential of what they want to build, we will assign two people as a strategist and as a technical lead. And it is their job to be involved from the very first conversations we have about the actual production of a site to sit in together and to hear the same things from their own unique expertise, and to be able to hear from the clients and the many stakeholders that are often involved in those early conversations, so that we can fully encompass both the business needs and the technical needs that may be constraints or desires on the project. So we start this process early on, and build a very collaborative process where we’re checking in very frequently, we’re documenting separately the things that we hear, and then bringing our notes together and making sure that we’re hearing the same thing and are able to capture the same vision for what the final product is going to be.
JAB: Then throughout the beginning of the process I might be introducing different concepts for how we want to organize our data, how we want to have different pieces of the site speak to different audiences, while Luke is giving ideas on how we would structure that data, how we would be able to put that in a way that, at the end of the day, somebody’s going to be able to see that on the Internet or whatever type of tool that we’re building. And as that continues going on, we work with our client to get to the best ideas. As his team keeps working through the development, my goal will be make sure that I’m able to follow up, can take a kind of different view of it, gut-checking, to make sure it’s working the way we were expecting and for the right goals.
LW: So we’re both definitely involved from the beginning and throughout. But the place where our two separate disciplines and our mutual responsibilities as stewards on a project intersect is at the data model layer, which is a very developer-y buzzword. That’s my word, not JAB’s. But the output of our data model is typically a complete definition of all of the pieces of information that are going to be on the project, and what those pieces of information encompass. And so Joe has worked very hard up to that point to get a full understanding of the individual pieces of information that are necessary to meet the goals and KPIs of the project, and I’m working alongside him to define reasonable ways of storing those pieces of information in a well-defined database and data structures. And so the output of that process is a data model that the development team can then use to begin layering interactions and relationships, and begin to see the vision of the full thing come to fruition.
JAB: It’s definitely measure twice and cut once. So we’ll spend a lot of time talking about, what are the types of pages that we need, what are the types of elements, and then how do we break that into fields and how do those relate. So I will be talking with the client or with the people that we’re working with, and saying, hey, we really need a categorization that helps us bucket these items together. Or Luke will take that, and using a term like ‘data modelling’, turn that into what that’s going to look like on the back end, and how can we be sure that we don’t blow up the element by putting a bunch of code out there. So we’re able to have that approach in two different ways that ultimately hits that goal.
LW: At the end of the day, what we want to make sure is that any client we’re talking to, any client that we’re working with and trying to build a project for — we want to make sure that we have the right people around the table or the Google Hangout, as the case may be to make sure that we’re hearing correctly and exactly what the client needs. Because it’s not until we can fully understand what the client needs that we can build for them exactly what they want. So that’s really the role of the project stewards: it’s to be there at every moment of the project to ensure that we’re hearing and we’re listening and we’re responding appropriately. Thank you very much.
JAB: Thank you.
AM: Thanks Joe and Luke. That’s the end of this week’s Secret Sauce. For more great tips, check out our website at palantir.net, and check us out on Twitter. Our handle is @palantir.
Have a great day!

A Peek at Drupal GovCon

On this week’s episode of The Secret Sauce, we are joined by guests Kirsten Burgard and James King, organizers of Drupal GovCon.
TRANSCRIPT
Allison Manley [AM]: Hi again everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick bit of advice to help your business run a little bit better.
I’m Allison Manley, an Account Manager, and today we have a different Secret Sauce. Ken Rickard, our Director of Professional Services, recently attending Drupal GovCon in Washington DC in July, and got to sit down with two of the organizers: James King from the National Institutes of Health (NIH), and Kirsten Burgard from the US Department of State to chat about this annual Drupal event. So they are going to share what this event is about, and why you may want to check it out next year.
All right! Take it away Ken . . .
Ken Rickard [KR]:  This is Ken Rickard. We’re at the Palantir Secret Sauce podcast. This is our broadcast from Drupal GovCon, and we’ve invited two of the organizers to join us today: we’re with Kirsten Burgard and James King.
Kirsten Burgard [KB]: Yay! Welcome to Drupal GovCon.
KR: Thank you. This is I think my third or fourth . . . it used to be Capital Camp, and it’s now GovCon. This is the second year I’ve been here at the NIH, I know that. So tell me, how did the two of you get involved in this event?
KB: Well, it started . . . this is all really Tim Wood’s fault. He’s at the Department of Commerce. And he thought it would be really great if we all got together and started to do events, mini events where we could share information. The very first event one we did we had thirteen people. Then we decided to hold a larger event as a government-focused one at Commerce, and that was 2012.
KR: Yes, I was there,
KB: Yeah, we killed the wifi before 8:00 in the morning [laughs]. I had never seen that before. We thought we’d get about 200 people. We had 330. And at that event James approached me and said, “Hey, what about NIH hosting it?” And I thought, ‘this is never going to happen. Who at NIH is really going to make this happen?’ And it’s been James for three years now.
James King [JK]: So I did go to the Commerce event, and I had started using Drupal since 2010. When I got hired here in 2009, they gave me a project that hadn’t been started, and they bought this thing called Drupal and had a server, and I knew nothing about Drupal so I was learning on my feet Drupal 6. And I started playing with it and really liked it, and wanted to learn more about it. Found out about the Commerce event and that, like what was there, but saw how cramped it was.
KB: [Laughs]
JK: And wanted to get involved, and also selfishly wanted to be able to get more exposure at NIH on Drupal. I work for the NIH Library . . . the internal research library for NIH . . . and one of the things that we’re trying to do is foster community in different areas. And since I have a technology background, I’m trying to encourage use of technology across NIH. And Drupal being one of the things we’re working on, we were trying to encourage more people to know about and use Drupal.
So it made sense to at least try to have an event at our place. Since then obviously this has continued to grow, and we now have user group meetings as well just for NIH people. And those are growing as well.
KR: Yeah, the GovCon is a little bit of a special event of all the ones that I go to. Most of the ones that I go to are regionally-themed, but this one is industry-themed, or in this case, government service.
KB: Yeah.
KR: Public service themed. So, I mean, what are the goals of the whole idea? What are we trying to accomplish here?
KB: Well when we started doing DrupalGov . . . it’s actually called Drupal For Gov . . . we really just wanted to make it possible for government practitioners in open source communities to get together. Drupal just had the largest influx of folks within government. We also have Linux people, Wordpress people, Joomla people. We have a wide cross-section of open source CMS’ mostly, and some back-end things. And our primary goal was to make it possible for government employees to get access to the information they needed. Whether it was training, or collaboration, or even just innovative new thoughts and processes.
Oftentimes in government we’re very stove-piped. We don’t collaborate, we don’t cross sections. We don’t . . . even within my old agency, Department of Veterans Affairs, one section didn’t talk to the next section. It’s very confrontational almost between offices. So to make an organization like ours, which started with 11 people, to an event that now has over 1,000 people attending, is pretty weird [laughs]! It’s just pretty darn weird.
JK: So as a librarian geek or information professional, information architect, I very much embrace the idea of open source, but also government use. The government spends a lot of money with contractors developing themes, developing modules, so forth, at a minimum I wanted to try and bring together the NIH people to be able to share that. To not only share the products, the deliverables, but to share lessons learned, to share the modules they’re using, tips and tricks, to come together on training, and so forth. Drupal GovCon was an easy way to foster that.
Having it here on campus made it very easy for the NIH people to come, but we’re also trying to be a sharing, open environment, so we’re making it as broadly available as possible. That’s why we continue to try to keep it to be free so that any level person, whether they’re a budding sysadmin, or developer, or a UX person, we’ll be able to come and learn.
KB: And we’ll have something for them too. We have sections that aren’t just like the regular “here are the tracks,” but actually sections across the board, and on top of that, additional training too.
KR: Yes, it’s a very interesting lineup. You have a very diverse speaker group, and very diverse attendee group. It’s interesting too, a lot of the Drupal events are weekend events . . . this is during the week. And so it’s almost a professional event. I think that’s fascinating too.
So based on the success we’ve seen from the last few years, I was at the Commerce event, what are you hoping to see next year?
KB: So next year might be a little bit more difficult because like I said, we’re over 1,000 now. Our attendee drop is nowhere where it needs to be on a free event. So typically a free event will have like a 50% drop in attendance over registration. Ours hovers at less than 40%. That makes it much more difficult for us to gauge how many lunches to buy, how many cups of coffee we need . . . we ran out of coffee yesterday morning an hour into coffee service, and we bought 800 cups! We ran out of lunches really close to the very end, so it wasn’t as like a lot of people had to go buy lunches. I believe we ran out of lunches again today, but not badly . . . only a couple.
JK: No, we were pretty close. The auditorium seats 500.
KR: And that’s the biggest space we have available.
KB: Yeah. And what we do through the day is we flux space everything. So we try to  tell all the attendees, “Please, refresh your screens. Sessions will move.” And they do. And sometimes speakers forget where they’re supposed to be.
JK: I appreciate and I expect that we’ll continue to have that diversity as highlighted in our keynotes. The first day keynote was challenging attendees to really look at diversity and bias that’s in the industry, and how do we step back and address that. Today was more of a practical on how do we practically move an agency top-level site to Drupal. And tomorrow . . .
KB: Tomorrow it’s all security. We actually have the keynote from Velocity from last year, Laura Bell, who is a security expert from New Zealand. So I’ve had all kinds of fan boys come up to me and say, “oh my god, how did you get Laura Bell?” and I’m like, “I asked.” [laughs]
KR: That might be the lesson for folks to takeaway from this episode of the podcast is sometimes all you have to do is show up and ask.
KB: Yeah. Show up and ask. It works really well.
KR: All right. Thank you both for joining me.
KB: Thank you.
AM: That’s the end of this week’s Secret Sauce. For more great tips, check out our website at palantir.net, and check us out on Twitter. Our handle is @palantir.
Have a great day!

Key Elements for Project Success

In this week’s episode of The Secret Sauce, Director of Professional Services Ken Rickard gives an overview of his upcoming webinar that outlines the components that go into successful web projects.
TRANSCRIPT
Allison Manley [AM]: Hi again everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick bit of advice to help your business run a little bit better.
I’m Allison Manley, an Account Manager here, and today’s advice comes from our Director of Professional Services, Ken Rickard. He has some thoughts on why web projects succeed: how to do proper planning and how to consider all the components of a project.
A heads-up that he talks about a webinar he’s hosting on this very topic on Wednesday July 27th, but in reality we moved it to Thursday July 28th (the next day)! So be sure to join our mailing list on our website at Palantir.net, or email me at manley@palantir.net to get the information and get the link forwarded your way.
All right! On to Ken . . .
Ken Rickard [KR]:  Hi I’m Ken Rickard, I’m the Director of Professional Services at Palantir.net, and on the 27th of July [NOTE: moved to the 28th of July] I’ll be doing a webinar called “How Web Projects Succeed” in which we’ll take a look at how you plan, and then later execute, a project from end-to-end. And we’ll be looking at specifically all the different components that you need to be thinking about in terms of strategy and budget while you’re planning to do your next project.
So what we like to do is walk through all the necessary steps that are required in order to really get a firm grasp on the goals of the project: how you’re going to measure your success towards those goals, how you’re going to articulate those goals to your internal stakeholders, we’ll talk about how you develop personas and other understandings of your audience, how you use those to inform your design, and use those again to do some testing around those designs to make sure you have good information architecture. We’ll talk about content, in particular we’ll talk about content audits and content strategy, so that you understand how your message gets across in terms of your CMS architecture, but also workflow and all the other little bits and pieces that go into making a successful editorial experience.
So what I think you’ll find for people who don’t do . . . who aren’t in a web firm like ours who do dozens of projects in a year . . . you’ll find there are lots of little nuances and details that if you’re not planning for them, they will catch you by surprise. And if you’re not prepared for those surprised, you’re going to have a difficult time adjusting as the project moves on.
It’s a fairly informal talk, but we do drill into, “here are the things we know are going to happen, here’s what we advise are best practices, and here’s how you ought to be budgeting for things.” A good example would be if you’re not budgeting for quality assurance testing, what are you going to be missing out on? If you’re not budgeting for long-term support . . . it’s fascinating the number of people we run into who have a budget for getting a new site designed, but then have no budget for Year 2 or Year 3, thinking, “well once we do this, it will be done.” And that’s just not the way the web works! We’ve all been doing this for a very long time, and understand that the web is a dynamic medium, and the thing you just finished isn’t complete. There are just waypoints along the road of sort of ongoing marketing and development and things like that. So you are always in a position to want to make changes. You’re always in a position to want to publish new things. And in order to do that, you need a long-term maintenance strategy.
It’s interesting . . . I was talking to a client recently, and we had a very long conversation about how we could help them on their project. And it was interesting to me because I think they were looking for a technical answer. They were expecting me to give them a technical answer. And I said, “the three biggest things we can figure out for you right now are: what’s your editorial workflow? Because you’ve got 300 people stretched across 10 different departments who right now pass around Word documents in email. Then they go into the CMS and they go online. That’s Number 1.
Then Number 2 is what’s your governance plan going to be? And your governance plan is something that, again, people often overlook. And that’s about who can make what edits to content on the web, who has to approve it before it goes live, when does it expire, things like that. And your governance plan, along with your workflow, really dictate a lot of the architecture to how the CMS has to be built. In some cases it dictates which CMS you need to use, as some do things in one way and some in another.
And the third thing we talked about . . . again, I think they were expecting me to say, “here’s some technical expertise” . . . and the third question was: what’s your maintenance capacity? Because again, this was going to be a very large project for a number of different departments stretched across a number of different agencies. And they have a staff of six people! So we could architect the greatest solution in the world, but if they can’t maintain it, then it’s not going to be a successful project.
So we use those kinds of metrics when we’re talking about success. What does it actually mean two years on? Three years on? After the initial project is done? How are you going to support it, how are you going to interact with it? How are you going to make changes as you go? Those things are critically important. We’ve done very successful projects where the budget constraint meant we couldn’t do the architecture that was recommended, so we had to go with alternative methods in order to keep the budget under control. We’ve done projects where we’d like to do a certain architecture, but they only have a staff of two, and the staff of two can only maintain certain things.
So if you understand going in all the different things that have to happen on a project, which is again what we’re going to be covering, these kinds of questions become much clearer, and much easier to answer. And that’s something I think we really enjoy as a company . . . I’m not the only one . . . everyone at Palantir really likes digging in and doing that kind of collaborative problem solving. That is easier to do when everyone knows, ok, these are the puzzle pieces, these are what we are trying to fit into a successful project.
And I would leave with this one thought, which is the big question I always like to ask people when we’re kicking off a project . . . and you can think about when going into this kind of session is: six months after your project is done and the new site is launched, what will you consider success to be? Typically we find people who are focused on one or two aspects on the project, and they may not be the right one. Sometimes people are fixated on budget, sometimes people are fixated on hitting a deadline. And that’s generally not enough because the things that are driving those budgets and deadlines generally have business goals attached to them. So you have to know, well, really we’re driving to have this project done by the end of November so that we can hit the big conference that we’re throwing, and then we’re hoping to increase our membership 20% in the three month after that conference.
That’s the kind of thing that you need to be able to come into a web project being able to articulate. Because that’s what’s going to drive the design and the development of the project. So understanding when you’re hiring a firm to do an end to end project like that you’re not just hiring, as we say in my house, you’re not just hiring us to lift the couch and put it where you want it. You’re hiring us to do the interior decoration, the interior design as well. And to do that we need to know what kind of living space do you want? What kind of tasks are you trying to accomplish? What kind of business goals are you trying to accomplish?
Like I said, that’s a whole lot to swallow! But I think we can actually do it. It’s a 45 minute session, and it’s free to attend. Go ahead and sign up, and we’ll be happy to see you on the 27th. {NOTE: moved to the 28th]
AM: But remember, it’s been moved to Thursday the 28th!
That’s the end of this week’s Secret Sauce. If you’re interested in attending Ken’s webinar on Thursday the 28th, please go online to palantir.net/webinar. Hope to see you there. Have a great day!

What Can Support Do for You?

Web projects are a lot to manage, and that fact doesn’t change after launch. A dedicated support team can help keep things running smoothly and securely. Client Success Manager Cynthia Philpot goes over all of the services our support team can provide to make sure your project is a success, no matter the size.
TRANSCRIPT
Allison Manley [AM]: Hi again everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick bit of advice to help your business run smoother.
I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Cynthia Philpot, our Client Success Manager. Cynthia handles support for our clients, which is such a critical component of any website. Because once a site is finished, it still needs continuous maintenance and upgrades. She will be talking about the support services that we offer here at Palantir and how we can assist with your support needs.
Cynthia Philpot [CP]:  Hey Allison! Among the many other services that Palantir.net has to offer — like web strategy, consulting, designing and building some very cool websites, we offer ongoing client support.  
Whether you are transitioning into our Support department from an ongoing Palantir project, or if you are looking for an experienced company to support your existing website, we can address your needs.
As the Client Success Manager here at Palantir, I am the ongoing point of contact for all of our customers in Support.  Based on a relationship built on trust we interact on a regular basis to ensure enhancements, features, and other project needs are addressed.
The services that we provide in support are many. We like to begin with a site audit. The site audit is essentially a snapshot of your site. We do a technical review of the site, looking at things like the architecture, build, security — just to name a few. We then provide you with an audit report and walk you through the site findings. We provide information and recommend solutions about any urgent needs that we uncover and make short and long term recommendations to provide a roadmap for next steps. We can do the work for you if you like, or we can do a consulting or training engagement should you decide to do the work yourself. This is really beneficial for a number of reasons for a variety of different people based on their individual skill set levels and desired outcomes.
You will have unlimited access to our ticketing system, which our support team will monitor, evaluate, and use to respond to your requests. Be it a bug-fix, issue, or question, we will assign an experienced engineer to provide one-on-one assistance and work with you until the request is resolved.
We do security updates because keeping your site secure is at the top of our list. We check weekly for any security updates that may affect your site, and we’ll keep you informed on the progress and ensure the update is done in an expedient manner.
We can maintain a standing relationship with your hosting provider. So based on your specific issue and provided we have access, we gladly manage the relationship between you and your hosting provider on your behalf. We have standing relationships with most of the largest providers, and can assist in providing clarity when you receive important notifications and alerts.
I mentioned earlier that we perform a site audit but we also provide a Google Analytics audit to identify proper tagging, custom event tracking, goals, conversions, and any other customizations aside from a basic install.
As I mentioned early on, whether you need assistance maintaining a current site or perhaps needing to onboard a new employee, we can provide training to fit your specific needs. Palantir provides training and consulting in a variety of formats. Teaching is an integral part of our work.
We provide support for Drupal sites as well as other types of sites like WordPress too. If there are additional questions, I am available to provide answers and discuss pricing. Just give me a call.
Thanks!
AM: That’s the end of this week’s Secret Sauce. For more great tips, please check out our website at Palantir.net. You can also follow us on twitter at http://twitter.com/palantir. Have a great day!

20 Years of Palantir

Intro: Welcome to the latest episode of On the Air with Palantir, a long-form podcast by Palantir.net where we go in-depth on topics related to the business of web design and development. It’s July 2016 and this is episode #6. In this episode, Account Manager Allison Manley is joined by Palantir CEOs George DeMet and Tiffany Farriss.
TRANSCRIPT:
Allison Manley [AM]: Welcome to On the Air with Palantir, a podcast by Palantir.net where we go in-depth on topics related to the business of web design and development. It’s July 2016 and this is episode #6.
This is a special edition really, since this year marks the 20th anniversary of Palantir. It’s hard to fathom considering the internet was still very new in 1996, so there are very few web shops that have been around this long. Palantir started as a development agency, then over time added services such as design and strategy, to become the full, well-rounded, end to end company that it is today.
So we are celebrating our 20th anniversary later this month. I sat down with owners George DeMet and Tiffany Farriss to talk about how Palantir started, how it developed into the company it is today, and where we’re headed.
AM: Hello, Tiffany and George! How are you doing today?
George DeMet [GD]: We’re doing well.
Tiffany Farriss [TF]: Hi, Allison!
AM: Thanks for talking with me, I appreciate it. So we’re going to talk about the 20 years of Palantir. It’s hard to believe, right?
GD: It’s…yeah [laughs]. I’ve never really known anything else, it’s kind of funny.
AM: You’ve never had another job?
GD: That’s not true. I worked for my parents when I was in high school. They ran a disposal and recycling company. So I did have experience growing up driving a garbage truck and managing a recycling center.
TF: This wasn’t what I was going to do, but it is pretty much the only thing I’ve done. Other than having a NASA research grant as an undergrad, this is it.
AM: What were you going to do? I’m curious.
TF: I was going to go to grad school in astrophysics. That was my thing. I really wanted to do astrophysics, and I really liked cosmology in particular. I wanted to study the origins of the universe.
AM: Which we’re kind of doing [laughs]. So let’s have a quick overview of Palantir’s history. How did Palantir begin?
GD: So I actually started Palantir back in the summer of ’96, which was between my sophomore and junior year of college. I had discovered the Web back in the fall of ’94 when I was a freshman, and had really been kind of fascinated by it. It was very new – Netscape was still in beta at that point, and I was just really captivated by this idea of having pretty much anyone in the world being able to publish content that pretty much anyone else anywhere in the world would be able to read and access and view. I thought that was kind of revolutionary and I could see that this was the start of something kind of interesting, and I wanted to be a part of it. And so I started making some web pages, just sort of as a hobby. I made a fan page for ‘2001: A Space Odyssey’ that is still around today, after 22 years. And then I discovered that folks would pay me money to build websites and web pages. So after doing this freelance for a while, I decided it was a good idea to start a company around it.
TF: Because that’s what your family does [laughs].
GD: So that’s probably a little bit of helpful background. Both sides of my family are a couple of generations of people who started and ran family businesses. I mentioned that my parents have a disposal company. My mom’s father had a couple of grocery stores in Leavenworth, Kansas. My dad’s family ran the DeMet candy company, the folks that brought you the chocolate Turtle. So that was really kind of all I knew, right? Working for someone else was really not part of my DNA. So I knew I was going to do something, and when the web came along, it seemed like this was definitely something I wanted to do.
TF: For me, I started on the web around the same time, in 1994. It was kind of an outgrowth of my love of Latin [laughs]. That’s the other thing about me is my love of the classics, particularly Latin, and I was involved in the Junior Classical League in Ohio. I first became the membership director and then the president of the Ohio chapter, and for them I learned how to do HTML. And the web was so new and so exciting, and I had a friend who was at MIT who could give me server space. And this was just so cool that we could be out there and be doing that. So when I met George, when I started at Northwestern, I joined up with him when we were creating a website for our dorm, for Willard Residential College. And we really wanted – our residential college was eclectic, which is probably the best way to talk about it [laughs].
GD: I think the proper way to talk about it was pan-thematic. Most of the other residential colleges had a theme, like arts or sciences or engineering. We were all the things.
TF: We were all the things, we were all the interesting people interested in lots of things. And so we really wanted to do an amazing job creating that website, and that’s really how George and I started working together, in that capacity, and ultimately that’s how Palantir got its second client, or first paying client, depending on how you looked at it [laughs].
GD: That’s right. So one of the things I didn’t know how to do but Tiffany did quite well at the time was to actually go out and find clients. And that’s the skill that Tiffany brought to the table, in addition to her technical skills and managerial skills – really bringing some kind of structure to the enterprise, as it were.
TF: And it all happened in the way we still sell today, in that we’re looking for that good fit. You say, OK, this is what we can do and these are our ideas and this is what we bring to the table. And that’s essentially how we got – when I was a freshman and George was a junior – how two students got the job to do Northwestern’s main university site. It was also the 90s which was a bit of a Wild West [laughs]. But that’s how it happened.
We were at the awards ceremony for the residential college competition, which we won, of course [laughs], and I was talking to one of the judges who happened to be responsible for the web at Northwestern at the time. And she was talking to me about our thought process, and how we approached it, and I was talking about things that are so obvious to everyone now. The three-click rule. Thinking about how users would journey through the path and how you would organize information. And how you apply human-computer interaction theory to the web. But this being early ’97, you know, she said to me, I’m taking classes to learn what you guys already know, can I hire you for $2 an hour as a work-study? And I said, well, I already have a NASA research grant, so, no, but you can contract Palantir. My partner will be in Wisconsin but I can come in for meetings with you. And that’s how we got that contract, so that’s how it all worked out. And that first project was to redo the information technology site, and then in ’97 through ’98 we ended up doing the main Northwestern site.
GD: For the folks at Northwestern, I’ve heard people complain since about the fact that it’s northwestern.edu. We share a little bit of the blame for that [laughs]. But seriously, nobody calls it NWU. It’s Northwestern. Or maybe NU, but I think that might have been taken.
AM: Well, a pretty auspicious beginning, I would say. Now that you live in Evanston and the office is in Evanston.
GD: Yeah. We never moved [laughs].
TF: Well, this is the thing. I met George my third day at Northwestern, and we’ve been a couple ever since, but we’ve lived within a six-block radius since 1998 [laughs]. Our first off-campus apartment was literally a block over, two blocks away. This has just been where we’ve found a home. Neither of us is from here. I’m from Akron, Ohio, and George is from Wisconsin. We met in the middle and literally stayed.
GD: To be fair, I have some family connections to Chicago. My dad and his family are from Chicago, and so it’s always felt like a second home to me even though I grew up in northern Wisconsin. There’s also a lot more to do here, and it’s a place where even though we are a distributed company and have customers all over the world, it’s a really great place to be.
TF: What I like about it is that irrespective of a physical office, I do consider us to be a firm that’s rooted in Midwest values. And I love that Chicago means business, but it’s business with this ethic. You work hard and you play hard, and you treat people fairly, right? That’s the way that we do things here, and it’s really important to me. And even once we don’t have a physical office or we don’t have headquarters or whatever it is, it’s about the sense of philosophy of place, of being Midwestern. Of being very authentic, being very genuine, and bringing our best selves to what we do.
AM: What would you say, if you can project back 20 years, or 19 or 18 years, the focus was for Palantir the first couple of years? Was the focus just trying to stay afloat, was there a specific direction you were trying to take at the time?
GD: So if you go back in time to the mid-90s and remember what the Web looked like at that point, it was the era of Geocities websites, and everyone was into, like, banners that scrolled across your pages and little animated GIF clip art and animated background patterns, and just really horribly ugly garish sites that people were creating because they could. And one of the things that I really wanted to do at Palantir was to bring more of a design aesthetic to the Web. I really felt that it shouldn’t be too difficult to create websites that were not just functional but were actually easy to use, and didn’t make you want to claw your eyes out when you looked at them. So I thought there was a real opportunity there. Not just to be able to do business, but also to help make the Web a better place. And that was very much what we wanted to do, certainly for the first couple of years, and even beyond as we started partnering with other folks. I think making the Web look better and work better for people was really key in those first couple of years.
TF: And for me, I think – I agree with everything that George said, but I also felt very strongly about how the information was organized and presented. At the time it was a lot of brochure-ware. People were essentially trying to put these very linear experiences up on the Web. Now we call it ‘content strategy’ but at the time it was ‘information architecture’, and I really loved to think about the way to organize information in a way that made sense to someone who had no familiarity. It wasn’t about creating this highly linear journey for them, it was about – I saw the promise as being able to present information, to allow people to get what they wanted, but still to also come away with the message you wanted them to have. I thought that was such an interesting challenge, to be able to allow people to take control of how they gathered information, to really put the control back in their hands, but still to have it be that kind of alignment where you as the content provider were getting your message through, right? And that’s still a lot of what underpins our work today, is really this kind of ‘choose your own adventure’. And that’s where the name really comes from and why it comes into play.
GD: So the name is something I came up with. It represents this idea of interconnectedness. The Palantiri are these communicators that in a fantasy realm are interconnected with each other, so you can look in one and communicate with anyone else who has a Palantir. The dominant metaphor at the time when Palantir started was the information superhighway, and I felt that metaphor was really flawed because it implied this kind of linearity, right? But the Web isn’t like that. The Web is this very decentralized interconnected place, and it really feels more and it actually is this network of interconnected communication, of nodes, really.
TF: And it’s interconnected not just in terms of people, which it certainly is and always has been since its beginning, but it’s also in terms of content. What I love and what I find so fascinating and interesting is the notion that you don’t have to encapsulate all of the knowledge – you can just link to it, right? So you can tell a story and you can pull together these varied threads, and braid it together into a narrative in such an interesting way. And anybody can do that. It’s so accessible that it’s really broken down some of those traditional barriers that essentially gated who was able to define the narrative. So any person now can define that narrative and string it together. This is why a lot more of our work recently has dealt with APIs and what we can do to bring pieces of content from different systems together. And ultimately it’s why I’m so passionate about Drupal, because the ability to weave different pieces of content together but allow them to remain authoritative external sources is so exciting.
AM: So it seems that, 20 years later, what you had outlined for yourselves back then still stands today.
GD: Absolutely, no question. We’re still facing some of the same sorts of challenges. They’re very different in nature, but fundamentally it’s a question of enabling people to be able to access information, or to create information, or to share information in a way that’s findable, that’s usable, that’s discoverable. That’s what we started out trying to do, and that’s what we’re still trying to do today.
TF: I have this very Teutonic brain, I like things to be very efficient. So for me the notion that I could weave these narratives together but allow there to be single authoritative sources of information, I don’t have to duplicate it – it’s very efficient, it’s so compelling to me. And this is where I think you see a lot of enterprises getting too narrow, with their notion of the omnichannel strategies – where you want there to be a single source but you need to kind of customize what that experience looks like. And you really get – by being so efficient with presenting that information and where you’re sourcing the information, you get to focus your efforts on how you differentiate it in different channels and different contexts, and have other people mix and potentially remix your information. That’s what’s so exciting about where we are today, but it’s not that different than in ’96. We were really trying to get authoritative sources, that was the key, to kind of have those sources be out there and have them be integrated together.
AM: So you would say that Palantir’s core values and mission really haven’t changed at all, or maybe just better definition.
GD: I would agree with that. What we’re trying to do, how we’re trying to do it, really hasn’t changed. What has changed is that we’ve talked about it, we’ve articulated it more publicly. It’s not just locked in our brains [laughs].
TF: Right, it’s those notions of assumptions so deep that you’re not even aware of them. For so many of the early years, we just knew. And because we were a smaller company and everybody worked with George and I on a daily basis, you just kind of felt it. You didn’t know it. I couldn’t articulate it very well, and it’s taken us several tries to be able to get it to the point where we feel confident saying, yes, this is it. Because words matter so much, and there’s such precision when I use language that I’m constantly trying to make sure, is this the right word to use, is this really capturing that feeling that’s so deep in our culture that I want other people to be able to grasp onto it.
Because we do have this growing firm, and our folks here today – George and I are clearly the longest-standing employees of Palantir, but we have folks who start in a week. So how do they get a sense of the history? So it’s this notion that we have to really have those core values, as guiding principles, articulated so that, without knowing the lore and history of Palantir, they can apply it going forward. It’s really been an interesting challenge and one that George and I have been focused on for probably the last 18 months, is realizing that all that shared history has to be able to be communicated, has to be able to be transferred. And that’s been a really exciting part of the challenge.
GD: And it’s not just communicated, it’s also contextualized. That’s the really fun part for me.
AM: It’s very hard to define your own selves, too. It’s definitely tough work.
GD: It is. But I think it’s essential. I think it’s something that has been kind of a hallmark of who we are. It’s really this constantly asking ourselves and trying to be as self-aware as possible about who we are and what we do and why we do it.
TF: And also what we don’t do, right? I think that as we look at the growth over the last 10 years, it’s really easy to think that we were something we weren’t. We were never a start-up. We’re celebrating our 20th year so by definition we can’t be a start-up, and even in the past 10 years we weren’t a start-up. But it might have felt that way, or it might have looked that way. And so it’s on us, it’s our responsibility, to make sure that people understand – both our clients and our friends and our colleagues – that we are approaching this with very much a fundamental family business mentality. Really old-school principles. You don’t spend money you don’t have, you treat people fairly. This kind of notion that you’re always building, that every decision you constantly make has to be adding up to something. And I think that’s been – we certainly have friends who made other choices with their companies, whether they consider themselves a tech company or a start-up and they go after VC. We’re just not that. And we totally admire them and wish them well with what they’re doing. We’re doing something a little bit different over here. So in order for folks to understand that, we have to talk about it. We have to say, you know, we don’t spend other people’s money, we don’t spend money we don’t have.
It’s been such an interesting journey, particularly for me not coming from a family business background, to understand really what that means and why that applies and to be really proud of it. I really think that’s the compelling thing here. Because at the end of the day, I’ve always believed that what you do outside of work makes you better when you are at work. And you have to have time and space in your life for that. And I believed that before I had a family, and I certainly believe it to be true now. How I live it, how I articulate it, is very different. And I think that’s right, that’s appropriate, to be able to evolve with you and to be able to change with you. And that’s the kind of company that we’ve built.
AM: Well, one of the things I’ve noticed specifically about Palantir is how involved you’ve gotten in several communities. One of the reasons that I actually knew Palantir for years before working here was your commitment to design, which George mentioned was an early interest, and you did partner with design firms in Chicago when at the time you didn’t have an in-house design department, you were strictly development-only. So you were prescient and smart enough to know that you should partner with some very good design firms in the city, and there is a very strong design community here. And so you actually joined the American Institute of Graphic Arts board at one point, to become, I think, the Web liaison.
TF: Electronic Media Chair, yes. I was lucky enough to be Electronic Media Chair for AIGA Chicago, and that came after several years of working with and partnering with those design firms. And that was such an invaluable time in Palantir’s history. Chicago does have such a very storied and internationally respected design community, and the opportunity to work in such an early stage in my career, and in Palantir’s lifespan, with some of the best – looking back on it, it was unbelievable. To be able to learn and work so closely with really, really smart designers as they were making that transition from being exclusively print designers to thinking about interactive design and Web design – it was such a neat time for all of us. We were bringing this very digital sensibility with us and they were bringing expectations of typography and color fidelity. And those were things that were really difficult in that early Web. It was really amazing. And that all came out of our early work at Northwestern. We originally started out partnering with the information technology department over there, and through that work we advocated that the university relations people be included in that conversation. Because we felt that there was a role for branding and photography, and just design standards as part of the work we were doing for the Northwestern home page. And through that we ended up learning how to work with traditional print designers.
And our business has always been built on this word of mouth, on reputation. And so through that experience we ended up getting connected into the Chicago design community, and passed from firm to firm to firm, and I see that being appointed to the board was really the outcome from that, after the several years we’d been working with and partnering with design firms, from 2001 – I think it was 2001 when I became Electronic Media Chair, until 2008 – we had been working for six or seven years. But I still reflect on those experiences and what I learned from working with those folks, just in terms of how to relate to clients and how to really be a consultant. It was an amazing opportunity, it was really great. I’m really grateful for it.
AM: And around the same time, around 2008-ish, was when you started to get involved heavily in the Drupal community as well.
GD: That’s right.
AM: So a pretty pivotal year there [laughs].
GD: Well, the Drupal decision we actually made in 2007. We had started working with Drupal in 2006, but to lay a little bit of background, we’ve always worked primarily with open source technologies – open source software, free software, from the very beginning. The LAMP stack, Linux, Apache, MySQL, PHP, and used those technologies. And I had always been interested in getting a little more involved with open source on the content management side. We did a little bit of looking into that around 2001, when some of the first generation open source CMSs started to come on the scene, and none of them were really never mature enough at that point. And at that point we actually thought we could probably do our own, just as well if not better. So we had our own CMS for a while – it was called the Community Platform and we did four major versions of it, each of which was pretty much a complete rewrite. Was it just three?
TF: We were thinking about doing a fourth.
GD: Right, right. And that was a really interesting learning experience for us, because when you are responsible for creating your own product that you are then in turn using for customer projects, you have to really be careful. Because there’s a huge temptation to modify it or tweak it or change it every single time. So what we actually found was that we didn’t have one CMS, we had however many dozen CMSs, each of which was a bespoke version for that particular client, because we had had to make some sort of tweak for the business needs of that customer. Which was great in terms of the short-term customer need, right? Because we could very quickly and inexpensively roll out a site for a customer, get it up very quickly, but when it came time to expand that site or support that site or make that site do something different, it was incredibly difficult. So that was one of the big issues that we were running into. We had worked with some other proprietary platforms – there was a product that was being used by a lot of higher education institutions we were working with in the early 2000s. It definitely had its challenges, but it was something our customers were using and it worked well for a lot of our customers. And ultimately the company ended up deciding to end-of-life that product, actually without telling any of their customers [laughs]. We had a little inside knowledge on that, and Tiffany actually announced it up on stage at South by Southwest, I think this was 2007.
TF: 2008.
GD: 2008. And it was really kind of interesting seeing everyone flee the room when you made that announcement.
TF: The 20 people.
GD: The 20 people, yes [laughs]. I mean, you know, it was a pretty big session. So at that point, things were kind of – we realized we really needed to get involved with, you know, something that was going to be more widely supported by a wider community, and that also wasn’t going to be tied to the commercial whims of one particular company. And so I’m actually going to let you tell the story of how we started working with Drupal.
TF: It happened over several years, really. In 2006, Robert Petrick, who’s one of those amazing Chicago designers that we were lucky enough to work with, he brought us in on a project for Washington University in St. Louis. And the project was a little unusual, because it wasn’t an implementation project. It was going to be an implementation project, but first it started with a consulting project, where they wanted us to look at the available landscape of content management solutions, but both bespoke – our Community Platform was on the table for consideration – and open source projects as well as proprietary. And I helped them make the decision, and open source was absolutely the right choice for them. Again, we narrowed it down – should it be Drupal, should it be Joomla, and there were a couple of other options they were considering at the time. And for them Drupal was the right choice. So we built out that first site for WSTL in Drupal 4.6, and it was a little bit frustrating. But 4.7 came out actually before the site launched, and we immediately upgraded it to 4.7. We had looked at 4.6 before and not used it, because we couldn’t do the things we needed to visually. We were working with a lot of the design firms, and we couldn’t tell them, oh, the technology choice we’ve made won’t allow us to present the interface visually the way you want it to be done. That was why we had our own community platform, and in 4.6 we felt that was still very much the case, we were very much limited by that theming layer. Then 4.7 ended up being the right choice for Washington University in St. Louis, and we built out the site there, and it was still a bit frustrating but we achieved the level of fidelity we wanted. And as we were wrapping up that project and getting ready to launch it, Drupal 5 came out. And without launching the 4.7 version we ended up going to Drupal 5 right away. And that was when our team said, oh, this is different, and we can do everything that is being asked of us visually, everything we want to do visually. And by the way the security team that Drupal has is larger than our entire firm.
So it was really in early 2007, in February 2007, when we were faced with rewriting our community platform from version 3 to version 4, it was going to be a complete rewrite – I just looked at George and said, I think we need to deprecate our own CMS in favor of Drupal. I think we need to put our efforts in that direction. So the next month we actually sent George and one of our colleagues at the time, Larry Garfield, who’s known as Crell in the Drupal community, we sent them both out to Sunnyvale where Drupal was having a DrupalCon, to learn more about it. And George came back and said, I think this is a community you’d really like. And you could really get involved in this. Ah, I don’t know, let’s just start with where we’re at right now. And then you do fast forward, that year of 2007 was when we did a lot of our first projects. We got all of our clients off our own community platform, and any new project we’d start doing in Drupal.
AM: How were they when you suggested getting them off the existing platform and getting them onto Drupal? Were they receptive to that, or were they hesitant…?
TF: We did it gradually, as people needed new enhancements or new versions of their sites. At the time, none of the sites we were working on had particularly long life spans, right? And we ended up having to support the community platform for several years thereafter. So it was really when someone came to us for new work, it was, oh, here’s Drupal and we think you should move here for the following reasons. We would lay it out, but we weren’t going to do any new enhancements to it, and we told them very clearly, we’re not in active development on the community platform any more.
GD: One distinction that’s important to make, I think, is that with our own product, the Community Platform, it wasn’t an open source product, but we did have our customers have the right to modify the source code themselves. They just didn’t have the right to redistribute those changes. So if customers wanted to take on that responsibility of updating or maintaining the site themselves, they were certainly able to do that, or we gave them the option of moving to Drupal.
TF: Right. So really through 2007 and into 2008 – 2008 is really where we got involved in the Drupal community per se. And that’s when I went out to Boston, and I said, oh, this is a community I will love. This is something that – the ethos of it, getting to meet Dries and Angie Byron and Moshe Weitzman, all the early and very influential Drupal developers, and just how welcoming and how open they all were. And what we were able to build with Drupal was just so much more than we would be able to build if we were responsible for the whole stack. It just started to fall into place, it started to make sense that we could do more for our clients. And that’s ultimately what’s always driven us. We’re trying to add value. We’re trying to say, because the clients we work with have limited resources and are always under constraints, what’s the most we can do for them? How much can we accomplish, how much value can we give back to them? How much easier can we make their lives by the choices that we make all along the project? And Drupal was one of the ones that made a lot of sense for them. It had roughly the same implementation cost as any other proprietary or custom solution, but in terms of the long term, it was much less expensive. Because you didn’t have the long-term licensing fees, you had the community patching issues – so sometimes a client would say, oh, I’m noticing this bug on the site, and we’d say, oh, actually that’s a module that’s been patched in, we can patch that for you. It really opened it up and allowed us to focus.
So all these kind of pivotal points that you’ve noted in Palantir’s history, they come around our ability to focus. Right? So in 2001 when we really started partnering in earnest with design firms, it allowed us to focus and really hone our craft, and understand how to do content strategy and how to architect solid technical solutions. And then again in 2008, when we focused in on Drupal it allowed us to realize, okay, here’s how – only build what you absolutely need to build. That really allowed us to do more with our client budgets, and again, I would say 2016 is another one of those pivotal years for us, when we realized how to focus in and how to really get to the nugget of the business problem that needs to be solved. We have the opportunity now to influence businesses and the success of those businesses, and organizations as well since we do so much work with non-profits and higher ed in particular, and really how to solve core problems that aren’t technology problems. They’re problems that reach across the organization at every level, and so the fact that we’re able to focus in on it from that perspective, with that lens, I see that as another transformational moment for Palantir.
AM: It seems like you had some very pivotal choices that you made, in 2001 to 2008 in particular - partnering with design firms, choosing open source and eventually choosing Drupal – and that you were sort of on the forefront when the mid-2000s hit. That was when it seems to me, from my perspective, that you were a very big fish in a tiny pond at that time. You had this incredible design aesthetic and appreciation, you knew how to work with design firms at that point – you weren’t doing in-house design yet – and you were one of the few firms who had really embraced Drupal in particular. And that community was exploding, and I’m not sure if you could see that community was going to explode, if you were able to predict that.
GD: It was pretty apparent when I went to Sunnyvale in early 2007. That was a very small conference, it was maybe a couple of hundred people, and not all of them were Drupal people. But it was really, really clear just from the conversations that were happening and the folks that were there that Drupal was on the verge of becoming a big deal. And it was really funny, because I think the first couple of years that we started working with Drupal, we would go to industry conferences like higher ed conferences or museum conferences, and people would be like, oh, what do you do, and we’d say, we work with Drupal. And people would be, Drupal, what’s that? And then a couple of years later, we would go to the same conferences, and people would literally come up to me, like, I hear you guys are experts in Drupal and I need a Drupal expert [laughs]. So there really was a huge shift, I think, between 2008 and 2011, when Drupal went from being kind of this niche open source project that very few people had heard of that powers some of the biggest and most ambitious sites on the Web.
TF: And I think a lot of that has to do with the ecosystem that was built up around Drupal. Not just Acquia but especially Acquia, which is the firm that Dries Buytaert founded and is CTO of, that really brought a lot of visibility to Drupal particularly around hosting and 24/7 support. I think that was a really important moment for Drupal. But I think what was happening before then as well, not just with firms like Palantir but the work that Phase2 was doing in the government sector – there are a lot of firms both in the US and Europe that were doing this very ambitious very large-scale work. You had Examiner really pushing the development of Drupal 7, and then eventually the White House goes to Drupal, and everything that was happening with Warner Brothers and SonyBMG putting all their artists on Drupal – Drupal became this kind of de facto go-to. When you had a project that was, as George said, ambitious – it didn’t necessarily have to be large, sometimes they were technically complicated and involved a lot of integrations between different kinds of data sources. That was the kind of work that we did, both for higher ed and for museums, where we were combining, say, digital asset management systems with content management systems with active directory or LDAP-based user solutions. Any kind of complexity at that level, Drupal’s so good at tying those systems together. Or if you wanted to go headless, right now Drupal’s very good if you want to have, you know, no front end to your data source. Drupal just knows how to connect people, how to connect things, and it gives you such a good basis for what you’re trying to do, or trying to replicate. If you need a thousand sites, right, this is again what Pfizer does, and they’ve got such huge regulatory concerns that Drupal, you know, was just always there.
And those of us in the, I would say, the second wave of Drupal – Palantir’s not a first wave Drupal shop, we really did start to come on line with Drupal 6, and we were essentially writing for those pieces that our clients need. So again this is that ethos that we have, where we’re going to find that win-win solution. And what we did early on, and in particular when we made our name with Drupal 7 where we created Workbench, it was because this was a need that our clients had, and multiple clients had that need at the exact same time. It was a space that Drupal just wasn’t solving, and it was something that we had the capacity, we had the expertise in-house to be able to write. So we were able to combine pooled budgets from some of the smaller non-profit clients that we had, combine them together and get that better solution than they would be able to afford on their own, and make Drupal better – those are those niches that we’re constantly looking for. Okay, where can we add the most value here, where’s that problem that we can pull the resources together to solve – whether it’s people or time or money.
AM: Well, I think one of the direct results of – maybe Palantir wasn’t a first adopter, but pretty early, still, and the creation of Workbench which has proven to be very popular, and going back to the fact that those choices led Palantir to be a pretty big fish in a small pond for a long time – one of the things that I think is amazing about Palantir is that for 17 years, I think you told me, you never had to do any marketing.
GD: That’s right. No outbound marketing.
AM: That’s a dream, right? [laughs] To never have to look, the referrals came so naturally. But then, 17 years in, as Drupal became more ubiquitous and more people were adopting it and more people were recognizing the design abilities of it and the flexibility on the front end, marketing all of a sudden was needed [laughs] because there was more competition. So how would you say the landscape has changed? I’m going to guess that was a pivotal moment too, just how that landscape changed.
GD: Well, I don’t know that it’s a pivotal moment – I think it’s been a general trend we’ve been seeing over the past few years. And fundamentally I think if you – we talked about focusing, and that’s important, but if you narrow your focus too much and you find yourself in too much of a niche and people associate you with a specific technology or a specific type of client, that’s not a great situation to be in. And I wouldn’t actually describe us so much as a Drupal shop, we’re a full service boutique firm that helps customers be successful on the Web. And fundamentally the tools we use to accomplish that – what’s important to us is helping our customers make the right choices, collaborating with our customers, being able to help them to achieve success. Drupal is and historically has been a really great way to do that for an awful lot of our customers. But at the end of the day, it’s not about being the biggest or the best or the most well-known Drupal shop. It’s about being a firm that can help achieve success for our customers, in a really smart way. And because we were so closely associated with Drupal, that’s something we didn’t talk about as much. But we have started talking about it a lot more in the last few years. So if that’s marketing, sure [laughs].
TF: Well, I think it is. Early on, in those days when we were partnering, it was, oh, you’re the people who know tech who know how to talk to designers. So we want to work with you.
AM: Which is a valuable skill [laughs].
TF: Absolutely. And we keep it with us, we still have it today. But at the time, what we were doing was problem solving. We were hearing what they wanted, what their clients wanted, and how we solved it, right? But then you fast-forward to Drupal, and then we had this really great run where it was like, Palantir! You know Drupal! We want to work with you! But at the end of the day we did the same thing. You come in, you have a problem to solve. They picked us for different reasons and they were pleased with the outcomes, and that’s how we ended up getting those referrals and that engine. But as Drupal matured and as Palantir matured, and, quite honestly, as the Web matured as a channel in its own right, not kind of as ancillary to the traditional channels that businesses and organizations relied on – as it became co-equal and even dominant, the expectations of what people needed from the Web started to go up. So I think that the notion that, oh, you’re good at this tech thing was no longer going to be compelling, it was kind of a given. Oh, we’re going to bring you in as a partner, we assume that you have technical expertise, but we need to know that you have the strategic expertise to help us make those good decisions. And we need to know that you are going to work with us to help us build our internal capacity around this. Because the Web has gone beyond something that you would just give to, you know, your neighbor’s kid who knew how to do HTML, to, you know, the core of many businesses. And right now we’re in this era where even the oldest and most established businesses are going through digital transformation. It is reshaping how everyone works right now. So the expectations, and rightly so, have changed. They’ve increased, And Palantir has had the luxury of all of this time to mature and to hone our craft, and we are still excellent problem-solvers. That approach, combined with all the expertise we’ve built up over the last 20 years, makes us a really great partner.
AM: So now it’s July 2016, celebrating the 20th anniversary, and we’re having a company retreat – we’re shutting down everything for a week to bring all the employees, one from as far as South Africa, to Chicago so we can all get together and celebrate and – there’s going to be some work too, internally, but there’s going to be a lot of celebrating. So my final question: what would you like to see for the next five years, moving forward, or two years, what would you say?
GD: [laughs]
AM: Is it overwhelming, is it too much…?
GD: No, no – you know, actually a couple of years ago we set out a couple of very high-level goals for the company, and we’re kind of in the middle of the process of that, of working toward those goals. We refined them a little bit at the beginning of this year, but they’re still fundamentally the same. And it’s about helping our clients achieve success on all of our projects, that’s number one. Number two, continuously learning, sharing and applying new knowledge, and this is one I’m really interested in having us focus a lot more on in the coming years. That this learning and applying new knowledge is really not just about technical skill or expertise, but it’s really about new ways of understanding people’s problems and looking at people’s problems in new and different ways. And developing our skills internally in terms of being able to understand and address those issues and questions and concerns, and the goals that our customers have. And then of course continuing to be a sustainable well-run organization with healthy finances and a happy staff. Those are the three things we’re working on. I think when we get together here for our on-site we are going to really talk a lot about how we’re going to do those things, and figure out and talk about what we’re going to do. We’ve spent a fair amount of time over the past year talking about what we have done – you know, how we are where we are today – and I think it’s time to start looking to the future.
TF: Building on what George said, I think learning really is the key. It’s about taking what we learn on every project and elevating it to the level of organizational learning, and doing the same thing for our clients. We have a long track record of collaboration and we have clients who embed with us and who we help level up and we make kind of essential parts of our projects. And that’s fabulous, and that’s a huge service for capacity building for our clients. And I think the opportunity I see is being able to take that and transform the organizations as well, so that they also have an organizational learning moment. So for me, I’m really focused on the notion of making sure that we’re getting the most out of every opportunity, out of every decision, and understanding why things worked or why things didn’t work, and how we make it better. And it’s this notion of continuous improvement, and really making that a core part of our service. I see that as kind of the biggest change. Because as the industry and the Web kind of matures, and continues to mature, I think we’re getting to this point where we’re going to see fewer and fewer exponential leaps, and I think it’s going to start to plateau off. And so the notion that you kind of create and institutionalize incremental learning is really going to be key for us and for our clients. So that’s what I want to focus on – how we help them continuously improve, not only in their website and their Web presence and their infrastructure and their digital strategy, but how they can continue to incrementally improve their teams and their organizations to be able to take advantage of and recognize opportunities when they come up.
AM: And cake. There will be cake.
GD: I hope there will be cake. Who’s in charge of the cake? I’m not in charge of the cake! [laughs].
AM: Well, thank you very much. Looking forward to our retreat, and looking forward to the next five.
GD: Absolutely.
TF: The next 20! [laughs]
AM: Why stop at five? The next 20! [laughs]
AM: Thank you so much for listening.  I have to say, after three years of being with Palantir myself, and after having worked with them for several years prior to that, I’m thankful that I get to go to work every day with really, really smart and thoughtful people who are creating great work and toiling every day to make the Web a better place. So - happy anniversary, Palantir!
If you want to hear more episodes of On the Air with Palantir, make sure to subscribe on our website at palantir.net. There you can also read our blog and see our work! Each of these episodes is also available on iTunes. And of course you can also follow us on twitter at @palantir. Thanks for listening!