Plus Plus from Palantir.net

Palantir.net, Inc.

We discuss what’s new and interesting in the world of open source technologies, and agile methodologies. read less
TechnologyTechnology

Episodes

Los Drupaleros
Sep 8 2017
Los Drupaleros
Welcome to the latest episode of On the Air with Palantir, a long-form (ad-hoc) podcast by Palantir.net where we go in-depth on topics related to the business of web design and development. In this episode, Allison Manley is joined by Juan Daniel Flores of Rootstack, and Juan dives into the Drupal world of Latin and Central America. TRANSCRIPT Allison Manley: Hi, everyone. Welcome to On the Air With Palantir, a podcast by Palantir.net where we go in-depth on topics related to web design and development. I'm Allison Manley, Sales and Marketing manager. Today, my guest is Juan Daniel Flores of Rootstack. Juan spent some time with me a few months back telling me about all the exciting things happening with Drupal in Latin America. Here we are at DrupalCon Baltimore 2017-   Juan D. Flores: That's right. AM: ... in the convention center at the corner of Pratt and Charles Street. I am sitting with ... JDF: Juan Flores from Rootstack from Panama. AM: From Panama. You came all the way from Panama. JDF: Yes, sunny, tropical Panama. Yeah. The temperature is quite a good a change for me. AM: Is it? JDF: I was born in Colombia, in Bogota, actually. The temperature is more or less like this. I really miss the cool temperature, because in Panama, sometimes it gets really, really hot. AM: Well, we're welcome to give you a nice, rainy break, so ... JDF: Yeah, I appreciate it. AM: Is this your first Drupal Con? JDF: Yeah, this is my first personal, my first Drupal Con in the States, but we have been attending Drupal Con like, since five years ago. We are three partners, and they do most of the traveling. AM: Okay. Excellent. How long have you been involved in Drupal? JDF: We have been involved with Drupal like from seven years ago right after college. We graduated, and we got our degrees, and we started the company. We started with Drupal right away. We learned about Drupal, actually, by a friend in the college. It was like we saw the tool. We saw all the things that you could do, and we were like hooked up, like, "We have to do this. We have to use this." It's been quite a long time. AM: Wow. That's great. Were you self-taught or ... JDF: Totally self-taught. In the university, they teach you certain things, but to be, to thrive in this world, you really have to be very proficient in learning by yourself. You have to be active. You have to be checking what's going in the world. Thanks to our desire to know more, we picked it up and here we are seven years later. AM: And here you are. Glad to have you. You call yourselves the Drupaleros, sort of jokingly. JDF: Yeah, that's the term we use for Drupal. That's in Spanish. It's a term that we use in general. AM: Universally. JDF: Yeah. Universal. AM: So that's not just the Panamanian- JDF: Exactly. Exactly. AM: Okay. I feel like there's a presentation next year for just the Spanish-speaking Drupaleros. I feel like there's some sort of presentation you should make around that and what's happening in Latin and Central America. JDF: That will be interesting. Even though like I feel that we're a little bit late to the party, in terms of doing stuff, there has been a lot of work that has been done by Latin developers. For example, there's Jesus Olivas, which is ... Well, and the team from We Know It, that they have been working hard with the Drupal console project, which is picking up, really, a great amount of fans. He gave a talk yesterday. He's from Mexico. There's another guy. His name is Omers. He's also from Mexico. The other guys, Anso and Kenya are from Costa Rica. AM: How many would you say there are total between Latin and Central America, you know, that you keep in touch with on a regular basis working in Drupal? JDF: It's hard to tell to know a certain number because, unfortunately, the community there is like a little bit shy. But I can say that, for example, if I can measure events that we have gone to, for example, the DrupalCon in Costa Rica, or the DrupalCon Central America that we did a couple years ago, I would say we could see around 400, but it's hard to ... They show up for events. There are a lot of people that show at events. It's the the building the community that's hard. AM: How did you start out? Tell me about the beginnings of your business, then. JDF: We were in college. One of the partners approach to us. He told us like, "Hey, I think we should do this. We should make a company for our own." We are good, each one, in our own stuff. For example, one of the partners is very good at business development, organizing. The other one is very good at developing. He's a very strong skill set. I'm more like the creative one in terms of design, in terms of implementing the science. We're sort like a match in terms of our skills. We started that in 2010, and we slowly grew. We recruited guys fresh out of college from our own university. Then, we started to build the team. One of the things that I have heard here is that it's hard to find Drupal developers. Which if it's hard for you, it's harder for us. It's been years of finding good people that we think that can be a good fit and training them. I think there's a value in that, in home-growing the developers. Because if they aren't there, you have to make them. AM: Right. How big are you now? JDF: We are 25. AM: Oh, so you went from 3 to 25 in just seven years. JDF: Yeah. AM: Wow. JDF: We have 18 developers. Then marketing sales, designers, so yeah. We hope to keep growing, and yeah. Basically, the objective is to be bigger, to go for more services. Even though we started as a Drupal shop, now we're doing more stuff. We're doing automations. We're doing mobile development. We're doing interesting projects in terms of challenges. For example, last year we did a project for a company here. Basically, we did a mobile app in Ionic that you could turn on, turn off, set the temperature of your spa machine. They sell spa machines that have a wifi antennae. You could be in your office, and you say, "Oh, I'm going home." You start the spa. You set the temperature. When you get there, there it is. AM: That's excellent. JDF: Yeah. AM: That's quite a range of services that you do provide already, even if you feel like you want to add more. JDF: Yeah, yeah. It is to find projects that are challenging and interesting. That's the what we're looking for. AM: What would you say is your main client base or what vertical? JDF: Basically, companies that split in two, in terms of half the company works with agencies here in the States providing Drupal services, so back-end, front-end development, and the other half of the team works with local clients. In terms of local and regional clients, our main verticals are government, banks, certain industries, like ... You have big clients like supermarket chains, people that are looking for very complex web projects, or automations, or yeah, that kind of solutions that we can provide. Yeah, that's what we are ... The companies, like two companies in terms of what we focus on. AM: Fair enough. Your first DrupalCon, what do you think so far? JDF: It's been great. I mean, the level of the sessions have been great. I really like the fact that people are very open to talk, very friendly. I know that in our conferences that, for example, I have been, it's harder to meet people, to find a point of conversation where you can start. But here, it has been great. The parties have been great, also. They provide a good space for talking. For example, yesterday, I was with the guys at Lullabot. They were super friendly, super fun. We have a lot of fun. Yeah, I really like. It's right what they say about the Drupal community. It's very open and very ... Well, even though what has happened recently, I think the people here are very good people, you know? AM: I would agree with that. JDF: Well, I hope that you go next year to Nashville. AM: I will be there in Nashville. I would love to go to Costa Rica if I could swing it, but- JDF: Yeah, so there in August. It's super fun. There's a good vibe always. We always do some, like after the camp, we always do like a trip to an island, or a beach, or- AM: Forest. Something. JDF: Yeah, very relaxing. AM: Sounds amazing. JDF: You can add your vacations and you do a- AM: Any others to look forward to or ... JDF: That's the ones I think right now the top of my head. AM: All right. JDF: I think Mexico is organizing one, too. AM: Fantastic. JDF: Yeah. AM: Look forward to it. JDF: Yeah. AM: Thank you so much, Juan. JDF: Yeah, look forward to seeing you. Thank you. AM: Thanks for listening. Follow us on Twitter at Palantir or read our blog at palantir.net. Have a great day.
Getting Started in Drupal
Jan 9 2017
Getting Started in Drupal
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 January 2017, and this is episode #7. In this episode, Director of Professional Services Ken Rickard is joined by Cathy Theys of BlackMesh.   TRANSCRIPT:   Allison Manley [AM]: Hello and welcome to the latest episode of 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 January 2017, and this is episode number seven. This time my colleague Ken Rickard does the interviewing work for me. Ken was at GovCon in 2016, and was speaking with Cathy Theys, who is the Drupal community liaison at BlackMesh. She's got some fantastic information about how to get started in Drupal.   Ken Rickard [KR]: Today we're talking to Cathy Theys. We're at Drupal GovCon, which is a great event here in Washington D.C., Cathy is the Drupal community liaison for BlackMesh. Cathy, is there anything else we should know about you as we get started?   Cathy Theys [CT]: Let's see. Right, so Drupal community liaison. I go to a bunch of events for my job. I fix issues in Drupal. I had a long history of dealing with the mentor program. I tend to serve as a contact point when people have questions about how you get things done in the community or there's a tricky situation coming up, they might ask me my opinion on it, how to deal with that.   KR: I know you from the Chicago Drupal community. I know I run into you at a lot of events where you're helping onboard new Drupal developers.   CT: Mm-hmm.   KR: That's one of the things that you're passionate about.   CT: Yes.   KR: I think that's a really interesting question here at GovCon, we're dealing with a lot of agencies here who are new to Drupal. The keynote we just sat through was about moving the NIH onto Drupal for the first time. They talked about what that was like. I mean what brought you here, to GovCon specifically?   CT: BlackMesh, we're based in Ashburn, Virginia, so we're super close by, local. There's a bunch of us here, there's like eight or nine of us here, so it's really great because I travel a lot. I don't get to see my coworkers all the time, so I go to an event like this, we all get to hang out together and that's really nice. The sessions here are pretty top-notch. There's a lot of interesting topics, both for developers and for agencies. There's a really good range of beginner to advanced ones. It's really great.   KR: And I learned yesterday that I think this is officially the biggest non Drupal Con event in the United States.   CT:  Wow.   KR: Yeah. We surpassed [inaudible 00:02:32] bad camps, so that's good. I want to go back to again your role in the communities to help onboard new developers.   CT: Mm-hmm (affirmative).   KR: In particular, you're a liaison to make it easier for folks to work with Drupal. Like I said, in the keynote, we were dealing with an agency coming on to Drupal for the first time. I think my first question really is, for a government agency or other organizations using Drupal for the first time, what advice do you have for them getting started?   CT: The very, very first thing, I think is important is that the agency makes sure that they have an organizational node on Drupal.org. That's just a piece of content where you can put your logo and your company description. It just allows a way of referring to yourself within the Drupal community. Drupal.org is really important for the Drupal community. It's the hub of everything and it's our central conical repository for asking questions and getting answers. So just establishing your agency is the very first thing. Then I think the next thing that's important to do, is to take anybody associated with that agency that might every touch Drupal and make sure they have user accounts. The profiles on these user accounts can be quite complex, but there aren't a lot of required fields.   It's like pick a username, give an email address, you don't even have to say your real name, but what the agency wants to make sure that their developers do, or not their developers, their tech team, right, does is makes a user account and associates it then with the organizational node that's there. That will immediately open up a lot of doors for getting information out of the community. Without that it can be really difficult to really get the most benefit out of it. Those are I think the first steps.   KR: That's interesting to me because we're making, I think we started with the assumption that you're going to have to interact with the community in order to get your project done and be successful.   CT: Yes, absolutely.   KR: What is it I guess about Drupal that makes that sort of a requirement?   CT: Some parts of Drupal are core, the central package, and other things are contributed projects, themes, modules, distributions. Then there's also custom code, the internal tech team might put together. Much of that is extremely high quality. Some of it isn't. Some of it has information about how to use it, but might be targeted towards a particular kind of role in a company. If the documentation for something is targeted toward a site builder, and you have a back-end developer trying to figure out what's going on, the quality of the project can still be good. The documentation is kind of sort of in place, but it still might be confusing if that documentation isn't written for exactly who you are. So you might want to clarify something with somebody, because when you have a chance to clarify something, ask a question, and get an answer it means that the total time that you spend trying to figure something out will be shorter. Typically, that means it costs less. I think that's really important for agencies.                                                   They want to make that their people are very efficient so that the project can get done in a reasonable time. There are not scary reasons for needing to interact with the Drupal community. I think a lot of projects will just have questions and clarifications and very little custom code that they need to do. But they may not realize that that's possible if they're not talking to Drupalers and getting those clarifications. They might go off on a wrong assumption like, "Oh wait, this doesn't do what I want. I'm going to do a whole bunch of custom stuff." When you have the chance to interact with people, you can kind of make sure you're on the right path. You don't go down that way of getting on a custom code. You may have some and that can be really good, but custom code is very difficult to maintain. Especially if you have turnover in your tech team.   KR: Mm-hmm.   CT: And if you don't have automated tests for it, then that can additionally be complicated. When you're just getting started on a project, right, you have this clean slate. You haven't changed Drupal, you don't have any of this custom stuff. If you know that you want to limit your custom stuff, and then talking with the community can help you do that. I think one of the reasons, in addition to maintenance of custom code, one of the reasons why keeping that to a minimum is important is for security reasons. Interacting with the Drupal community can provide a really nice opportunity to make sure that your stuff is secure.   When you do have to make custom code or patch a module or whatever, and you ask the question on Drupal.org, typically perhaps an issue associated with the theme or the module that the question is about, that gets you started in the right direction. Then you may be like, "Oh. Well I think it should be like this." Or "This is the custom solution we're going to use with this." Because you have the issue, because you asked the question, then you can present the changes that you think are needed on the issue. When you do that, what you get is you get the entire Drupal community, which is quite large, I mean it's got to be, life if you add up people who contribute to contribute stuff, then it's got to be like 10,000 people, I think.   KR: Right. It's a gigantic international community. One of the advantages we always talk about with open source is essentially that none of the problems you're talking about are unique, right? Your project is special to you and it's important, but it's-   CT: And the combination of aspects of your projects could be quite unique. Individually, those have probably come up already.   KR: Right.   CT: Yeah. Then when you post these changes on this issue where you started asking just some questions, and you have the whole entire Drupal community what you get is a chance that somebody in there might have experience with evaluating changes and their security implications. They might see your change, they could run across it, spot something, and then ... Nobody's going to do that and not reach out. The way people reach out then is a lot of different ways. It could be in a comment on the issue, it could be contacting somebody through their user profile, it could be going to look to see what company they look at and who else works there. So that ties back to this first step, right, of the organizational profile and the user profiles. I think for government agencies, security is quite often a very big concern.   The nice thing about doing this, or the opposite of doing this let's say, right? Is you start your project, your internal team you're like, "Go learn Drupal. Go do it." And they don't ask anybody questions, so they want to change something, and they keep their change internal only. Then they don't even have a chance to get this free, possible security audit. I mean it's not a formal thing, but if you don't put it out there, on Drupal.org, then you don't even have that opportunity and you're completely missing it.   KR: Right. It's worth noting for people who aren't aware. So we talked about sign up for an organizational cap, the next thing you have to do really is sign up for security alerts. Security notifications I mean, security notifications come out every Wednesday.   CT: Yeah.   KR: Sometimes there's none sometimes there's several. It's worth noting that any module that you download from Drupal.org that has an official release, it's not an Alpha software, it's not a Beta, is covered by Drupal security team.   CT: Right. What that means though is not that it gets a security review before release, but that if somebody notices a security problem that they can bring it to the security teams attention, typically privately. Then somebody will look at it. It's reactive in that sense. The security team also does several proactive things, but it doesn't just be like, "Oh you can't make an official release until we look at your code." We don't go quite that far.   KR: Right. But it is nice to have that layer of accountability, so when we say, "Oh we think there might be a security issue with his implementation." You can report a security issue and the security team will have a, essentially someone who's trained in security review take a look at things. Yeah, I've participated in those issues. It's quite an impressive process.   CT: Yeah and super high quality people that have a lot of experience looking at it. I'm also on the security team, but I'm a new member. Mostly I just help other people with things. Like you asked, you're getting started, what are some of the first steps? We talked about some of the things. Making those profiles, starting to use Drupal.org to talk to people, to ask questions, and to post possible changes. I think the thing is the agency, it would help the agency take advantage of all these benefits only if they have their tech team doing this. So putting in place some internal processes that encourage this will help make sure it happens. If you want somebody to do something, you should give them an environment where it's easy for them to do it and they see the benefits from it. If you can, you make doing it part of a bigger process.   Yesterday, here at GovCon, I went to see Damien Mckenna's talk. It was called Free, Libre and Open Source Software and You. It was absolutely about this. You have an internal group, you know you should be doing something with the community or contributing, like what the heck do you do? So I highly recommend that people check out his information that's on the GovCon site, it's on the schedule for Wednesday. But there were kind of two or three important things I think that I can say pretty quickly and that is that one step to encouraging people to do this interaction with the community is just to start tracking the interactions that happen. Without necessarily asking, like setting expectations for what people should do. Every project that you answer a question on or things, like just start tracking the interaction that happens. So you can see how that changes over time. I think that's good to have in the process.   One of the ways to encourage communicating on Drupal.org about things, and have it be part of the process, is internally when you have to make a change to something is to track as part of the identifier for that change, the issue number and the comment number. You can't then internally track it as part of your process, if it doesn't have an issue and it doesn't have a comment number. So you could make some kind of standard like in your git-commit message, make sure you use this pattern in this string. Or when you name your patch file, or when you set up your composer json and you're pulling a change, that part of documenting that is the issue it came from and the comment number. Then you can't really get around it, because it's like, "Oh I can't commit it without a number." And then people do and so that can be really nice.   I think the other kind of getting started recommendation that Damien had that is pretty decent is to plan for your tech team to have 10% where they don't have to track what they're doing. So it's not like directly billable or on a particular thing that's in the current sprint, but it's just 10%. Damien says people can do things like four hours on Friday afternoon, tends to work pretty well because you don't really want to be deploying any changes on Friday afternoon, but you have these people and you're paying them to do something. So they might as well be doing something productive.   KR: Right. He's basically talking about, baking aside sort of 10% is internal training time or just community time.   CT: Yeah.   KR: To get things up to speed.   CT: And for that it can help to have some sort of orientation for people. Some agencies might identify one person on their tech team, like you said, that will spend a significant part of their time figuring out what the heck this community is and being the point for communication there. If people don't have that, they might want to get ramped up by bringing in somebody for maybe a day, or two days, and be like, "This is how you communicate with the community." Because telling people, "Oh you have 10% time to do whatever you want." They're going to do things that they're interested in and probably that they kind of sort of know already. If they're like, "Yeah 10%, I could contribute to some Drupal project." And they've never done it before, and they're all on their own and they don't know what to do? The odds of them using that time for that are kind of low. Including some kind of orientation for how to do that will help make sure people can be successful when you expect them to do it.   KR: It's good also to review the types of contributions that people can make, because this is something we talk about with contributors all the time.   CT: Yeah. I switched my description of talking about who these people are, the tech team, right? Halfway through the conversation.   KR: Right, right.   CT: Because I think people have this expectation that the only people who might be doing this interaction with the community are back-end developers, or possibly [inaudible 00:17:14] femors, but that's really not true at all. It's site builders, and junior people on the team. It could be anybody because there's so many different levels of questions. It could be like, how do I use this API? Or it could be like, I'm evaluating these three modules, or it could be we have this ambitious goal for this project, can we even get it done? Those are not all the same role, but they're all on the tech team.   KR: Right, correct. Editors have questions too. We were working on a project and I had to say, "Hey I'm using the Wizzy Wig to upload images, but I can't upload files through it. So what do I do?" And the answer was, "Well we go to Drupal.org and we look around and know if there's a module that handles that." Yeah. It's a project question. CT: Right.   KR: And it's a technical question, but it's not a developer question.   CT: Right. I think it's nice when we're ... One of the super awesome things about the Drupal community that is a little difficult to explain to people who might be getting involved, is how thoughtful the Drupal community is. How we're always looking at the processes that we have, and can we improve them, and what happened, and what should happen? One of the ways that that can be apparent that that's part of our community ethos is that we frequently go through changes in language that we use to describe things. So that we can be usually more accurate, and also more compassionate, more inclusive.   KR: Mm-hmm.   CT: I like that when we use language that's more inclusive, we're quite often being more accurate. Like an example here at this event, and a lot of Drupal events that people might end up going to, is that we use a lot of rooms. We take over conference centers, and typically one of the areas in the past used to be called The Coder Lounge.   KR: Right, right.   CT: Over the last couple years, people in the community who may not be even involved with the camp, sort of take ownership of things. It's open source, right, you see a problem and you fix it. Sometimes people will take sharpies to signs that say Coder Lounge and they'll make them more accurate and also more inclusive, by crossing it out and changing it to Contribution Lounge, because that's what happens in those rooms. When people get together and they're like, "I had this question about Drupal. Perhaps it's an issue we might eventually need to fix something." Or, "I have a question about an issue." So the activity in those rooms is not people coding always. The people in those rooms are not just coders. You can get usability specialists, designers, all kinds of people, marketing people.   I was in Montreal recently for Dev Days, which was a Drupal event. I was in the contribution area and somebody was walking through and they're like, "I need help." And people were like, "Well what do you need?" And they're like, "I need a native English speaker." I'm like, "I'm a native English speaker." And so I started talking to them more and it turns out they were working on writing a showcase that featured their new distribution that they were putting out for Drupal 8 that is going to be kind of the replacement for commons. This person, which was like the project lead, and they had their whole team there and they were doing last minute changes to make this distribution available so a bunch of people could get a nice benefit, not just their agency.   Stated explaining to me, and I was reading the showcase that they wrote, and we didn't just end up talking about grammar and native English things. Because I'm outside to the project, and I'm not familiar with it, and I don't have any expertise in commons, I had a lot of questions. There were some wordings that they thought were clear and that I didn't think was clear. They would switch audiences sometimes, like sometimes be talking to developers or evaluators. They were talking about the community as us sometimes and sometimes the agency is us. Just because I didn't know anything about their project, we were able to work through this together. We actually had a super fun time. We were able to work through this together and come out with a much better showcase that then ended up being a featured showcase on Drupal.org.   Was that coding, in a Coder Lounge? No. Was it contributing to the success of a project? Absolutely. Was it somebody working on the computer by themselves? No. It was just me asking questions. I would read it and I'd be like, "Well what does that mean?" I didn't even have to know anything and I still helped with the contribution. So when we say tech team, it really is more inclusive. When we say contributing, we really mean contributing in the widest possible way.   KR: Yeah. It's probably good to wrap up by talking about that concept of contribution and collaboration. I mean it is one of the driving forces I think for why people, especially government agencies, would want to use Drupal rather than a propriety system. Because this idea is, if we solve this problem the first time then it can be reused. Reused by other people.   CT: Mm-hmm.   KR: For example in Australia, the Australian government has a common Drupal distribution that all agencies can use to kick start their projects. Sort of a fascinating piece. A lot of the stuff that we've been talking about here is around baking that knowledge into your project. Making sure that your project is planned with these interactions in place.   CT: Yeah.   KR: What I'm getting at a little bit is are there parts of your project that you don't want revealed immediately? Is that you need to be planning for? Because sometimes there is proprietary business logic or-   CT: Yeah absolutely.   KR: Or secret things. So do you need to be planning out like, this is release worthy. I'm thinking of an example from the White House. The White House, for example, very specifically released certain code when they did their big WhiteHouse.gov project.   CT: Yeah.   KR: So is that something that sort of project managers ought to be thinking about upfront?   CT: Well you definitely can't just release everything. Perhaps including a little bit of research into the project as to what the common best practices are, and how people make that decision, and being able to spend some time educating your team is good to build into the project. Doing that, when you do decide to keep some things private, doing it with the understanding of the costs of that and the repercussions. It can still be the right decision to make, but you would want to do it with the knowledge of what's going to happen because of that. Like you are solely responsibly for maintaining it. You are going to need to invest more money in doing maintenance and security, and all these other things. It can still be the right decision, but it's going to affect the project differently.   KR: Mm-hmm.   CT: Even if you make that, it's still good to understand what the benefits would be if you did release it, so that you can understand what the cost you are incurring are when you don't.   KR: Sort of as a wrap up, is there any sort of last pieces of advice you have for people getting started? Like the best thing you've ever done or that sort of one special thing? Maybe, I mean what's the best way to approach the community? It might be a question, like you've never contributed before, you have a question, I don't know.   CT: So the best way to do it, is to start digesting the stream of information that's coming out of the community. Pick your favorite medium, I really like podcasts, there's Drupal Planet RSS feed, that aggregates blog posts and announcements together. Many camps record and publish, for free, their sessions. If you like to watch something, listen to something, or read something, like pick whichever one those are, and just time box four hours or whatever, over a couple days and be like, "I'm going to learn something about whatever." Because whatever information you're looking for it's out there. People communicate really, really well in the Drupal community. The one thing I want to add, when we talked earlier about first steps, and we talked about making user accounts and you mentioned signing up for security email lists. The way people do that is in their profile.   KR: Right.   CT: You can subscribe to the security announcements via their profile. Profiling is super important.   KR: It is super important, because it's the way that we do communicate. I want to thank you for spending the time with us today. You've been really fun and informative.   CT: You're quite welcome. It was nice.   AM: Thank you Ken and Cathy. If you want to hear past episodes of On the Air with Palantir, make sure to visit 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 follow us on Twitter, @Palantir. Thanks for listening.
Remote Teams
Oct 17 2016
Remote Teams
With the advancement of technology, there are infinite ways and opportunities to work remotely, no matter where you are. In this week’s episode of The Secret Sauce, we share some strategies for making remote work - well, work. 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, Sales and Marketing Manager here, and today’s advice comes from Scott DiPerna and Lauren Byrwa. In this global economy, there are infinite ways and opportunities to work remotely, no matter where you are. Scott and Lauren are going to share some strategies on how to collaborate successfully across great distances and time zones. Scott DiPerna [SD]: Hi, I’m Scott DiPerna. Lauren Byrwa [LB]: Hi, I’m Lauren Byrwa. SD: Recently we worked with a client in California who had hired a content strategy team in New York City. Lauren, with our development team, was in Chicago, and I, as the Project Manager, was in South Africa. We had lots of interesting new challenges in this project, and like we do in most projects, we learned a lot about working well with our clients, our collaborators, and with each other. LB: So, Scott, what was it like trying to work from South Africa, being seven to nine hours ahead of everyone else? SD: Well, it wasn’t that different from working remotely in Richmond, Virginia. I do shift my working hours to the evening to overlap with the team in the States. But just as I did in Virginia, we do all of our meetings on a video chat regardless of where we are. It’s part of our process especially with our clients being all over the country, so that part wasn’t really different. But we did do a few things differently in this project — not so much because we were all in different places, but because we had multiple vendors and teams collaborating together. Do you want to talk about some of the adjustments that we made in terms of meetings? LB: Yeah, so we met with the content strategy team weekly. We met with our product owner three times a week. We met with our full team, our full team of stakeholders, weekly. And in addition to that we still had all our usual agile ceremonies like scrum, demos, retrospectives, that we always do on projects. These meetings especially were productive because we had all of the strategic functionality up front, and we could ask specific implementation-level questions early on, and we could vet them both with the product owner specifically, with the strategists specifically, and with the entire group. But I think there are a few other ways that the thorough strategy helped. Do you want to talk about those? SD: Sure. I think there were two parts specifically that were really helpful. Doing a lot of the strategic planning up front meant that the client was a lot more conversant in the details of the product that we were planning to build for them. We just had a lot more conversations with them up-front and could talk in detail. The other piece was having much of the functionality visually documented in wireframes that the strategy team kept current with changes in the functionality meant that the client always had a “picture” in their minds of what it was that we were talking about. When everyone is working remotely from one another, these kinds of visuals help conversations over video chat be infinitely more productive, which I think is something we see in all of our projects. So all of this planning had a really helpful impact on your ability to estimate the work up front, too. Do you want to talk a bit about that? LB: Because we had the complete and canonical wireframes from the strategists we were able to fairly precisely estimate all of the functionality that they had scoped out in those wireframes. This meant that even before we started development, we were able to work with our product owner to go over in detail the scope of work we anticipated to be able to complete within their budget. We had many conversations with him about what features would be most important for their users, and were able to prioritize accordingly. It meant that we could talk about the specifics of our implementation in really granular detail internally, both with the strategists, both with the product owner. We collaboratively evaluated if there were options to streamline our implementation, and we were able to address specific questions that usually would not come up until user acceptance testing.   All of these conversations resulted in updates to both the canonical wireframes that the strategists were maintaining, as well as the implementation documentation that we were maintaining on our end. And it meant that the picture that the strategists had, that they kept, that the clients had in their head, stayed the same. And it was all reflected in what they could expect to be spending on the implementation for development. SD: Right. And since we were documenting those functional changes in the wireframes, we could capture that quickly and review it with the client in the middle of a sprint. And speaking of that sort of adjustment in the middle of a sprint, you started doing mini-demos of work in progress, demoing that to the product owner. Can you talk a little bit about why you shifted in that direction? LB: Yeah, so because we already had all of these meetings set up, and because we already had those canonical wireframes that showed all of the functionality in the picture, we wanted to make sure that they could see the picture of their website, the implementation, as quickly as possible too. So when we had specific implementation questions about things that were spec-ed out in the wireframes, we would demo it for the client. And they could vet it, both for the client and the strategists, and come back to that . . . is this the best choice for the user. It meant that all of those questions of, is this the best route to go down, does this work the way that I anticipated it to, were answered not even before user acceptance testing — they were answered even before the demo. So we could pivot our strategy accordingly, and we did on a lot of issues. SD: So given all of these constraints that we faced on the project, where we had a client in one part of the States, a content strategy team in another part of the States, even our own internal strategy team split up across continents, and a pretty sizeable project with some interesting technical projects to solve — what were some of the biggest take-aways that you had from that project? LB: I think the number one thing that I took away from that project was that we can solve every problem together, and that we can come to a better conclusion when we come to it together. The collaborative effort with the strategy team to focus conversations through the lens of the primary audience really helped us anchor our strategy and our implementation in that primary user, and not in some of the other things that often derail projects. We had complete and thorough documentation both on the strategy level and on the implementation, and both of those were transparent to everyone accessing the project. And I think that really helped us to streamline the entire project. SD: I think for me one of the other things is that we were able to form really good relationships both with the client and with the third-party team we were collaborating with. And that made all of our conversations run more smoothly. We were able to have fun even in the difficult phases of the project, and even going through tough negotiations around scope or functionality or budgets or stuff like that — having those good relationships and having that good level of communication with them just made the whole process go more smoothly. 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 @palantir. Have a great day!
Collaboration Tools
Oct 11 2016
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
Sep 20 2016
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
Sep 13 2016
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
Sep 6 2016
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
Aug 30 2016
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
Aug 23 2016
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
Aug 16 2016
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
Jul 22 2016
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?
Jul 21 2016
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
Jul 15 2016
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
Sync Your Sales and Marketing
Jul 5 2016
Sync Your Sales and Marketing
Sales and marketing tactics can complement each other well when used collaboratively. Learn how Palantir intertwines the two disciplines to better understand (and reach) clients. TRANSCRIPT Allison Manley [AM]: Hello and welcome to The Secret Sauce, brought to you by Palantir.net. This is a short podcast where we offer a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an Account Manager at Palantir, and today’s advice comes from Alex Brandt, who talks about how to combine sales and marketing. Alex Brandt [AB]: A lot of people think of sales and marketing as two separate entities, but the truth is they can both benefit greatly from working together. At Palantir, our sales and marketing efforts are strongly intertwined, and we have found this approach to be extremely effective. For starters, sales helps marketing by informing content. Most often, clients have their first direct interaction with a company by communicating with the sales team. That means the sales team is hearing firsthand what new clients are looking for, what their goals are, what pain points they are dealing with, and ultimately what they think will make their project become a success. The sales team also has a good view into what kind of clients are reaching out. For instance, we have seen a shift in what roles are involved in managing a website redesign. While we used to interact with mainly Directors of IT and other similar technical roles, we now see a lot of marketing teams heading up these kind of projects. This valuable information helps inform what kind of content we should be producing. If we are speaking with more marketing folks than technical, and they are coming to us with new problems and goals, the kinds of resources we are providing for our clients should reflect that. And if this trend shifts again, our sales team will be the first to let us know so we can pivot and adjust. In turn, marketing helps sales by providing a gateway for conversation. Now that the sales team has helped clue us in on what kind of content we should be producing, our marketing team gets to step in and create compelling resources that make people want to work with us. These resources get distributed across different channels and open a path to conversation with sign-up forms for free consultations, newsletters, and webinars. But most importantly, an open and collaborative approach gives all team members the context to keep messaging consistent. Whether it is coming from a blog post, an introductory phone call, or a presentation at a conference, the message a brand is communicating needs to be consistent and in line with what your clients are searching for. Clients want to know that they are being heard and understood, and by keeping a fluid conversation between sales and marketing, this can be accomplished. AM: Thanks Alex! For more business tips, or more information about Palantir, please visit our website at Palantir.net, or follow us on Twitter at @palantir. Have a great day everyone!