On the Air With Palantir

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.

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.

TRANSCRIPT Allison Manley: Hi and welcome to the Secret Sauce, a short podcast by Palantir.net. I’m Allison Manley, the sales and marketing manager here, and today we’re giving you something a little bit different and special. It is the end of 2016, soon to be 2017. We are moving our offices, relocating across the border a little bit to Evanston, Illinois. So we wanted to write a little poem for everybody based off of “‘Twas The Night Before Christmas” to sum up how we felt about 2016 and where we’re going next year. So it’s time to cue the sleigh bells. And here we go:   T’was the night before moving. The office was busy. Boxes and bubble wrap all in a tizzy!   We have to pack up, and keep at a fast pace! Palantir’s moving to a new space.   A new year is always a chance to reset. So we can create our most thoughtful work yet.   This year was a ride, with a nation divided Though some would stay home and remain undecided.   The world lost some favorites.* They left quite a void. A poet. A writer. A mischievous droid.   The perkiest mom. A singer of soul.   A journalist in an award-winning role.   A boxer. A wizard. A Duke and a Prince. A candyman too . . . this year made us wince.   But “Sweet Home Chicago” could trade in those tears With Cubs being champs for the first time in years!   2016 was a ride, there’s no doubt. There were ups, there were downs, and much angst about.   Since this year has seen things get often divisive, Our mission continues to be quite decisive.   The web is a tool that can bring us together. Palantir believes this now more than ever.   In our effort to help remove every wedge, We give you our 2017 pledge:   It strengthens humanity to share and create. And knowledge is something that we celebrate.   Our clients have always been those who endeavor To make the world better, more honest, more clever.   So as we work to craft each client site, We’ll make their online space extra bright.   Our Strategists will see where each audience went, To recommend best how to manage content.   Designers will theme with a deft and skilled hand, With type and hierarchy enhancing the brand.   Front-End Developers will translate each page Perfecting the code for the following stage.   Engineers will create a solid foundation With open-source code and much dedication.   Directors and Managers, Sales and the rest Clear out the hurdles so all do their best.   It’s a process that’s seamless and quite efficient. After twenty years on, we’re very proficient!   In short: we’ll work to create more connections. This includes expanding our craft for confections!   The packing is done, and now we move North To Davis Street, Evanston, we shall go forth.   We’re sure he will find us, that Santa and sleigh To bring cheer to all beyond New Year’s Day.   A toast to this year as the curtain descends, Onwards and upwards with clients and friends.   So bring it on January! The stage is set. Happy holidays from Palantir.net!

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!

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!

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!

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.

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!

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!

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!

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!

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!

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!

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

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!

Typography is a huge and critical component of the Web. So what do you need to know about web fonts for your site? Designer Michellanne Li goes into the details. TRANSCRIPT AM: Hi again everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick piece of advice to help your business run smoother. I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from one of our designers Michellanne Li, who is going to talk about web fonts. ML: Hello, my name is Michellanne, and I am a designer here at Palantir. Today, I am going to talk to you about web fonts: what are they, and why do you need them? How do you select fonts and implement them on your website? In the early days of the internet, browsers could only render a handful of typefaces, 5 of which became commonly used. Over time, however, browsers and font files have developed so that we literally have thousands of options when we look to select a typeface for a website. But, first of all what exactly is a web font? According to CreativePro.com: “A webfont is a font file downloaded from a Web server and used by the browser to render HTML text.” The desktop fonts that you use in Word or Photoshop are specifically encoded to be rendered by a computer. Desktop fonts come in the following file types: TrueType, PostScript, and OpenType. However, web fonts are created to be read by browsers. Web fonts come in: TrueType, WOFF, EOT, and SVG. So, from a technical standpoint, you need web fonts if you are building a website because they are specifically encoded for the web. But from a design standpoint, good web fonts have features that make them particularly suited to being read on a screen. For instance, they may have wider letter spacing, heavier strokes, or taller x-heights (which are the relative heights of the lower case characters). All of these result in greater readability on a screen. Users don’t spend a lot of time on each web page, so making smart design decisions is critical in ensuring that your content reaches it audience. According to the User Experience experts at Nielson Norman Group, “the first 10 seconds of the page visit are critical for users' decision to stay or leave. The probability of leaving is very high during these first few seconds because users are extremely skeptical, having suffered countless poorly designed Web pages in the past.” Now that we know what web fonts are and why you need them, let’s talk about the financial and technical considerations behind selecting the right fonts. The following are some guidelines to keep in mind: Free fonts are great! . . . sort of. In 2010, Google launched Google fonts, making hundreds of web fonts available to the public free of charge. To do this, Google has collaborated with designers in exchange for a flat fee and the promise of exposure. Google fonts can be a great option if you are on a really tight budget. However, the following are risks to consider: Unfortunately, Google fonts are not held to any external standards, both from an aesthetic and technical standpoint. Before choosing one, it’s wise to verify if it works in all major browsers. Unlike commercial fonts, many Google fonts do not come in a range of weights or styles, such as italics. Due to the Chinese government’s censorship of Google, Google fonts do not work in China. If you have an audience in China, this is important. Websites with Google fonts not only load slowly, they may appear “broken.” Although workarounds exist, they all come down to finding a different source for fonts. Some of the latest sources are Chinese services that host Google’s fonts on their own servers. Although this probably is not illegal, I would not recommend that clients use a fonts platform that did not pay for its fonts. It is, to say the least, poor form. Free fonts, including but not limited to Google fonts, get enormous mileage both in print and on the web. When it comes to simple classic typefaces, that’s not a bad thing. They are like the little black dresses of typography. But, if you’re looking for a high impact display font to differentiate your website, selecting the same free font that everyone else has already used to the point of exhaustion will have the opposite effect.All of this being said, Google fonts has some real gems and is a solid, budget-friendly option. So, why bother shelling out money for a commercial font? You should purchase a commercial font when the following are your priorities: Quality: Commercial fonts are held to high technical and aesthetic standards. The best typeface foundries put an incredible amount of thought and detail into their work and can answer questions about browser compatibility, usage scenarios, and the history behind each typeface. Brand consistency: If you have an existing brand that includes typefaces for print materials, it’s worth it to purchase the corresponding web fonts. In the event that you are just starting to establish your brand, now is a good time to ask if the typefaces you like have print and web equivalents and to determine how well these potential typefaces work in both kinds of media. When purchasing a commercial font, it is important to read the licensing agreement. Font designers and retailers place constraints on the scope of a font’s usage in order to protect the value of their product. So, at this point, you’ve picked your fonts, and you’re ready to start using them on your website. How does that work? One option is to use a hosting service for your fonts, which means that your font files will reside on the server of the company from which you obtained them, and your website will load those files. For commercial fonts, hosting is a subscription-based service. The advantages of this are: Implementing the fonts on your website is as easy as adding a single line of code. Web fonts get updated as the internet changes and grows. With a hosting service, your provider can push the latest versions of the font files to the cloud server, and they will be automatically loaded onto your website. You don’t need to keep track of the font files. Hosting services offer some great bargains. For instance, Typekit is a hosting service that is bundled into the Adobe Creative Cloud package. For no additional cost, this includes unlimited web font usage for up to 500,000 page views. All of that being said, Typekit isn’t really a bargain if you don’t need Adobe Creative Cloud to begin with.Self-hosting is another option. Self-hosting means that the font files exist on your server. The main advantage of self-hosting is the ability to subset fonts. This means editing the files to remove unneeded characters. Subsetting results in smaller files sizes, speeding up the load time of your website. In summation, web fonts are an important component in creating a website because they are specifically designed and encoded for the web. In selecting fonts, both financial and technical considerations should be taken into account. Once you’ve determined your fonts, you can choose to use a hosting service or to self-host. Even when we’re not conscious of it, typography is a huge part of the web. I hope this talk will contribute to making the web a more beautiful and user-friendly place! AM: Thanks for listening to this week’s Secret Sauce! For more great knowledge, visit our website at palantir.net, or follow us on twitter at @palantir. Have a great day!

It’s hard to know which type of image will best help you optimize your site’s performance. Front-end Developer Patrick Weston breaks down four different image types and assesses the function and benefits of each kind. TRANSCRIPT Allison Manley [AM]: Hi and welcome back to this week’s Secret Sauce, a short podcast by Palantir.net that offers a quick tip on some small thing you can do to help your business run a little bit better. I’m Allison Manley, an Account Manager, and today’s advice comes from front-end developer Patrick Weston, who has some thoughts about dealing with images on the web. Patrick Weston [PW]: Hi, I’m Patrick, and I’m going to be talking about images on the web. The web is really progressing forward and evolving, and as developers we tend to take data and speed for granted. We normally work at businesses and offices with really fast broadband connections, but that might not always be the case for all users. Responsive web design has really focused on mobile first, and a lot of times these mobile users are data capped or have their data limited. And they can also be in remote locations on slow connections. Images are often the largest asset on web pages. So if you make improvements with images, you can really make large improvements with your site speed and performance. I’m going to talk about different types of images, when to use which, and some general tips for improving your site with regard to images. First, I’m going to cover two different types of categories. There are: Lossless vs. lossy compression Lossless as the name implies, is no loss of data. So these are images where the source feed is the exact same as the outcome. But lossy compression allows you to lose some quality at the sake of file size. There are also vector graphics vs. raster graphics Vector graphics are defined mathematically. For example, a line starts here, and ends here 10 pixels over. But Raster is defined pixel by pixel, so you can think of it as kind of a 2D grid with different colors at each pixel.So now I’m going to talk about the different types of images that there are. There are four main types: PNGs JPEGs Gifs and SVGsI’m going to go through each one and kind of talk about their strengths and weaknesses, and then I’ll recap about when to use each type. PNGs are the first type I’m going to talk about. They are a lossless file format, so you don’t lose any quality. And they are also raster, so they are defined pixel by pixel. But the benefit with PNGs is that they have what’s called an alpha channel, so this allows for transparency. If you’re using transparency on the web, it’s likely a PNG. And this alpha channel is a scale of transparency, so it can have different values of how transparent the image actually is. The next are JPEGs. These are kind of the workhorse. This is one of the most common file formats, and it’s a lossy file format, so you can have some loss of quality, but also save image size at the same time. They are raster, so they have a 2D grid of pixels, and they don’t have an alpha channel, so there’s no transparency. The next type are GIFs. They are also lossless and raster. They do support transparency, but it’s  kind of an on/off switch, so the pixel is either transparent, or not transparent. So you do lose some quality here with the transparency. But the main thing that makes them famous on the web is that they support animation. So if you’re looking for kind of a simple animation, GIFs are a good way to go. Last you have kind of a newer file format that’s beginning to be more popular on the web , and that’s SVGs. They are vector graphics, so they are defined mathematically. You have shapes and sizes, different line widths, thicknesses, colors . . . they’re really versatile. These four file formats are kind of confusing, and there are different approaches to when you want to use each of them. So the real key is to kind of figure out what image is best for you. If you need any sort of animation, GIF is the only option. It’s the only one that provides animation without using a video format. If you need any sort of transparency, PNG is probably your best bet because it gives you that alpha channel for transparency that is a nice scale rather than just an on/off like GIF provides. But if you have an image that’s a photo or a scene, a JPEG is probably your best choice. And JPEGs are probably your best choice just by default (unless you don’t want to lose image quality, in which case a PNG is also a great choice). The great thing about JPEGs is that you can set the quality. If you have something that needs to scale well . . . a logo, or something with simple shapes and colors . . . then go with an SVG, because they can have really small file sizes. Other alternatives that you can use include CSS. A lot of times you can do gradients or background images, and you can avoid images all together. Or if you have a logo you can use text or a web font. And there are also some great approaches that are starting to come out, and become more popular, for responsive images. One is called  “Srcset.” It allows you to define different images depending on the width of your browser. There’s also the picture element. And Drupal also has a great responsive image module that’s new in Drupal 8. You set up different images sizes and styles, and then tell Drupal when to apply each. But all of these really depend on having a really good source image to begin with. You can do all sorts of responsive tricks and things. But if your source image isn’t the right type and isn’t optimized, it’s not going to be a good result. There are lots of types of images out there. But with a little thought, and with the help of some new best practices and automation (like Drupal’s new responsive image module), you can create a great, fast-loading site for all users regardless of screen size or internet speed. AM: Thank you Patrick. That’s it for this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great one. Helpful links Image types and when to use them: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization?hl=en Configuring Drupal's new responsive image module: https://www.advomatic.com/blog/adding-responsive-images-to-your-drupal-8-site

Writing a Request for Proposal (or RFP, for short) is no easy task. You want it to be as detailed as possible, as to ensure you get the right kind of proposal from the right kind of vendor, but general enough since you're not entirely sure what you need – and the expertise of the vendor will help articulate some of that, ironically. So how can you write a better RFP given these circumstances? Our Account Manager Allison Manley has seen hundreds of RFPs come through the door, and shares some thoughts on how to streamline your process and ask the right kinds of questions to get what you need, and make it easier for vendors you actually want to submit a proposal. TRANSCRIPT Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by Palantir.net. This is a short podcast, just a couple minutes, that offers a quick tip on some small thing you can do to help your business run better.  I’m Allison Manley, an account manager here at Palantir, and I’m the one offering today’s advice, which is about how to craft an RFP (which stands for Request for Proposal) in order to attract really good responses from firms like Palantir.  RFPs are hard to craft, no doubt. You have to be concise, you likely have to insert a ton of legal jargon, but you want to create an appealing proposal that will attract the right firm for the job. Over the years we have looked at a lot of RFPs, and have seen the good, the bad and the ugly. We thought it would be helpful to share our experience from the responder's side. I’m going to outline the main five things you should consider. There are many more things to consider, and actually I outlined 15 of them in a blog post from March 2016 that is up at Palantir.net. But here are the key five things I think you need to know.  1. Be specific about your desired outcomes and goals When outlining your goals, get as specific as possible. Even if you need just a general upgrade because your site is outdated in both the look and the technology, there must be a reason you’re frustrated with the old site: is it now too slow for back-end users to update? Does it need to be mobile-friendly? Do you want to increase traffic for a specific reason or conversion? Why do you want those things? What will they do for you that your current site can’t? Try to also avoid generalities such as: "We want a website that incorporates social media,“ or “We want more traffic,” and “The site needs to convey our message and mission.” Because guess what: everyone wants those things, and they don’t give us enough information. When outlining projects, make sure to tie outcomes back to specific goals. 2. Give us a budget From a bidder’s perspective, there’s probably nothing more frustrating than asking for a budget, only to be told “we don’t know. We’re trying to figure out how much this should cost.” Let’s face it: there’s a number in your head. I know this because once I hear the basic parameters of the project, I’m going to respond with a range. And based on your reaction, I can get a sense of budget. I’ve had a lot of potential clients describe their needs, to which I’ll respond, “a similar project we did cost in the low six figures.” This is usually followed by a client saying, “oh, that’s fine” or “we don’t have more than mid-five figures to spend.” See, you did have a number in mind! Even if it was your maximum cap. Don’t ask for all the bells and whistles of a Porche-sized project if you know you only have the budget for a small Kia, or some similar car. Giving a budget upfront allows each firm bidding to tell you what they can offer you for your money. Then you can compare expertise and the value offered for your budget, which gains for you a more complete picture of what you're buying. 3. Be specific about constraints and exclusions Are there certain key dates by which you would need your project completed? Are there brand and identity standards that we have to adhere to? What about third-party integrations that need to be considered? Giving us parameters helps us focus on what we can deliver for you. Exclusions help define a project as well. What items will the bidders not be responsible for? Will someone else be in charge of photography and/or content creation? What about hosting and migration? Letting us know what not to bid on will ensure we don’t account for it as an unknown in our estimate. 4. Realize you are buying the process, not just the end product Palantir didn't always work for healthcare clients. It took the trust and vision of our first healthcare client to give us the project to prove that we could. Consider responsive design: prior to 2011, nobody had ever heard of responsive design, let alone build anything for all devices, it just wasn’t done. But the smart firms all made a smooth transition to responsive. Don't necessarily discount a firm because they've never done a project exactly like yours. Instead look for proof that they have related experience, are effective problem solvers, and have the creative and/or technical range required to complete your project successfully. Conversely, the firm that does nothing but your particular type of project is unlikely to give you a solution much different than the one they produced for your competitor last year. Make sure you are dealing with firms that can effectively translate your message to your audience and not a production house offering cookie-cutter solutions. 5. Do not ever ask for spec work Spec work is asking for work done prior to engagement with a client in anticipation of being paid. Never ask for examples of solutions as part of the RFP process. For one thing, professionals are paid for their ideas. Let’s face it: our ideas cost money. But more importantly, any quick solutions that a candidate would come up with before doing the proper in-depth research about your organization's culture and goals would simply be ill-informed and incomplete. Having strategic thinking guide your message is a much better bet than the "throw-it-at-the-wall-and-see-if-it-sticks so we can get the job" approach. Who wants to hope for a happy accident? In conclusion Writing a good RFP is not easy, I’m not gonna lie. It isn’t! It’s tough to get everything you want distilled down to a few pages (and in some cases impossible, since your organization may require many pages of legal attachments that need to be there). The bottom line: make sure you are clear about what you need and why. Give us some solid parameters from which to work. Tell us what will make the project successful for you. This helps us suggest the best solutions to fit your needs. And leave the possibility open for a conversation with the bidders so they can ask follow up questions in case you missed anything. And if you need assistance defining your project and writing your RFP, call us. We’d be happy to help show you a better way. So that’s it for this week’s Secret Sauce. For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Have a great week, everybody!

Welcome to a new 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 June 2016 and this is episode #5. In this episode Account Manager Allison Manley is joined by our client Justin McGregor from Rhodes College. Allison caught up with Justin at DrupalCon in New Orleans last month, and spoke with him about how his school has implemented Drupal, how we worked together, and how it’s been going since. We'll be back next Tuesday with another episode of the Secret Sauce and a new installment of our long-form interview podcast On the Air With Palantir next month, but for now subscribe to all of our episodes over on iTunes. 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 June 2016 and this is episode #5. I’m Allison Manley, an Account Manager, and today my guest is a client of ours named Justin McGregor from Rhodes College. I caught Justin at DrupalCon in New Orleans last month, and spoke with him about how his school has implemented Drupal and how it’s been going. I am here with Justin McGregor from Rhodes College. How are you? Justin McGregor [JM]: Doing well, doing well.  AM: We’re in the last legs of DrupalCon 2016, and we’re in the busy lobby of the conference hall in New Orleans. So there’s a little bit of noise behind us, but we will plow through. So tell me a bit about Rhodes College. JM: Who we are and what we do? We are a small liberal arts college nestled right in the middle of Memphis, Tennessee. If you look at a map of Memphis from above, there’s a big ring road that runs at the side, and if you throw a pin in the middle, that’s us [laughs]. We are 2000 students, roughly, 300-odd employees, traditional liberal arts curriculum covering everything from pre-law, pre-med, that sort of thing, all the way down to the study of the classics. We have a Greek and Roman studies department, and right across the quad we have people that are doing pediatric oncology at St. Jude Children’s Research Hospital. So it’s literally all over the map. And I get to support them all [laughs]. AM: Wow. So your college is on Drupal. How did you come to choose Drupal in the beginning?  JM: I’ve personally been an open-source advocate for a very long time. I’ve been in higher ed web work for going on 16 years now, and I’ve worked with a lot of different CMSs, none of which I could really ever evangelize for. They were really good for what they were, but, you know. At my last school I had evaluated Drupal 6 early on, but our CTO was very anti-open source. But I kind of fell in love with it then, and I’m like, one day I’m going to come back, I’m going to be in the right position at the right school to do this, Years elapsed and D7 had come to be a really mature solution, and I got the job at Rhodes. We were coming off of an aged open-text solution and also Sharepoint 2010 pointing internally. Both solutions were long in the tooth and needed to be replaced, and when I came on board, I’m like, yeah, cool, let’s do this thing, but one of my caveats was, we have to give serious consideration to open source and to Drupal specifically. And so during our CMS roadshow we looked at the two leading proprietary higher ed solutions and also to Drupal vendors for hosting and DevOps. And it became clear really early on that for our use case, Drupal was the only solution. AM: Well, great. Thank you for choosing Drupal! JM: I’m glad to be here, believe me. AM: So what does your internal team look like? What’s the composition? JM: It’s largely me. I am the only developer on staff. I work in the communications department, which actually reports to the dean of admission. So from a business perspective I work for our sales team. That being said, I do have an interactive technology manager, who is my liaison to our external services alumni and development departments. And while he’s not a Drupalist, he’s in the guts of the thing every day, doing work on the site in one capacity or another. I’m also lucky enough to have a handful of student workers, including one third-year computer science student, and while they’re contractually limited to only ten hours a week they are a massive help. And also I found out just before I left to come here that one of our vacant positions may be reclassified as a developer. If anyone’s looking for a Drupal development position in Memphis, Tennessee – just saying it’s a possibility [laughs]. AM: So you did hire Palantir, just to be transparent about things. You hired us for consulting a few times a week to support your team. What was it that you needed from us? What was it you needed to complete the project? JM: Okay, there were two projects. Let’s do them chronologically. The first one was, we’re relaunching our flagship .edu, and while I’ve been in web work for a long time, I was new to the practice of building a Drupal site. And so I knew what I wanted to accomplish, but I would go to Contrib and, here’s all the modules that are available, I could go do this by modifying a template file, or any number of things. But I needed best practices, I needed best solutions. And you can go watch training videos all day long, but they’re around the piece of technology or the specific use case that may or may not actually be the use case you’re dealing with at the time. So having somebody – the structure that I loved was, we would start the week with ‘here’s the problem of the week’. Here’s the piece of functionality that I’m going to be building. Let’s talk through all the possibilities for how this problem could be solved, and arrive at what the best practice is for this use case. And then I’d take a couple of days, get in there, work on it, build it out, and at the end of the week – nine times out of ten, it was done, but if it wasn’t, we could come back and say, here’s the specific problems I ran into, how do we work through that? The metaphor I kept using was, we ate the elephant one bite at a time [laughs]. I had six content types, a whole ton of media assets, and, ooh, I think we ended up moving about 7000 pages, a piece at a time. We took this fairly massive implementation over the course of a couple of months, and built out the framework to handle it all, and just started shovelling in the content. AM: And what was the second project? JM: So I said a minute ago that we had the open-text that was the CMS for the public-facing part of our site at the time, and also an internal SharePoint 2010 set of publishing sites. So support for that is going away, and we needed a solution, and I’m like, you know what, I’m not standing up another CMS for this, let’s just go multi-site and do it all in Drupal. But then we have the challenge of standing up branded sites in a hurry for every little department, grant, professor, whatever, that had had a SharePoint 2010 publishing site before this. And so what we worked through was, first of all, building a road-specific installation profile of Drupal, so that out of the box, all of my content types were there, all of the branding was there – there’s the branding they can change and the branding they can’t change, as a site owner. And also the mechanism for site ownership and how that’s going to work. And the second part of that was to automate a good chunk of the deployment, so I can do from the handful of things that I have to do in my DevOps environment to a functioning Drupal site. The last one I set up took me about five minutes, which is not a bad way to go. AM: I don’t know if I’ll have time to do that today, boss, it took me five whole minutes [laughs]. So what were your goals for your site? JM: To drive recruitment, more than anything. We need students. More than that, though, higher ed is generally in the position of having – as much as we say that the mantra of the site is to drive recruitment, and we say that over and over, we have parents, we have alumni, we have the colleagues of our tenured faculty, on and on. Researchers that are coming because of the disciplines we teach and the research that we do. Researchers from around the country want to come see the research that’s being done here, to be able to collaborate, all of this stuff. So ease of discoverability of whatever piece of content that’s relevant to that audience – now that we’ve been in Drupal and been in production for a year and change, we’re really starting to look seriously at personalization. It’s sort of the standard higher ed model to have the audience navigation across the top – you’re a parent, you’re an alumni, you’re a current student, yada yadda yadda. But once you’re in the guts of the site, that just starts to bleed away, you know? And so being able to contextualize information based on what we know about the person coming in is steadily going to become more and more important to us. Part of that to be handled through Drupal and part of that through CRM integrations, with both Salesforce and an admissions-specific product called Slate.  AM: So personalization is next down the road. Excellent. So what was your working relationship with Palantir? What did it look like on a day-to-day, week-to-week basis? JM: So both of the consulting setups were more or less the same. We identified an hour early in the week where we could, you know, bang around what this week’s problem was, and then an hour later in the week, how did it go, staging for next week’s problems, or if something didn’t get done because I had a roadblock or whatever. Both of the guys I worked with were fantastic. Even if we weren’t on a call I could send them an email any time I wanted to, and hear back pretty darn quickly. But a lot of times I would save stuff for the call because it’s just something you need to talk through, or screen share or something. It was nice to have somebody who’s done a lot of Drupal deployments, at the front of the week, to say ‘this is what, given your current level of expertise, you can reasonably expect to get done this week without just absolutely killing yourself’. And to do that knowledge transfer early in the week that says, okay, here’s what you’re going to need to know, if you’re not hip to this, go read this, go watch these YouTube videos, whatever. Then set to the task and we’ll wrap up on the back end. Having somebody who was really expert in these sorts of Drupal deployments helping set your agenda, because I know my goals, I know my organization, but I need to know what is really realistic to do in the product in a given span of time, you know? AM: All right, so let’s start with the bad stuff, the obstacles. What roadblocks did you run into during the course of the project, and how were we able to help you remove those roadblocks? JM: I’m not new to development, I’ve been doing web work for a while, but there are sort of Drupal-specific things that, when you read through the documentation, or at least when I read through the documentation, like the hook system – they seem to work fine in the documentation, but then when you get into the guts of the system, you think, that doesn’t seem like what I just read, or doesn’t behave in the expected way. I had done a lot of front-end development prior to coming to Rhodes, and the Drupal templating system is something wholly different from anything I’d encountered before. I knew how I needed the site to behave, I knew what I needed it to look like, I knew how I needed it to respond, and all of that, but figuring out, do I do this from stacking a bunch of modules in order to handle fences, for example, which I ended up relying on a lot, to sort of get the markup back down to something reasonable and something I can work with and go from there. Or do I just dive off into the PHP and let’s make template files for everything, and that way I’m programmatically controlling markup. We had to come up with a strategy pretty early on and say, okay, for the sake of anybody who ever has to follow in my footsteps, let’s find a solution we like, and move forward with, that’s how we’re going to work. AM: So what was the biggest win over the duration of the project? I don’t know if you have one win per project, or… JM: So many. Seriously, I say that about the theming as a roadblock, but overall, both of these projects from an institutional perspective have been a resounding success. For academics not to complain about something is actually fairly rare [laughs]. That’s not to say that there weren’t people who take exception to, say, font choices, or, is that really the institutional red, it needs to be a little richer – you know, that sort of nitpicky ‘I don’t like this element of the design so I don’t like all of the design’. Overall, oh gosh, as of last week I think we’re 16 sites in, that we’ve launched so far. And yeah, all the designers have been very very happy with the end product, with the authoring experience. I’ve had some requests for new features and I like that my users are passionate enough to say, hey, this is great but here’s how we could make it even better, and to work through these things with me. I’ve got a handful of new content types that people have suggested – as I’ve been rolling out these little multi-site instances, I think that every last one of them could be used across the enterprise. And it’s great to have people that are willing to work with me on this sort of stuff, to come up with these ideas – not just for them. Probably one of the nicer things about being in a small liberal arts college is that they are mindful of the impact any change can have all the way across the organization, because they eat lunch with these people every day, you know? [laughs] So they’ve all been really successful. AM: Fantastic. So the next step you’ve mentioned for yourself, because you don’t really have a team [laughs], moving forward is the personalization piece. Anything else? JM: Well, part of the reason we selected Drupal to begin with was that it allowed us the flexibility to not deploy a site and then sort of be stuck with it forever. I mean, unlike some of the proprietaries, you get the tools that come out of the box and that’s kind of the end of it. You take one of their templates, you skin it your way, and you’re done. We’re looking at some design improvements. We did a complete redesign, this wasn’t just a move of an old design, we started from scratch and rebuilt. So there were design elements that have really worked well for us, and some things that, to use the industry jargon, aren’t converting the way we’d like them to. We’re not getting the traffic draw for some of the elements that the real estate they’re on deserves. So we’re going to take some time with the design team this summer and look at redesigning certain elements, and – I love that my templating architecture is flexible enough that there’s going to be no problem to just drop in there and, it’s all the same entities, it’s all the same data, we’re just presenting it differently. It looks like it’s going to be a fairly painless process. Also, since we’re at DrupalCon, I’m going to mention this. I’ve been at several sessions about paragraphs over the course of the last couple of days, and when I was at DrupalCon LA I went to a session and I was like, hmm, neat idea, maybe when it matures a little bit more – well, apparently it has matured a lot over the course of the last year. Because some of the things I’ve seen people do with paragraphs here are really impressive. So I’m sort of starting to daydream about some of the tools that I may be able to give my content creators, to do a lot more complicated and a lot more interesting things than they are now. There are certain things, the demand of the site and the demand of the brand, that will require us to leave some things static, but I want to give them as much creativity and as much flexibility as I can, to really make their content sing.  AM: Are you going to be able to add to your staff? JM: We’re trying to get a position for another developer, which hopefully will allow me to pull out and do a little more high-level stuff. We’ve also been steadily training more and more of our communications staff to work directly in the CMS and not rely on me or Nick or the student workers to do the layouts and content for them. And again, so far that’s gone really well. Like I said, the reason that I liked what I was seeing of paragraphs and a few of the other sessions is that, as much as I’m worried about user experience for our audience, I’m also worried about user experience for my content creators. I want them to want to work in the CMS, you know? And anything I can do to improve that situation for them – out of the box Drupal’s a great CMS to work with, but there are always ways to make it better. I’m always on the lookout for tools to help make their work better. AM: Isn’t that the thing about the Web, though – you can always make it better. Tomorrow’s another day [laughs]. JM: Exactly. AM: Well, thank you, Justin. I appreciate you taking the time, I know you’re fried – we’re all fried on the last day of DrupalCon – and there’s been a lot of knowledge and alcohol shared [laughs]. So I know everyone’s ready to relax a bit. JM: Next stop for me is the streetcar, I’m going to go to the other end of the French Market and start tchotchke shopping for the kids and hit three or four bars on the way back to the hotel, that sort of thing [laughs]. AM: Well, hopefully you’ll join us tonight at trivia night, and then at sprints tomorrow. JM: Don’t know, I have family here in town so I have some obligations there. But I’d like to put in a hour or so at the sprints and see how it goes.  AM: Well, thank you so much. I appreciate the time. JM: Thank you! AM: Thank you so much for listening. If you want to hear more episodes of On the Air with Palantir, make sure to subscribe on our website at palantir.net. There you can also read our blog and see our work! Each of these episodes is also available on iTunes. And of course you can also follow us on twitter at @palantir. Thanks for listening!

Account Manager Allison Manley is joined by Senior Engineer and Team Lead Bec White who has some thoughts regarding deployment, and why it's so important to do so early and often not only for your internal process but also to help bring a site to life for your clients. TRANSCRIPT Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by Palantir.net. This is our short podcast with 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 to us from Bec White, Senior Engineer and Team Lead, who has some thoughts regarding deployment. Bec White [BW]: My name is Bec White, and I want to talk about deploying early and often On a project, I feel It's important to get deployments running as early as possible. There are a bunch of reasons for this, but my two favorites are not solving problems at the last minute, and bringing the site to life for clients. I mean, number one, I'm not a firefighter. I don't want to solve problems under pressure, I want to solve problems beforehand and then have my team look like wizards later. There's this idea that with Drupal that you don't have to know the target environment, that you just make a drupal site and then you can put it anywhere. But in practice, though, there's always something about the environment that always affects the build: whether it’s the php versions, whether it’s setting up http redirects (on apache vs nginx), whether it’s your single sign on integration, search servers, varnish config, just to name a few. And for the Drupal-specific hosts, there are other things, like how the settings.php file is managed, and where the Drupal root lives in the repository. So always when you run a project on a new environment, there is *something*. You can make as big a launch checklist as you want, but we all know how painful it is to find out these things when you're rolling up on a deadline. But at the beginning of a project, the deadlines are just thin wisps on the horizon. And under a blue sky, it's not so catastrophic, so stressful when drupal barfs errors all over the destination environment where the client can see them. Ok, so at the beginning of a project, maybe we have a "sprint zero" and we get a repository set up, and Drupal is installed, and hey — we put it on the staging environment. Then there's a plain Drupal up there: it has a druplicon and has the bartik theme. And you definitely . . . the project isn’t ending there. Just looking at it, we know that we're going to have to deploy again… and again, and again.  As an engineer, I love systems, and I love repeatable workflows. So at this point if I can put together a workflow that my whole team can use, that my junior developers can use to deploy when I’m out on vacation, something that’s going to be robust across the lifespan of the project — that's going to be really gratifying. And the goal is to make things less error-prone — to run everybody's code through the same tests, to manage the dependencies consistently so they are present on all environments, even to prevent development code from being deployed to production environments. Once we've ironed out the wrinkles in the sprint zero deployment, we can evolve the deployment script as the project continues and there are additional requirements that get added to the build. This is pretty powerful because at this point we have a repeatable deployment. Everything that goes up into this environment, any content and configuration, that anybody does on that staging environment, that little sprint 0 deployment, anything will get wiped away. You can't break anything as a user on this little sprint 0 site. And when you deploy the sprint 1 work, you're bringing the site to life. Clients can go in and take a poke at their new site, and you know what? The sooner we'll get the feedback that is so crucial to aligning our work with our clients' needs, the better. This is why we do agile! This is the part where I get really excited. What’s better than having someone look at your work and say, "oh boy, this is going to be great for us." Or even better, "This field isn't working the way I expected" or "this page has a bug". That sounds like negative feedback, but really the sooner we get that information, the better. Getting that stuff right is foundational for the work we do. Whether we need to explain what we were thinking, fix some code, or reorganize a user interface, it's always easier to incorporate these kinds of fixes earlier in a project. And the only way we’re going to get that kind of feedback is if it’s real to them: if they see it, they can use it, they can interact with it. And production is where it’s going to be real.  I especially love it when a client, someone who is playing the "product owner" role on a project, says, "ooh, let me show this to my marketing director/content author/intern". What this shows me is someone who is invested in the work my team is doing. Someone who recognizes that this project is going to affect the way their organization works. And as an engineer, the only thing better than systems and repeatable workflows is someone who is invested in my work. So, deploying early and often not only lets us avoid doing high-pressure, last minute, environment-related bug fixing, but it also fosters that feedback cycle that lets us respond to clients.  AM: Thank you, Bec. For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Have a wonderful day!

Running a 30-person team is no small feat, and is absolutely a group effort to ensure everyone is happy and healthy. Sometimes those helping hands come in the form of a service rather than a person however. Our Director of Operations Colleen Carroll talks about one such tool, and the positive impact it's had on our company and culture, in this week's Secret Sauce podcast. TRANSCRIPT Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by Palantir.net. This is our short podcast, up to 10 minutes, that offers 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 to us from Colleen Carroll, our who is going to talk about a tool we use in human resources called Bamboo HR. Colleen Carroll [CC]: Hi, I’m Colleen Carroll, the Director of Operations here at Palantir, and today I’m going to talk about Bamboo HR. It’s important to me, as the Director of Operations, to develop a culture within the team where the team is informed, where they feel independent, and they feel empowered. And one of the areas that I think is overlooked quite often in companies is the employee resources side of things. And quite honestly the term is “people operations” or “employee engagement “ . . . there’s a lot of terms for it . . . but all the resources and things that relate to being an employee of a company. In my past, I’ve experienced first-hand what it is to be an employee and be in the dark. The things that often times you’re in the dark about are, “what was that 401k percentage that I had put on my check that doesn’t show up on my check stub?” and, “what are all the things that I can elect to take advantage of, the benefits that the company offers me,” “what does the company think my PTO [paid time off] balance is?” It’s little things, but it’s things that when you’re in the dark about them you start to worry, or anticipate, that something might be wrong, and you don’t know who to talk to about it. And again, having working for a large institution in the past, it wasn’t clear what those services and resources were, and you didn’t know who to talk to, and yet it could be easily answered in a five minute question. So at Palantir I made it my job to be that resource. And it was easy to do for a very long time because we were a small team. And I felt it was important that people could reach out to me and say, “hey, what benefits are available to me, and why is this a good benefit?” But as the company grew, it got harder to be that centralized resource. I didn’t always have the answer right away, which I always liked to do. But more importantly it became a situation where it was inefficient. The amount of time that was needed on my side, as well as the employee side, to understand the benefits before we could even get to a point of asking specific questions . . . and through my little bit of research I realized that there were tools out there that do this. They often call them HRIS systems. APD is a payroll-related system that also does some of this. But all of them felt too big, too large, and didn’t really meet the culture of Palantir.  And one day I came across Bamboo HR. And it’s mission statement, or it’s promise I should say, was that, ‘if you’re in people operations and you have a bazillion spreadsheets out there, then Bamboo HR is the right thing for you.’ And that caught my attention right away, because I had at least 20 spreadsheets to help me manage all the things that related to the employees here at Palantir.  But then there was the big gotcha, and it was, “do you need help managing PTO balances and communicating that to your team?” So I looked into it and, sure enough, that was exactly what Bamboo was able to offer us. And that was the hook! I took on Bamboo to help us manage paid time off (PTO) and to be able to put that information in the hands of our staff so that they didn’t have to come to me. So that in real time, when they were ready, when they had a question, they could find that information themselves.  And what happened after we got Bamboo installed and set up, was that it had a lot more things to offer, a lot of really great things. Stuff that was even more cryptic to find, I think, in a lot of institutions. For instance, what has your salary history been the entire time you’ve been at the company? Or how much am I contributing to these different benefits for my salary, and what does the company contribute? Some other services that Bamboo was able to offer us was a phone directory. The phone directory created an opportunity for individual employees to update their personal information on their own. So it wasn’t on me to make sure that I always had the most current home address, emergency contact, personal phone number for everybody.  Then when it comes to much more secure information, personally identifiable information like social security and birthdate, I never had a really secure way to do that except for the payroll system. But I don’t really want to be logging into the payroll system to figure out when people’s birthday are so I can send them a birthday card! Well Bamboo lets me do all these things in a really easy way, and I can’t tell you how much easier it’s made my job, and I think how much happier it’s made the team here at Palantir, because they can now come to me and say, “hey I’ve been looking over this benefit package,” or, “I’ve been looking over this information and have a couple of questions for you.“ So our conversations are much more informed, they’re much more efficient . . . I’m not wasting their time, and they’re not eating up too much of my time either, and we can get to the specifics and I can be a better resource to them.  But probably one of my more favorite items — well, I should say there are two new favorite items in Bamboo that I take advantage of — one of them is the Job Board. It’s an applicant tracking system for handling people who apply for jobs at Palantir. No longer do I have to go to Palantir.net and log into the system and maintain different job postings. I have a whole dashboard within Bamboo that tracks people who’ve applied for the position, how long I leave it open. It broadcasts it out to different resources out there, whether it be LinkedIn or other things. It allows me to see how we’re faring, how many people have actually looked at the job posting, and how many of them are actually transitioning or converting into applicants, which is awesome. Then I can roll that applicant once we’ve hired them right into the system.  So administratively — at least ten less spreadsheets! Which is pretty great.  But then the real exciting feature that comes with Bamboo has to do with reporting. This is again where a lot of the spreadsheets come in. For tax reasons, for census-related reasons, for different benefit packages . . . there are a lot of forms you have to report back about how many employees do you have, and where do they physically live, and in our case we have people in different states. So what states do we have employes in? How many people are taking advantage of your benefit systems?  And so as we move towards becoming a more diverse company, it’s important that I have patterns and statistics — historical patterns and statistics to look at — to see how are we faring. What did our metrics look like on applicants who applied and came into Palantir and where can we do better? Where can we knock down some of those unbiased . . . sorry, unconscious biases . . . so we can help drive diversity at Palantir? And Bamboo helps me do that quite easily.  In summary, Bamboo has pretty much saved my life, made me be a better Director of Operations, have a better grasp around all of the things that involve being an employee at Palantir, to help the staff become more informed, and it fits very much to our culture here. And being a distributed company, and one that focuses on being a remote-first culture, I can put this information at the fingertips of the team. And then they can reach out to me and ask more specific questions so that I can have a more thoughtful and informed conversation from my side.  AM: Thank you, Colleen. As an employee of Palantir using Bamboo, I have to say it’s pretty great, so kudos to Colleen for the implementation and choice there. For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Have a wonderful day!

Welcome to the Secret Sauce, our short podcast that is typically around 10 minutes long and offers a quick tip on some small thing you can do to help your business run better. Account Manager Allison Manley is joined by our peer Jason Pamental, the Director of Design and Technical Strategy at Isovera in Massachusetts. Jason shares his thoughts about typography on the web, and how he got into it in the first place. TRANSCRIPT Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by Palantir.net. This is our short podcast, up to 10 minutes, that offers a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an account manager here at Palantir, and today’s advice comes to us from Jason Pamental, the Director of Design and Technical Strategy at Isovera in Massachusetts. I caught up with Jason at DrupalCon, and he wanted to share with you his thoughts on typography on the web.  Jason Pamental [JP]: Hi, I’m Jason Pamental, I work at Isovera, a Drupal shop right outside Boston, Massachusetts, and I’m here to talk about web typography, and kind of how I got into it. Which, interestingly enough to me . . . I think about it when I’m here . . . I actually got into it because of people I talked to at DrupalCon. I started writing about web fonts when TypeKit came out in 2009. Studying graphic design many years ago, I always loved type, but couldn’t ever really do that much with it online. When TypeKit launched, I had already started using Drupal, and I was using TypeKit, and there were no modules. I found somebody had started one and I just got involved in that: I became the co-maintainer. And that was one of my first forays into using, actually getting into the contrib space.  But then it opened up into talking with a bunch of core developers at DrupalCon in Chicago. It was Al Stephan and Matt Tucker, and a couple other people, in a bar of course, at two in the morning. And I figured if I could convince them that web fonts were actually worth implementing, then I should really do something with that. Since then I’ve spoken about at DrupalCons on three different continents, and written a book about it, and absolutely love the way the sort-of art and science of using fonts fits with that same way that Drupal can kind of tie into how an organization works, and how you create websites, and that same sense of . . . that blend of strategy, and design, and technology all kind of in this one big platform. It’s been perfect. I spend a lot of time thinking about how to implement it, and teaching people how to do it and use web fonts and now I get to kind of spread that around with the rest of the technical team at Isovera too, which has been a lot of fun.  One of the things that actually struck me in how to use web fonts well was actually . . . one of the guys from Vox Media was talking about it in a session yesterday . . . he was talking about image performance, and font performance, and ads. One of the things he started talking about with font performance was something that I had actually written about a while ago: it was a way to balance that flash of unstyled text or unseen text when things are loading.  And that actually ties into a great way that Drupal 8 allows you to control the loading of Javascript. So it really comes down to when you’re loading the web fonts, the first thing that happens is the browser sees the listing for the web font in the CSS, and it has to think about whether or not that web font has loaded. Most of the time it hasn’t yet, so the browser default behavior is to not show anything. That’s actually how all the browsers behave now. The problem is that when you have all these other things going on in the loading process of a page from Drupal, if you’re also then waiting for a web font to load, you’re creating a pretty big delay, and it could be a significant delay in actually seeing any content show up on the page.  So the trick is to actually use something called the Web Font Loader, or something like it that will inject a class into the page. You set the font loading to be asynchronous using Javascript, and that’s something you can easily do now in Drupal 8 to control where the font, the script is executing. And in doing so, you get the unstyled text on the page right away by tapping the CSS into this web font loading class. Then you can style that fallback: you can set the line height, the font size, the letter spacing, all through CSS that is sort of scoped to the presence of that WF inactive class in the loading pattern.  And this is something that the guy from Vox was talking about using on The Verge, on the Vox Media site itself . . . it’s a loading technique that is the easiest thing in the world to set up. I actually have it built into a couple of frameworks and a theme that I maintain on Drupal.org called Beep Edition that will give you some pretty simple hooks to try this stuff out for yourself.  So that loading process  . . . getting the text on the screen right away . . . is another one of those ways to achieve better perceived performance and minimize the difference for people when they are loading stuff.  So if you’re interested in checking that stuff out, if you look at the theme that I have up for D7 and D8 on Drupal.org, Beep Edition, it has a lot of that stuff built in.  AM: Thank you, Jason, and so nice to meet you at DrupalCon New Orleans! For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Have a wonderful day!    

Account Manager and Podcaster extraordinaire chatted with dozens of folks at DrupalCon in New Orleans last week to get a sense of what made the show special for them. This week's Secret Sauce is a collection of those highlights. Some shared specifics on something they learned at a session they attended, otherwise talked about the community or trends in the Drupal marketplace, and much more. With DrupalCon last week, we missed our long-form, but stay tuned for that and more short-form podcasts in the weeks to come. And as always, thanks for listening! TRANSCRIPT Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by Palantir.net. This is our short weekly podcast where we offer a quick tip on some small thing you can do to help your business run better.  But . . . today we’re going to switch up a little bit. Last week, a number of us from Palantir and a larger number of all of us from the Drupal community were in New Orleans last week for DrupalCon 2016. So we decided to go around the room and ask everyone that they thought the best takeaway or the best thing from DrupalCon 2016 was for them. So this is a compilation of all the people I ran into randomly and got them to tell me what they thought was the best thing about DrupalCon 2016 Allison Manley [AM]: Alright, Justin McGregor of Rhodes College . . . what is your favorite thing about this year’s DrupalCon? Justin McGregor: Oh my goodness. I was actually just in a wonderful session on personalization, about an hour ago. Personalization in Drupal, and specifically they covered a lot of modules in Drupal 7. And that’s been a goal for us early on was to work some content personalization into the site. But the great thing about a Con like this as opposed to some of the other conferences I’ve been to is just how approachable the speakers are after the fact. People go up, grab somebody as they’re coming off stage, or see them at the booth later, and really talk through the implications of some of what I’m working on . . . because everybody’s use case is different, right? And so to be able to talk through with somebody a problem like that based on a presentation you’ve just heard . . . it’s a fantastic thing to be able to do, and not all conferences allow you to do that.  Dave: My name’s Dave from Glendale Community College in Arizona. And my favorite thing about DrupalCon so far is I like interacting with all the vendors, and getting to meet all the cool people, and see all the neat things that they offer. David: I’m David from Pantheon. My favorite thing about DrupalCon this year was all the amazing people, and the amazing parties The Pantheon party was amazing. I’m saying amazing a lot, and I’m aware of that. But that’s amazing too.  Shelley Hutchins: My name is Shelley Hutchins from MediaCurrent. My favorite thing about DrupalCon is just being on the exhibition floor and getting to talk to so many members of the Drupal community. Chaz Chumley: Chaz Chumley, Technical Architect for ForumOne, author for Packt Publishing “Drupal 8 Theming with Twig” book. My favorite thing is this gentleman right here, who is one of the most awesome pre-keynote putter-together singers, dancers, and who looks really sexy in lamé and tights and whatever else he decides to put on for the keynote.  Campbell Vertesi: I don’t know whether to be flattered or feel awkward about that [laughs]. But I’ll be in the bar later.  My name is Campbell Vertesi “ohthehugemanatee,” and every DrupalCon I get to get up and sing, and dance and wear gold lamé. So that one’s not special about this DrupalCon, I think my favorite thing about this DrupalCon is how much more visible the Indian community is. Because the Indian Drupal community are “jump in with both feet” kind of people . . . if there’s a party, if there is a dance, if there is something to code, if there is a totally new API . . . every single one of them that I’ve met will just leap in with both feet and try it out. And it is so much fun.  Stephen Lucero: My name is Stephen Lucero, Solutions Architect with Media Current. “Slucero” is my tag. My favorite part has been getting to meet up with the community, meeting up with people that I didn’t realize I needed to reconnect with. So it’s been great to be able to do so, and then be able to meet up with them and go and see a giant float burn with a flamethrower. That was pretty awesome.  Adam Erickson: Adam Erickson with August Ash. I’m a Lead Developer. Favorite thing about DrupalCon would be the community, and how everybody gets together. It’s extremely impressive and motivating. That’s the thing I love about it most.  Shawn Haukaas: My name’s Shawn Haukaas, I’m President of August Ash. We do Drupal development in Minneapolis. And I’m always impressed by the passion of the people that come. So wheher you’re a site builder, a developer, a designer, or a project manager, or an owner . . . at any level there’s passion for Drupal, which is something that’s pretty impressive. I work in a lot of different platforms and things within the business community around, and it’s very rare to see what we see in Drupal. Kevin: Hi, I’m Kevin. I’m from Dallas, Texas. I work for a company called [audio issue] as a web developer. The best thing about DrupalCon is getting to interact with other guys and other developers, and learning about what’s new in Drupal 8. It’s been a good experience so far.  Sunny: Hi my name is Sunny Shah, I’m from Dallas too. I’m the president of a company called Voltage Net, we are a start-up. I’ve been coming here since . . . this is my third time at DrupalCon. It’s just great to meet all the people working on Drupal, learn about what’s happening in Drupal 8 and what’s coming next, and just to communicate and collaborate with everyone. I think that’s the main reason. Erik Paxton: I’m Erik Paxton. I’m with ThinkShout, and my favorite thing about DrupalCon so far has been the front-end sessions so far, I think. It’s nice to see the direction of the decoupled Drupal, and where that’s going. Mike Shaver: My name is Mike Shaver. I work for ThinkShout as well. I think my favorite thing has been connecting with other developers and other folks in the Drupal community that I’ve been in contact with over the years. Edward Pritchard: My name is Edward Pritchard. I’m with the Maricopa Corporate College. And the best thing I like about DrupalCon is being able to run the front-end track and learn all about front-end design, which I’m gearing towards. Scott Worthington: Hi my name is Scott Worthington. I work at Estrella Mountain Community College in Phoenix, and my favorite thing about DrupalCon is catching up with all my fellow Drupalistas.  Valery Chen: Hi my name is Valery, and my favorite thing about DrupalCon is learning all the new skills out there, and meeting people. Kristoff Van Tomme: This is Kristoff Van Tomme from Pronovix. And this DrupalCon was really different because of the city. New Orleans is simply really amazing. The food is very different from usual US fare. Yeah. It’s interesting. Good con. Joe Purcell: I’m Joe Purcell. I work at Digital Bridge in Chicago. And my favorite thing about DrupalCon 2016 is seeing lots of familiar faces, and there are lots of exciting things happening in Drupal 8.  Dwayne McDaniel: My name is Dwayne McDaniel. I am with Pantheon. My favorite thing about DrupalCon New Orleans 2016 It think is just the positive energy about this show. This is my fourth DrupalCon, and the DriesNote kicked things off in such a wonderful light, and every conversation i have is filled with this excitement about what we’re going to do next, not “when will it happen.” That positivity has flowed through everything: through all the parties, the dinners, all the conversations, the sessions I’ve attended. If I’d say there’s one word that sums this thing up it’s positivity, and it’s the best DrupalCon yet.  Nancy Flowers-Mangs: Nancy Flowers-Mangs, and I’m from Yale University, and my favorite thing about DrupalCon is the networking.  Jason Pamental: Hi, I’m Jason Pamentel. I’m the Senior Director of Design and Technical Strategy at Isovera in Waltham, Massachusetts. And so far my favorite thing about DrupalCon New Orleans was Sara [Wachter-Boettcher]’s keynote yesterday. Absolutely blew me away in every possible way. Fantastic.  Tasha Cherry: Tasha Cherry, and I’m from the University of Virginia. And I think one of the coolest things that I’m hearing from the conference is just how accessibility is going to be so much easier using Drupal 8. That’s what I’m excited about. Because we’re implementing more accessibility into our designs and things like that, and it’s more crucial to just our operations now. So that will help a whole lot. So things will be automatically built in as opposed to trying to convince people to do it right away.  Sam Boyer: I’m Sam Boyer from Tag1 Consulting. My favorite thing about DrupalCon 2016 is shrimp and grits.  Larry Garfield: I’m Larry Garfield with Platform.sh. Best part of this DrupalCon was Dries laying out actual plans that make sense, and might actually be achievable, which is great! Seth Brown: I’m Seth from Lullabot, and my favorite part of DrupalCon New Orleans has been the renewed vigor and energy now that Drupal 8 is actually out. I feel like our team is thrilled with the sessions. Everybody is kind of excited to dive back in It feels like Drupal, you know, around circa Chicago, everybody is excited again. So I think it’s a huge win for us to have Drupal 8 out.  Morton DK: Hi. Morton DK here, out of Copenhagen, Denmark. I work for Geek Royale and Tag1 Consulting. My favorite about this DrupalCon in NOLA has been to see the front end community and back end developers coming together on a simple alignment so we can push our code forward and make a pretty amazing product in Drupal 8.  Michelle Krejci: My name’s Michelle Krejci from Pantheon. The best thing about DrupalCon was just conversations with everyone.  Roy: My name is Roy. I’m from the Netherlands. I’m a user experience designer. And the best thing I saw at DrupalCon New Orleans was that from the DriesNote to the different core conversations we had, I can see that people are not burned out on Drupal 8, but people are seeing the opportunities for Drupal 8 moving forward, and that was really inspiring. UX is a big part of that, and I’m hoping to do more and more of that in the coming months. [Sounds from Trivia Night, with Jeff Eaton hosting] Todd Jamieson: My name is Todd Jamieson, I’m from Boston. I work at MIT. I support web development and project management for our internet presence at MIT for Career Services. And my favorite thing at Drupalcon . . . oh there was a lot. I think it was a use case by the Sierra Club. I was very skeptical going in, and by the end of the presentation it totally nailed exactly some of the things I’m dealing with at my office. I loved it.  Erik Peterson: My name is Erik Peterson. I work for RiffTrax in San Diego, from the guys that brought you Mystery Science Theater 3000. My favorite part of DrupalCon 2016 in New Orleans was . . . besides Emeril’s Restaurant . . . has to have been the Drupal 8 Kickstart panel, and the deluge of information that gave me what I needed to know to get started developing for D8.  Drew Gorton: My name is Drew Gorton. The best thing about DrupalCon 2016 is the people. Jeff Eaton: Hi, my name is Jeff Eaton. I’m a Digital Strategist for Lullabot, and I think one of the best things about DrupalCon for me this year was the number of people that I was able to talk to and meet who talked about how much of an impact Drupal has had on their lives and their careers over the past decade. As Drupal has aged and grown, the number of people in our community who have really impressive stories about what it’s meant to them has grown with it. And I think that’s really encouraging, and really really really exciting. AM: It really really really is! And since it was my first DrupalCon, I thought it was terrific. And we will be back next week with our usual Secret Sauce, but I hoped you enjoyed this little special edition. To find out more about Palantir, you can go to palantir.net, or you can follow us on Twitter at @palantir. Have a great day!

CEO and Founder George DeMet shares a continuation of ideas presented at DrupalCon Barcelona with his new talk on the benefits of running a company according to a set of clearly defined principles, which he's presenting next week at DrupalCon New Orleans. It's called Finding Your Purpose as a Drupal Agency. Want to learn more? We have built Palantir over the last 20 years with you in mind, and are confident that our approach can enhance everything you have planned for the web. TRANSCRIPT Allison Manley [AM]: Hi, and welcome to the Secret Sauce by Palantir.net. This is our short podcast that gives quick tips on small things you can do to make your business run better. I’m Allison Manley, an account manager here at Palantir, and today’s advice comes from George DeMet, our Founder and CEO, who as a small business owner knows a thing or two about how to run a company based on clearly defined principles.  George DeMet [GD]: My name is George DeMet, and I’m here today to talk about the benefits of running a company according to a set of clearly defined principles. What follows is taken from a session that I presented last fall at DrupalCon Barcelona on Architecting Companies that are Built to Last.  At the upcoming DrupalCon New Orleans in mid-May, I’ll be continuing this conversation in an all- new session called Finding Your Purpose as a Drupal Agency. If you’re able to attend Drupalcon New Orleans, I hope you’ll check it out. Some time back I came across an article from the early 1970s about my grandfather, who was also named George DeMet. He was a Greek immigrant who spent more than 60 years running several candy stores, soda fountains, and restaurants in Chicago. While the DeMet’s candy and restaurant business were sold decades ago, the brand survives to this day and you can still buy DeMet’s Turtles in many grocery stores. I never really got to know my grandfather, who died when I was 7 years old, but I have heard many of the stories that were passed down by my grandmother, my father, and other members of the family. And from those stories, I’ve gotten a glimpse into some of the principles and values that helped make that business so successful for so long. Simple things, like honesty, being open to new ideas, listening to good ideas from other people, and so forth.  And as I was thinking about those things, I started doing some research into the values that so-called family businesses have in general, and that some of the oldest companies in history have in particular.  The longest lasting company in history was Kongo Gumi, a Japanese Buddhist temple builder that was founded in the year 578 and lasted until 2006. At the time that Kongo Gumi was founded, Europe was in the middle of the dark ages following the fall of the Roman Empire, the prophet Muhammed was just a child, the Mayan Empire was at its peak in Central America, and the Chinese had just invented matches.  At some point in the 18th century the company’s leadership documented a series of principles that were used by succeeding generations to help guide the company.  This included advice that’s still relevant to many companies today, like:  Always use common senseConcentrate on your core businessEnsure long-term stability for employeesMaintain balance between work and familyListen to your customers and treat them with respectSubmit the cheapest and most honest estimateDrink only in moderation Even though the Buddhist temple construction and repair business is a pretty stable one, they still had to contend with a lot of changes over their 1,400 year history. Part of what helped was that they had unusually flexible succession planning; even though the company technically was in the same family for 40 generations, control of the company didn’t automatically go to the eldest son; it went to the person in the family who was deemed the most competent, and sometimes that person was someone who was related by marriage.   Kongo Gumi not only only built temples that were designed to last centuries, but they also built relationships with their customers that lasted for centuries. In the 20th century, Kongo Gumi branched out into private and commercial construction, which helped compensate for the decline in the temple business. They also didn’t shy away from changes in technology; they were the first in Japan to combine traditional wooden construction with concrete, and the first to use CAD software to design temples.  And while Kongo Gumi’s business had declined as they entered the 21st century, what ultimately did them in were speculative investments that they had made in the 80’s and early 90s in the Japanese real estate bubble.  Even though they were still earning more than $65 million a year in revenue in the mid-2000s, Kongo Gumi was massively over-leveraged and unable to service the more than $343 million in debt they had accumulated since the collapse of the bubble, and they ended up being absorbed by a larger construction firm.  Principles are designed to help answer the question of *how* a company does things, and what criteria they should use to make decisions. In the end, Kongo Gumi was no longer able to survive as an independent entity after 1,400 years in business not because of economic upheaval or changes in technology, but because they strayed from their core principles, stopped taking the long view, and went for the quick cash. Companies that want to be successful in the long run need to identify their core principles and stick to them, even when doing so means passing up potentially lucrative opportunities in the short term. Regardless of whether the business involves building Buddhist temples, making chocolate-covered pecans, or building websites, a focus on sustainability over growth encourages companies to put customers and employees first, instead of shareholders and investors. These kinds of companies are uniquely positioned to learn from their failures, build on success, and learn how to thrive in an ever-changing business landscape. AM: Thank you George! George will be presenting his session, Finding Your Purpose as a Drupal Agency at DrupalCon New Orleans on Wednesday, May 11. You can find out more on our website at palantir.net and in the notes for this particular podcast episode.  If you want to see George’s presentation from DrupalCon Barcelona last year on Architecting Drupal Businesses that are Built to Last, you can also find that link in the notes for this episode as well.  For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Have a great day!

How do you build a variety well-rounded content for your site? And is it all working toward a common goal? If it seems disparate, maybe it's time to look at your content development, writing, and publishing as an ecosystem where all parts – big and small alike – have their place and are working together to support that ecosystem. But how does it work? Marketing and Communications Lead Shawn Smith shares his thoughts and provides a framework in this week's Secret Sauce. TRANSCRIPT Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by Palantir.net. This is a short podcast that offers a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an account manager here at Palantir, and today’s advice comes from Shawn Smith who is going to talk about how content ecosystems can work for you. Shawn Smith [SS]: Hi I'm Shawn Smith, Marketing and Communications Lead here at Palantir.net. Today I'm going to talk to you about the concept of a content ecosystem, and why it might be the right choice for your team and organization with regard to content creation, publishing, and how it dovetails with your overall marketing strategy. This is a big topic, of course, so I'm going to do my best to give you a high level overview of how it could work, without getting too far into the weeds. Think of it as a general framework, with which you can begin to understand how you could use it, and also how to think about the development of your content (including but not limited to content verticals). It also has to deal with your sales and marketing goals, customer personas, and other important considerations, so the assumption going in is that you have some of this articulated. With that in mind, let's start at the beginning: an ecosystem. In biological terms, an ecosystem is a biological community of interacting organisms and their physical environment, or, in general use, a complex network or interconnected system. The important terms here are community, interaction, network or system, and interconnectedness. And health, but we'll get into that later. I think this concept is particularly useful if you are part of a small marketing team. Here at Palantir, the team is quite small… in other words, it’s just me. I have some help from our account managers, our sales folks, and others. BUT there is a big caveat here regardless of marketing team size, and that is the opportunity for team-sourced content. After all, we have about 25 different people working at different disciplines in the company.  Given that content publishing is hugely important for a service-based company like Palantir for sales purposes, we *must* have a variety of different content types to attract and keep engaged our various audience types (and ultimately lead them to choosing us for projects, of course). We create content about the kind work we do, share insights on new technology, details on events at which we're speaking, how our company operates culturally, job openings, our client's projects, and many other types. And while we work in a variety of disciplines, some, like development and supporting technologies, are quite technical in nature. So we'll use something technical as an example for developing content as part of an effective content ecosystem. But before we talk about content, let's start with the 20,000 ft view of this content ecosystem framework to understand how it operates: It's important to think holistically, and build upon some sort of overarching goal your organization has. What is the goal upon which we can build a foundation for our marketing plan and strategy? We value collaboration and transparency both internally and with our clients at Palantir. And with our 20th Anniversary around the corner, we're focusing on allowing our company values to surface throughout the content we generate. That's a great goal to use an anchor. From there, we think of a supporting theme for the quarter (or any length of time that may work for your organization). This theme could be one of your marketing campaigns. For example, we know that our strategy services in all their forms are incredibly important for our client projects, and can vastly increase the success rate. We'll use this as our supporting theme for the quarter, focusing on strategy services. From here, you can get as granular as you wish. I like to then take the quarterly theme, and break it down monthly and overlay with other targets we want to hit due to an event coming up, a conference, client project launching, or some other kind of happening. You can go further down this rabbit hole, too, breaking down by week or even by day should there be a particularly important sales and marketing opportunity coming up. Now that we have a basic framework, let's get back to content. Earlier we decided to go with something somewhat technical in nature… so how about Drupal 8 as a platform choice for our client projects? It's a big topic, and can inspire content big and small in nature, and that's perfect because every bit of content in the ecosystem has its place; it could be small and fun and, say, community facing, or technical and epic, or somewhere between. Now, let's take a look at Drupal 8 as a content generation concept, with strategy as a theme, and collaboration and transparency as our overarching goal. What content can we develop around this? We could talk about Drupal 8's new features that make it easier for content editors to publish content. That is likely strategically important for our almost all of our clients. But how does this work in Drupal 8? This could be a blog post, a webinar, a downloadable how-to, a podcast, and certainly supported via social channels to point people to this various content. We could also talk about something much more technical in Drupal 8, like how it has REST baked in, or how it plays nice with a suite of PHP technologies out of the box. The question here then becomes: who are we targeting with this content, and where does it fit into our content ecosystem during this time? More specifically, how does it work with our theme? And further, does it hit our target goals? It could, so long as we tailor that content to do so. REST being baked into Drupal 8, not to mention it playing nice with PHP technologies, provides our clients a variety of interesting ways to surface data and interact with external data sources to offer the kind of content and information their audience wants. So we can talk about that generally, or offer a technical whitepaper. We could host a webinar that explains this in a non-technical way to be more transparent about technology. Any many other content types, all appropriate for our theme, working toward our goals. The examples could continue, but the important thing is that it sets you up with a framework to both make sense of what content you could publish, but more important WHY you're publishing it. It's also important to make this concept your own. It shouldn't be overly rigid, it’s not prescriptive, nor should it be too soft… instead it should be… well, squishy. After all, stuff is going to come up and you'll have to pivot and scramble to get some sort of content online that may not entirely jive with your theme or goals exactly. To review: Establish your company goals, whatever they may be You then develop a quarterly theme based on some targets or other happenings occurring during that time You determine your preferred level of granularity, be it monthly, weekly, or even daily You then create content that both supports your theme and goals, making sure you look at it through these important lenses Then you make sure you have a variety of content, whether small and fun or technical and epic, or something between If you're interested in introducing this for your company, and you're in charge of marketing and/or content generation, you'll need to own it and act as the product owner, really. And if you have a team from which content can be developed, their buy-in is going to be key to your success. While this approach may be rooted in generating leads and driving sales, it's also about highlighting all of the things that make your company and your team amazing. Revenue generation is a nice byproduct of that. If you utilize this method, and make it work for your organization, I'm confident that in time you'll have a healthy content ecosystem. And as an aside, if you use the inbound methodology, this is a fantastic compliment to that as well. I'll go into greater detail with a downloadable template next month on our blog, so sign up to our newsletter to be informed. In the meantime, thanks for listening, and email me at smith@palantir.net should you want to discuss content ecosystems or other concepts presented today. AM: For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Have a great day!

If you've ever worked on a web project at any scale, you may have participated or lead daily scrums. These mini meetings provide regular touch points for projects, and help keep it humming.  However, those not familiar scrums may have heard the term, but don't exactly understand what they're all about. So why do we have scrums? Are they valuable? If so, what’s the best format them? And what’s the role of a scrum master, anyway? Project Manager Chad Goodrum joins Account Manager Allison Manley and shares his knowledge on the subject. TRANSCRIPT Allison Manley [AM]: Hello and welcome to The Secret Sauce, brought to you by Palantir.net. This is a short podcast, just a few minutes long, that offers a quick tip on some small thing you can do to help your business run better.  I’m Allison Manley. I’m an Account Manager here at Palantir, and today’s advice comes from Chad Goodrum, one of our Project Managers. Chad is going to talk about meetings in the  development world known as scrums. Chad Goodrum [CG]: Hi, this is Chad Goodrum with Palanatir.net.  I’m a Project Manager here at Palantir. I’d like to talk today a little bit about scrums. We use those every day in a 15-minute standup with the development team, which includes our developers, designers, Product Owners from the client side, project managers, strategists, and other stakeholders inside the Palantir team.  The format of our scrums take place on video conferences. We find that scrums are more useful when they are face to face. If they can’t be face to face, we find that at least a visual representation or through video conferences work better for us.  Why do we have scrums? We use scrums daily as a way to look back in 24-hour increments what the team has worked on, what they’re going to be working on, and any issues or blockers they may have.  What’s the format of a scrum? The format of a scrum is pretty casual. People refer to them as “standups” where people used to stand up together in a 15-minute scrum. But typically what we do is we have a short conversation, and go around the room or the video conference with each individual discussing what they have worked on. So let’s say we have a developer named Jan. Jan will say what she worked on the day before, go over tickets at a high level and discuss what she worked on; she will say what she’s working on today . . . maybe it’s a continuation of those tickets, maybe it is starting something new; and then she will mention any blockers that she may have. These could be feedback from the client, feedback internally, issues with the user story or ticket that she’s working on . . . this gives the team a perspective to take a look at that issue as a whole and give immediate feedback or schedule a later call or conversation to discuss that. It’s a high level conversation that we can have internally to make sure that we are on track every day.  Some things we use to manage scrums: we have something called a scrum log. Scrum log is a basic document with each team member’s name on there discussing what they’ve done, what they’re going to do, and any blockers they have. A requirement is that it’s filled out prior to the meeting every day. The meetings are going to be at the same time every day for consistency’s sake.  Another requirement that we have is not being shy or conservative to talk about issues you are having. Sometimes this comes up with the client product owner is on the scrum. But it’s more detrimental not to talk about an issue that you’re having then to talk about it and bring it the attention of everyone on the team. What’s the role of a “scrum master?” The scrum master is not a stakeholder in the conversation itself. The scrum master is the mediator or moderator. They are the ones who are going to facilitate the conversation. They’re not there to give opinions about the process itself. So the scrum master is going to call the meeting, make sure everyone’s on time, go through the meeting, set up further meetings if there needs to be meetings internally or externally with the client.  There’s been a lot of talk internally here at Palantir about having product owners on the scrums daily, or not having the product owners on. And there’s been a lot of pros and cons of that. The pros of having the product owner on the scrum with us: it gives them daily visibility into what we’re working on. It’s a transparency at Palantir that we really like to have. That way there are no questions or concerns maybe at the end of a sprint, in two week increments, where they are unaware of what we’ve been working on for two weeks.  One of the cons that I discussed earlier was about being shy or conservative around the product owner. If someone has an issue maybe with the architecture, or some of the strategy, or some conflicts with the overall process, many times developers (myself included) will tend to be a little shy about bringing those issues up to a product owner. So sometimes we’re not as candid as we could be without the product owner. There’s talk about where being shy or not as candid could actually lower velocity for the team.  Another concept of scrum is the idea that scrums are self-managing, that there’s not one person that is responsible for the scrum. And by self-managing that means that everyone is accountable for all things. That includes the scrum log being filled out, being on scrum on time, being on video, and being candid about your issues or concerns that you may have on a daily basis. And by self-managing that means everyone on that team has the right, as well as the duty, to speak up if something is not going accordingly . . . whether someone’s late, misses scrums, or a known issue that isn’t discussed.  Scurms in general at Palantir provide an immense amount of value to the team, to the client, and to the overall success of the project. Without doing daily scrums, it would be very difficult for everyone on the team to know what others are doing on a daily basis. Check-ins once a week are not enough for us to have a consistent, transparent view of the project as it moves forward. When we’re working on any sort of format that’s agile or agile-like, daily standups or daily scrums are imperative to the project’s success.  AM: Thanks Chad! And thank you all for joining in on this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day!

DrupalCon is just a few weeks away in New Orleans, so this time around our Account Manager Allison Manley is joined by our CEO and Founder George DeMet, Drupal veteran and PHP guru Larry "Crell" Garfield, and Senior Front-End Developer Lauren Byrwa. They share thoughts about the conference generally, what they're excited about specifically, and what they're expected from the Driesnote, among other topics. TRANSCRIPT Allison Manley [AM]: Hi, and 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 April 2016, and this is episode #4. I’m Allison Manley, an Account Manager at Palantir, and today we are going to give a preview of what to expect from the upcoming DrupalCon in New Orleans which is taking place May 9th through the 13th. The website is drupalcon.org if you want to see more. I’m a newbie to DrupalCon — this will be my very first one — so I gathered a bunch of my seasoned colleagues here at Palantir who have attended in the past to get their thoughts on the upcoming conference. I am here with three of my fabulous colleagues that are going to be attending DrupalCon with me. So I have Lauren Byrwa, who’s one of our senior front-end developers. Lauren Byrwa [LB]: Hi! AM: George DeMet, founder and CEO. George DeMet [GD]: Hello. AM: And Larry Garfield, Senior Architect and Community Lead. How are you? Larry Garfield [LG]: Hello, world. AM: So what we’re doing here is basically a preview of DrupalCon. DrupalCon is coming up in a couple of weeks, in New Orleans, which is very exciting. How many DrupalCons is this for each of you? LG: I think this will be #21. AM: Out of how many? How many have there been? LG: Maybe 25? I’m a staple at this point [laughs]. GD: It’s a good question. Not as many as you, Larry, but probably, if I had to guess, between 15 and 20. LB: I’m actually only at #2 for Cons. So not a whole lot compared to these guys. AM: I’m a complete newbie, so we’ll get to that later — what I can expect — but before we get to what most people or new people can expect from DrupalCon, or what DrupalCon is about — we know that Drupal was started by Dries Buytaert. Did I pronounce that right? LG: Close enough for an American [laughs].  AM: What is the correct pronunciation, please? LG: Well, I’m an American too. ‘Drees Boy-thart’ I think is closer, but don’t quote me on that. Dries, feel free to correct us. AM: I’m sure he will later [laughs]. So what is DrupalCon about? LG: DrupalCon is the summit of the community. It is the largest Drupal in-person event in the world by a very wide margin. It’s a place for the whole community of whatever stripe to gather and discuss, learn, teach, plan, work, play, drink, and several other things along the same lines. A lot of conferences are very developer-centric or very business-centric, or very whatever. DrupalCon is — these days, DrupalCon is a Web conference with a Drupal angle to it. There’s sessions for back-end developers, there’s sessions for front-end developers, there’s sessions for project managers, there’s sessions for content strategists, there’s sessions for business owners — whatever you do, if it involves Drupal or the Web in some way, there’s at least a couple of sessions that are worth going to for you. GD: I would agree, and I would say that even if you don’t do Drupal or you’re not someone who’s really immersed in the technology or the community, it’s still a conference with really great value. You can get a lot out of it, and I think particularly for folks who are new to DrupalCon, it’s a really great way to get immediately connected with the community. And it’s often a very overwhelming way. We’re a very friendly and welcoming community, sometimes overly so. LB: I would like to think of DrupalCon as our family reunion, for all Drupalers. We’re there to learn, we’re there to share, but mostly we’re there to collaborate. And that can happen in sessions, that can happen at happy hour,that can happen anywhere. But it’s a great way to get plugged into the community.  AM: So I am a newbie, as I said — this will be my first. So what should I expect from DrupalCon? Am I just going to walk in and be completely overwhelmed at first? GD: Yes. AM: [laughs]. LB: I think at my first DrupalCon — overwhelmed? Yes, definitely expect to be overwhelmed no matter what. But feel comfortable, feel welcomed. Everybody is excited for newcomers. Everyone is excited to get to know you, to hear your ideas. So stand up and talk, and listen, and ask questions. And go up to people that intimidate you, and tell them that you’re a huge fan and that you work with their tools every day and that you like what you saw in this blog post. And they’ll be flattered and want to know what you think and why or why not you agree or disagree. But talk to everybody. Talk to them on Twitter, talk to them in person, talk to them at bars — everything you can do to soak up as much information as possible. That’s always my number one.  LG: The main thing you should expect at DrupalCon is 3000 introverts playing extroverts, who really want to talk to you and teach you things because that’s what they do. And if you’re up for talking to people you’ve only heard of, or never heard of, and just learning from every person you run across, you’ll do just fine. GD: And I think — so when we’re at our booth, every year without fail I’ll be standing there and someone will just kind of come up to me, and they’ll have The Look in their eyes. It’s very clear that this is their first time, they’re feeling very overwhelmed. And it’s really funny, this happens every time, they’ll make eye contact, come over to the booth, pull out their program guide, and be like, where do I go? And there’s so many different things you can do and places you can go and sessions you can experience, and it really is about — I think for folks who are going, it’s really taking a look at the sessions, figuring out ‘what do I want to get out of this event’, and focusing on that. And if you are getting overwhelmed, just find a friendly face, and they’ll more than likely be able to help you out and point you in the right direction – ‘oh yeah, I know the person doing that session, they’re awesome, go to that session if you want to learn about this, so-and-so is like the world’s expert on that’. All kinds of opportunities to just soak everything in, and learn what you can. It’s a really fun, really intense time. AM: Great, I’m really looking forward to it. So every year Dries gives a keynote. And it’s fairly spectacular, I’ve seen a bunch of them on YouTube. They’re very involved. So what are you anticipating this year from the Driesnote, as he calls it? LG: I have no idea what Dries is planning. I think the best keynote he’s given in recent years was in Amsterdam, where he was talking about actual practical changes to our process. That’s where he introduced the plan for putting credits on the site, which got implemented later. And I think that’s been a great thing to encourage contributions from companies and clients and commercial organizations, which we absolutely need.  I’d like to see something inward-looking. By that point Drupal 8.1 will have just come out, and that’ll be the first time we’ve done that type of release in, I think, ever in Drupal. So I suspect he’ll be talking about that and the implications of being able to evolve the system more smoothly than in the past. That’s my prediction, such as it is. [this was cut from the original recording due to audio issues, but is left intact for the transcript] GD: I’m hoping that Dries will take this opportunity to talk a little bit more about what the vision and future direction of Drupal is going to be, not just from a technical standpoint but really from an — answering the question, why does Drupal exist? What we’ve seen over the last few years, particularly as we’ve been through the Drupal 8 cycle, is that Drupal has changed and evolved tremendously. And at the same time the kinds of people that use Drupal, and the ways that they are using it, have changed tremendously. And I think that a lot of folks in the community have moved along with those shifts, but others might be feeling a little left behind, like they’re not really sure. Maybe if you’re somebody that’s joined Drupal at a point in the past, and you’ve had a particular motivation for doing so, the project and the community may be very different now. I think as we go through that change and that evolution, having a shared understanding and grounding in what our shared values are as a Drupal community and a project would be really cool to hear from Dries. LB: I would say we’re actually at a place right now where we don’t entirely know what’s next for Drupal. We’re not waiting on D8 any more — there’s a whole slew of things out there. And so I agree that the future of Drupal is going to be a big topic. I think in addition to that, this is our good chance and this is Dries’ good chance to really press on contribution, and to recruit people.  A lot of our hardcore developers that helped build D8 are feeling a little burnt out. They too are celebrating the release, but in addition to that, they’re feeling a little burnt out after years and years of press to get it there. So I think contribution is going to be a really big topic this year — trying to figure out how to get people involved and how to get new blood in the system and new  ideas. To really push us towards that future, that’s going to be important. AM: That’s a lot to cover in one keynote [laughs].  GD: The expectations are always incredibly high for these things. And it’s really often almost too much to ask, that one person will be able to cover this much in an hour or an hour and 15 minutes. One thing I’ve seen is that sometimes, when Dries delivers, he really delivers in a really great way. But I also know that it’s really hard to do that. So hopefully everything will click in place. I’m looking forward to it. AM: Me too. So what are the big talking points in Drupal right now? Obviously I can assume Drupal 8. What else do you think will be the big things? LB: A big focus of this year’s DrupalCon is actually a lot of the front-end frameworks and performance. Like we said earlier, it’s really kind of a dev conference with Drupal in the background. So we’re really trying to branch out as a community and accept some of the other new things going on in tech right now, and I know that’s going to be a big press this year. LG: There’s a whole lot of sessions on the front-end frameworks, like Lauren was saying, and around the discussions around, should Drupal have a front-end framework baked into it, like Angular or Ember? Or should we do something along those lines with our own components? Or should we ignore all of that? Or should we, whatever? So there’s actually a new track for this con called Horizons that has — pie-in-the-sky ideas. That’s kind of the point of that track. So we actually have the project lead of Angular talking. We have the project lead of Ember talking.  And there’s a number of other sessions along similar lines. We’ve got a core conversation that was originally supposed to be a moderated fight between people who wanted a front-end framework and people who didn’t. I think it’s turned into — those people have already fought and have a plan now, and what’s that plan, but we’ll see. Definitely, the front end and JavaScript are big talking points.  Another core conversation, as Lauren was talking about, is burnout. We have two, maybe three, sessions on time management and burning yourself out and managing volunteers, and what happens when people leave Drupal and how can we learn from the people who have. People will always come and go from any project, but how do we do that in the most graceful fashion, so that it’s good for those people and good for the project. That’s another talk we have there. And then of course, continuing the ‘get off the island’ angle, we have a Symfony track, as we’ve had the last couple of years. We have a dedicated PHP track — that’s non-Drupal-specific PHP that we actually collaborated with Php[architect] on. I was one of the track chairs for that. It’s the first time we’ve had it in North America — we’ve had it in Europe. And then the Horizons track includes a lot of big ideas outside of Drupal, so there’s a lot of, what new stuff outside of the Drupal experience should we be looking at and taking stuff from. LB: In addition to what Larry was saying, there’s a new spotlight on mental health in the tech industry, and this is going to be a big issue. You’re starting to see real sessions on mental health and taking care of yourself as a developer. But I also think it’s going to be a hot-button issue for BOFs, and you’re going to see a lot of talking about it outside of sessions as well, and how to cope with this environment. AM: OK, wait a minute. Can we define “BOF”? LB: My apologies, it’s an acronym for “birds of a feather”. It’s a group talk where people of like-minded ideas or having the same interests get together and have a conversation about it, as opposed to somebody getting up and presenting about a topic. It’s a more casual and close way to discuss some of the issues that are popular. GD: And so one of the other hats I wear in the Drupal community is serving on the Community Working Group. And I know that we’ve been talking internally about a lot of the challenges we’ve seen, experiencing burnout, and trying to improve — trying to provide more communication tools and resources, particularly for folks in the core development community. So I’m really happy to see an increased focus on that, not just at this DrupalCon but at the last couple of DrupalCons. I think we’re going to have more and more, hopefully more structured, programs and resources, so that people can contribute in a way that is sustainable in the long run. The other kind of big topic or trend that I’m seeing is — I think there’s a little bit of a question or tension, that ties into a lot of the technical questions, about the extent to which Drupal is a product and Drupal is a software platform. If you think about it in terms of Legos, is it a big box of a whole bunch of Legos that you can put together in any kind of different shape or form to create whatever you want, or is it more kind of a Lego construction kit that’s got all the tools you need to build a truck or a boat or whatever. And the extent to which we move in one direction and make Drupal more of a polished product — does that undermine our ability to be incredibly flexible? And so there’s questions like, do we have a decoupled front end? How do we approach questions like content workflow and management and all that stuff, and how much is that prescribed by the system? These are all really important questions that we’re going to have to, as a community, come to some sort of agreement or consensus on as we move forward. LG: As a side note, on the mental health front, our third keynote for Thursday is from Michael Schmid, a long-time Drupaler. He’s talking on brain health and mental health and so forth. It’s definitely an area worth the time it’s being given, which is considerable and as it should be.  AM: Great — I definitely want to get to some of the sessions that you’re excited about. So there are 13 tracks total in DrupalCon this year. Some of them are new, as you mentioned earlier, and they cover quite a range of topics. So there is something for everybody. I am not an engineer myself, but there is plenty for me to absorb at this conference [laughs], because the tracks are so varied. And I haven’t counted how many sessions there are in total, spread across those 13 tracks. LG: I think it’s 131 or something like that. AM: Wow. So there’s a lot of information being shared. So outside of the Palantir-led sessions, because we are leading three — which we’ll cover in a bit — which sessions are you most excited about, aside from the ones you’ve already mentioned? LG: I’d say I’m most looking forward to the core conversations on burnout and on community management, and on how do we keep this process sustainable? Because the way we went about Drupal 8 is not sustainable. That level of work was necessary for the project, but that kind of surge mentality of, throw warm bodies at it and work extra hard to make sure it gets done, is not a good way of developing software, open source or not. I’m looking forward to the discussions that are already slated around, how do we not do that? How do we make Drupal successful, or more successful, and how do we make our people more successful while respecting the fact that people still have lives and limits, and people have families? We don’t want to inadvertently pressure people to sacrifice those. No one consciously likes to do that, but there’s unconscious pressure at a lot of times. So how do we counteract that in a healthy fashion? Topic-wise, that’s probably what I’m most looking forward to, probably followed by some of the front-end framework discussions. LB: As a front-end developer, I’m interested in some of the config management in D8, some of the front-end frameworks, I’ll definitely be at those. But outside of that I’m also really looking  forward to the content strategy and UX things — D8 accessibility, content strategy and popular culture, some of these look really interesting. I know there’s also one on lessons from WordPress that I think is going to be really great as well. I think there’s a lot of great sessions regardless of what you’re specifically interested in.  GD: Unfortunately, one of the things about being someone in my position is that I don’t really get to go to sessions very much [laughs]. I actually have not looked too much at the program schedule yet. AM: But you will, of course [laughs]. GD: I will, certainly. And I will pick out a few sessions and put them on my calendar and will intend to go to them, and then inevitably something else will pull me away and I’ll end up watching the recording after the fact. AM: But luckily they are all recorded. GD: They are all recorded. And they’ve gotten really good at making sure that the session recordings are up usually within a day or two of when they’re recorded, which is a very impressive logistical feat. So I’m really happy with that. And in addition to Michael Schmid, or Schnitzels — that’s his nickname — and his keynote, I’m very much looking forward to, and I hope I don’t destroy her name here or we can correct it in post-production, Sara Wachter-Boettcher, who’s doing a keynote on content and design. I’ve read a lot of her stuff and I’m really excited to hear what she’s going to have to say for the Drupal community. One of the great things over the past few years is that we’ve really started thinking more about design as a project, which is really important and really challenging for an open source project – to really come together and prioritize not just what the software does but how people interact with it. LG: That’s something that we’ve been seeing not just in the visual design aspect. We have a session in the PHP track that I’m really looking forward to, called “Your API is a UI”. The idea is that code should be designed with the same kind of thought you put into user experience for someone pushing buttons — it also needs to go into how someone is writing code. And that’s something that the community is starting to get their head around in the last couple of years. So I’m really excited for that session and others like it, that push that concept. AM: Well, let’s talk about the ones that Palantir is leading. We have three. One is “PHP 7: The New New PHP”. LG: I talk about new stuff [laughs]. This is a talk that I’ve given at a few PHP conferences – it’s not Drupal-specific at all, it’s in the PHP track. PHP 7 was released last fall, right after Drupal 8 was – its release date was actually pushed back because of Drupal, we kept finding bugs. But for the developers and sysadmins in the room, if you have not tried out PHP 7, you really need to. It’s got a ton of really nice new features which I talk about in the session, and it’s twice as fast. And I’m not just showing marketing numbers – there are companies that have said they’ve shut down half their servers by switching to PHP 7. It is dramatically faster. Drupal 8 requires PHP 5 or later, and I would say, within six months if you’re not running Drupal 8 on PHP 7 – you’re doing it wrong. You’re leaving money on the table, you’re hindering your own developers. So come to the session. I’ll tell you all the reasons why as a developer you really, really want to be using PHP 7 right now. AM: Really, really! LG: Really, really, really [laughs]! AM: So your second session is “D8 Module Acceleration Program”.  LG: And this isn’t a normal track session, this is actually in the Business Showcase. It’s a panel that Acquia is putting together. Acquia, as some of our listeners know, has been funding a program called MAP — Module Acceleration Program — which is basically, hey, Drupal 8 is out, what about contrib, let’s put some actual money behind getting the major contrib modules up and running on Drupal 8. And Palantir has been partnered with them, as have a number of other companies. Acquia has provided some funding, and Palantir is working at a reduced rate because we’re doing community work, essentially. My main work for the last few months has been the Workbench moderation module for Drupal 8, as well as the multi-version Workspace deploy suite which I’m collaborating on with some other developers at Pfizer. So the idea is there’s a panel of people who have been working as part of this program, saying, okay, what is it, why is it, what are the benefits of it, what does it mean for contributing to open source. Teaser: contributing to open source is a viable and important part of any business that’s using it, and it is a worthwhile investment. Now you can come to the session to hear the details of that. AM: Cool. So the last session is George’s session, “Finding Your Purpose as a Drupal Agency”. GD: Yes, so I’m going to be doing a session in the Business track. It’s a little bit, for those who might have seen the session I did for DrupalCon Barcelona last fall, it’s a little bit of a sequel to that session. Essentially what I’m going to be talking about are some of the challenges. Last year was a fairly challenging time for a lot of companies in the Drupal ecosystem. Everyone was kind of waiting for Drupal 8 to come out — a lot of folks were holding off on starting new projects because of that, and so I’m going to talk a little about that. I’m reaching out to some other folks, some other companies in the Drupal ecosystem, hoping to get them to share some of their perspectives as well.  But then I’ll be talking about how, particularly during challenging times but during any time in general, the value of defining your purpose as an agency — your vision, your values, and how those things really come together and enable you to really have kind of a focus for where you’re taking your company. And not just how you run your agency, but also why — which I think is a question that doesn’t get asked often enough. So I’m really looking forward to that. For people that might be interested, it’s not just for folks that run Drupal companies. If you are involved in or interested in any way about how companies are run, and even — I’m not going to be talking that much about Drupal in particular, so I think it will be really valuable for folks, obviously even non-technical. And one of the things I do with my talks is a lot of analogies, so I’ll probably have some pretty entertaining analogies for folks. AM: Great. Well, as Lauren touched on, beyond the sessions DrupalCon is also about the social life, and the socializing, and the community around it. So what am I to expect as a newbie, going to my very first one, after the daily sessions are over? LB: Expect to be overwhelmed. Expect to be bombarded. And expect a little debauchery. I think you’ll be entertained, to say the least, but everybody is very friendly, everybody wants to buy you a drink and hear your thoughts. And everybody wants to argue. So be willing to defend your ideas, because it will come. And you might change your mind and you might change somebody else’s, but that’s the glory in all of it. And I’ve found a lot more meaning comes from the conversations outside of the sessions than sometimes during them. So I always encourage especially first-time Drupalers or first-time Con-goers, don’t stop after the sessions. Go to the after-stuff, even if you don’t drink, even if you just want to sit there and have water and talk to people, or have a Coke. It doesn’t have to be about the drinking, and it’s a really great place to socialize and share ideas. AM: I understand that in the past there’s been things like trivia night, or karaoke, or just meeting at ping-pong [laughs]. GD: Well, in fact there is a trivia night on Thursday, and we are sponsoring it, as we have for the last couple of DrupalCons. And for me at least, it’s one of the highlights of the whole event. The key is, try to find a table with people who have been around the community a little while. But the questions can be all over the place, and sometimes they even give credit for having someone who’s at their first DrupalCon at your table. AM: So what, you get something like frequent flier miles for your very first one? [laughs].  LG: It varies by year, but I think your team gets a bonus point for every person at your table who’s at their first DrupalCon. If it’s your first time at a DrupalCon, that makes you a valuable commodity, so show up anyway [laughs]. AM: I should wear a sign. LG: And I think there’s actually a penalty if someone on your team is a core committer. So don’t always go for the table with all of the lead developers because you get a penalty for having them on your team. I’m not a core committer so I have no penalty one way or another. GD: The trivia night is on Thursday night, and I think a lot of folks may be tempted to leave early because Thursday is the last day of sessions, but definitely stick around for trivia night on Thursday. And stick around for the sprints on Friday as well. Folks are generally fairly tired by that point, but sometimes being tired at that place really lets you focus [laughs] on getting cool stuff done. And it’s not just code, it’s all sorts of things. There’s documentation sprints, we’ll often do some community work as well — all sorts of things going on even after the sessions are over. LB: Definitely, it’s an exhausting week and it’s a long one. But those sprints at the end, those make the difference, and that’s how you really get involved and how you really learn stuff. So don’t ever think that, oh, I’m not an engineer, or, I don’t know how to do this. Because if you show up, we will find a job for you. LG: There’s a number of people at sprints every year whose job is, it’s just part of sprints, to mentor people in getting started. Get your dev environment set up, figure out where to find issues to work on, figure out if you want to do code or documentation or usability testing or whatever else you’re going to do — whatever you’re interested in doing, there’s a use for it, and someone who can hold your hand along the way to get involved in it. So, yeah DrupalCon doesn’t end on Thursday, DrupalCon ends on Saturday. AM: That’s a long conference. It is. Sunday to Saturday, pretty much. LG: It is, but for all of that, it’s one of the cheapest conferences around for that length of time. It’s definitely worth the value of going. AM: So then let’s delve into the exhibition space and the vendor space. What can attendees expect from going into the vendor room, besides being thrown a whole lot of swag? Pencils, buttons, tattoos, all sorts of things [laughs]. LB: So there’s the swag, which is always wonderful. And you will find some very cool and unique swag, depending on what booths you’re at. But what I think is funny, having worked a booth before, is you’ll see vendors kind of use it as bait. They’ll watch you walk by and they’ll watch you want it but not want to talk to people, because, like Larry said earlier, we’re all introverts. We’re just pretending for the week. And so they’ll kind of bait you with it, and they’ll get you to talk. And they’ll start with something small and introductory, and you might find yourself connecting with people you didn’t expect. LG: People are generally not too pushy about it, most of the time. But yeah, tech conferences are where introverts go to cosplay extroverts. GD: So as somebody who’s been to a lot of different conferences, and seen a lot of different exhibition spaces and exhibit halls and vendor booths and all that stuff — I really love the DrupalCon exhibit hall because it’s a lot more down-to-earth. It’s a lot less sales-y than most other conferences out there. You definitely have folks who will put a little flair on their booth or have some wacky promotion or something like that, but it doesn’t feel forced as it does at many other kinds of conferences. You really can, as Lauren said, just go up to people and have a conversation. And most of the time they’ll be happy to talk to you and not just to convert the sale. AM: So of course I would be remiss if I didn’t mention that we’re going to have a booth and we’re going to be luring people in with our swag as well [laughs]. LG: Come to our booth! Say hi! We’ve got swag! AM: That’s right [laughs]. Come to our booth, there’s going to be about seven or eight of us this year, and we’re going to be booth number 222. Come visit! And the website for DrupalCon is… LG: http://www.drupalcon.org . That will redirect you to what the actual URL is.  AM: Perfect. LG: One final note. On Tuesday, you go to the pre-note. That’s not even a question. You go to the pre-note. Everyone goes to the pre-note. GD: The pre-note is kind of a tradition that’s sprung up over the last five or six years or so. It’s the presentation that occurs before the keynote on Tuesday. And it’s generally put together by the same group of people. It’s intended for people who have never been to DrupalCon before, but it’s enjoyable by everyone, and they go to great lengths to make it incredibly enjoyable. So in the past, there was one that was all themed around Disney musicals — they’re very often tied into the culture of the location where DrupalCon is being held. Occasionally in the past we have even seen Larry up on stage [laughs] singing and dancing… AM: And wearing inappropriate things [laughs]. LG: Those things were very appropriate given the character I was playing. AM: Fair enough, fair enough [laughs]. LG: Without giving too much away — this year is more musical numbers, and I’m sure there will be shenanigans [laughs]. We’re still working on it as we speak, but expect shenanigans. You want to be at the pre-note. It’s worth waking up early for. AM: Early? How early is it? LG: It’s before the keynote on Tuesday, so it’s at 8 am. And it’s worth being up and at the conference center for. AM: Good, I look forward to it. Thank you all for joining me. I’m looking forward to my first DrupalCon, thanks so much. LB: Thanks for joining us, and you can find us at DrupalCon. GD: Thank you. See you in New Orleans. LG: See you in New Orleans. Let’s have some fun! And learn stuff [laughs]. AM: Thank you so much for listening. If you want to hear more episodes of On the Air with Palantir, make sure to subscribe on our website at palantir.net. There you can also read our blog and see our work! Each of these episodes is also available on iTunes. And of course you can also follow us on Twitter at @palantir. See you at DrupalCon New Orleans!

Account Manager Allison Manley is joined today by... well, herself! She shares valuable insights on building effective Strategy Reports –  the document we generate at the end of the discovery and strategy phase of any project that includes the summary of our work, methodology, KPIs, competitive analysis, personas, usability test results, and much more – for your project. In short, they're very important. Related: How to Build a Strong Project Foundation with Practical Personas by Carl Martens TRANSCRIPT AM: Hello and welcome to The Secret Sauce, brought to you by Palantir.net. As always, this is a quick podcast, just a few minutes long, that offers a quick tip on some small thing you can do to help your business run better.  I’m Allison Manley. I’m an Account Manager here at Palantir, and today’s advice comes from . . . . me! Haha! Today I’m going to talk about Strategy Reports, which is a report that we at Palantir generate at the end of the discovery and strategy phase of any project. Some agencies refer to these as Creative Briefs, particularly if you’re in design or advertising. And they are essentially the same thing: it’s a report that summarizes all the research and findings uncovered from the discovery and strategy work done at the beginning of a project. It outlines the goals of the project, and then gives recommendations moving forward for the remainder of the project. They can be just a few pages long, or even 100 pages long depending on the depth and detail of the research.  Some items that could be included in a Strategy Report are the following:  A summary of the work, and the methodology used;A definition of strategic goals and recommended paths forward, with supporting metrics and data to help drive internal change management; Any Key Performance Indicators (KPIs) for measuring project success;Competitive analysis;Documentation of content management needs, governance and workflows;A review of any existing content strategies to recommend how to best manage content moving forward;Assuming of course you’re doing a website, ideas in which the content can be marketed and expanded beyond the web site into additional campaigns;A content migration strategy outlining how content will be moved that will include initial recommendations on time and resources required, and how to minimize the SEO impact;Any results from usability tests or surveys created during the initial phases;Any persona development created from the uncovered research;And it could even include a project schedule with milestones for strategic objectives or completion of work throughout the remainder of the process. So as you can see, they can include a lot of really valuable information, or as little as you need depending on your project.  Strategic Reports are terrific for a number of reasons. First, they lay the groundwork for the entire team. That could include marketing and communications folks, designers, stakeholders, developers, etc. The report makes sure the entire team knows exactly what the roadmap is for the project going forward, and lays a strong foundation as to how that roadmap was developed. It informs the next phases of wireframing, developing the information architecture, creating designs, and through development as all those people on the team know exactly why they are making each decision along the way when they are creating the final product.  Second, it’s a fantastic reference in case you get lost during the process. It’s really easy on long projects in particular as scope expands, or changes, or new team members come on or off a project, to lose focus on what you’re building in the first place. So when the team starts to feel like it’s straying off the path in any way, go back to that Strategy Report and review the overall goals and why you got there to help you focus back on what’s necessary to complete the project. I wrote a blog post recently called You Don’t Want Fries With That that talks about this particular reason why upfront strategy is so critical to any project.  Lastly, and this reason is more pragmatic, a summary report simply justifies a lot of the upfront research and offers peace of mind! Building discovery time into a project is critical to completing any job thoughtfully. But a stakeholder on the client end may wonder what they’re getting for their money, and they’ll want to see something tangible to justify that expense. A website is an expensive proposition, no doubt, and usually the most critical and visible marketing piece an organization produces. So of course a stakeholder might get concerned if several weeks of research and testing are happening, but they don’t see anything tangible until they see designs or wireframes much later. So summarizing all the initial work into a Strategy Report gives them peace of mind that progress is being made, as well as setting up the rest of the project beautifully for success.  That’s why I love Strategy Reports so much for every project. Thank you all for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day!

Today Account Manager Allison Manley is joined by Alex Brandt our Sales and Operations Coordinator who walks you through the top four most important things you should consider before starting up a conversation with your next strategic vendor partner. Considering these things first will set you up for a higher rate of success in finding the best vendor fit for your project.Transcript AM: Hello and welcome to The Secret Sauce, brought to you by Palantir.net. This is a quick podcast, just a few minutes long, that offers a quick tip on some small thing you can do to help your business run better.  I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Alex Brandt. Alex works on our Sales team and fields a lot of our new business inquiries, so she has some thoughts on how to best prepare yourself for your next web project.  AB: Hi, I’m Alex Brandt and I’m Palantir’s Sales and Operations Coordinator. Are you in the planning stages of a new web project? Today I’m going to walk you through the four important things you need to consider before you’re ready to start up a conversation with your next strategic partner. First, what kind of internal resources do you have? Are you a web team of one, or do you have a few developers who are just looking for some guidance? Maybe your design team is looking for a development partner who can implement their designs. Whatever the case may be, knowing what kind of internal resources are available can help your strategic partner frame the scope of your project to be most successful, while staying within the constraints of your timeline and budget.  Second, who else will be involved in the decision making process? Do you need to get anyone else on board with the project before you can get started? Do you need to get board approval or stakeholder buy-in? This is important to know, because there’s nothing more frustrating than being really excited and ready to start a project, and then realizing there is a long formal process you need to follow for selecting a partner agency. Also, the agency you’re hoping to work with might be able to provide you with some tools that can help you frame your argument for why the project is important. Third, what deadlines are driving the project? If your website is your prime lead capturing tool and you have a major conference you are sponsoring at the end of the year, you’re going to want to make sure your new website has launched by then so you can hit your marketing goals. Alternatively, if you are a large university, you want to make sure your website is functioning properly by the time prospective students are clicking through your course catalogue. Another thing you might need to consider in regard to timeline is that you may need to split your project into different chunks of time to span multiple fiscal years. This brings us to the final question you should be able to answer: what kind of budget are you working with? I know, your first inclination is to say “we have no idea, we’re asking around to figure this out,” but, if I were to throw out a budget in the range of $1 million, you might think that is way more than you were thinking and if I were to throw out a budget of $1,000 that might be way less than you were thinking.  So what’s the rough number you have in your head? Maybe this project is the largest rebranding effort for your institution in the last ten years, and you have a budget of $500k set aside for its undertaking. Perhaps you are just looking to fix some things that are broken or make your website responsive, and you have a budget closer to a high five-figure range. Whether your budget is expansive or modest, having a rough idea of this number will help your strategic partner scope out a project that will be successful and hit your goals. To sum things up, here’s a quick checklist of questions you should ask yourself when planning a new project: What kind of internal resources do you have?Who else will need to be involved in the decision making process?What’s driving your deadline for launch?What is your budget? So, do you think you’re ready to start a project? Let’s talk! AM: Thank you Alex, and thank you all for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day!

AM: Hello and welcome to The Secret Sauce, brought to you by Palantir.net. This is a super short podcast, just a few minutes every week, that offers a quick tip on some small thing you can do to help your business run better.  I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from one of our Web Strategists Joe Allen Black, who has some ideas on how to measure Key Performance Indicators, also known as KPIs.  JAB: I wake up every day and put a little black tracker called a FitBit on my belt. It’s quite tiny, with a little screen and white numbers on it that syncs up to an app on my phone. As I take steps each day, the little tracker keeps count of how far I’ve gone and compares my numbers to the number of steps my friends have taken as well. My goal each day is 10,000 steps — which is easy on the day I run a big race, but it can be seemingly impossible during a day when I’m crunching numbers in a spreadsheet on the couch. For me, the 10,000 steps is a daily KPI, or Key Performance Indicator. It’s a guidepost for me to achieving my daily fitness goals. So, what’s the whole point of this story? It’s really to get you thinking about tracking and setting up benchmarks on your websites. You can do this in your real life — thinking about the number of steps you take like I do, or hours of sleep you get each night — or on your site when you’re thinking about why you have your site and the types of things that are really bringing in your revenue. If you’re a new site, you should make sure you’re adding a tracking system to your site. For free you can use Google Analytics, which many of our clients use. At first, it’s a little daunting when you open it up, but don’t worry after popping in a few times, it definitely becomes a little friendlier. Of the dozens of types of numbers your tracking system is capturing, you’re going to want to just to key in on just a few for overall health of your site. We’re going to call these your Key Performance Indicators. What your KPIs are will differ depending on your industry. The numbers will generally fall into just a few categories: The first one’s conversions: Conversions are the actions you want your visitors to take when they use your site. In some ways you can think of this as what will make money for your site, or what will keep you going. A couple examples of these can include: On an education website, this can be the number of people who register for a course. The payment they make ultimately is a top way the education site is making its revenue. On a site like Palantir’s, we’re all about finding new customers and connecting with people who are looking for our services. A main conversion on our site is people filling out a contact form so our sales team can start working with them on a deal. A news site might be focusing on increasing the number of pageviews, since the ads on those pages are what makes the money. We then start looking at a bucket that I like to call micro-conversions, which is a fancy way of tracking the things that lead to people taking conversions, but they’re not really quite there yet. The other day I added some items to my Amazon Wishlist, I didn’t really buy anything, I didn’t spend any money, but I’m really getting close to making that conversion. I’m definitely leading toward doing that soon, so I’m making a micro-conversion at that point. Other industries may see this as users taking part in live chats, or filling out a form get an ebook or something of that nature. Last, but certainly not least, I recommend some overall site health tracking metrics. For commerce sites or sales sites, these numbers don’t necessarily lead to an immediate sale. However, these health numbers lead to knowing if there are problems or opportunities. Tracking page views per session across devices and browsers is the number one I like to look at. If I am regularly tracking how how people use my site on mobile versus desktop, I can quickly see if there’s any problems for mobile users if I change something on my site . . . if I see those mobile numbers go really down, for example. Bounce rate is another one we look at: Bounces are the number of times people go to a page and then leave without taking another measurable action. If I see a giant fluctuation in that, it could mean I need to reassess some recent choices, or examine why some people to see why users aren’t sticking around on my pages. I also like to recommend looking at the types of content people are leaving the site from. If see my exit rate on my blogs for instance going really high, I might have a problem I should address over there. If it’s really low on my sales page, I might have an even bigger problem. As you begin a redesign, it’s important to really think about what those KPIs are from the start. Before a design or development process really begins in earnest, it’s important to explicitly state what those KPIs are and then optimize your site for them. For example, if you’re a hospital, maybe one of your KPIs could be growing the number of people who make an appointment. In that case, as you design your homepage, or your content, or anything else, it’s important to think about how you can give clear paths to making an appointment on each of those experiences. Most sites we work with will have 1 to 3 main actions or conversions they want users to take. The sites may have 5-to-10 other actions that they are curious about but those are those micro-conversions, or things that are less important to the overall bottom line. If you’re someone using Google Analytics, which many of our clients do, you want to set Google Analytics to track those conversions so you know how many visitors are doing what you hoped they would. It’s a good idea to keep a regular scoreboard of these KPIs so you can constantly look back to see if you’re growing at the rate that you want to, and you can correct if you aren’t.  You can also include the site health metrics, too, so you can find out where you are having those problems, or where you have reasons to celebrate across the board. Here at Palantir, we like to document and discuss these goals right off the bat with our clients, so we can make sure we are hitting the right points early and throughout the project. We bring this discussion into each subsequent decision about the website from what features should be included, or not included, and even to what type of navigation we’re going to include. After a site launches, we want to make sure our customers have that same experience I talked about earlier with my FitBit — they have a simple benchmark that lets them know if they’re hitting their goal. Thank you. AM: Thank you Joe, and that’s it for today’s Secret Sauce. For more information on how to measure analytics for your site, check out Joe’s blog post from last year all about what metrics to check before a redesign. And the address for our site is Palantir.net. You can also follow us on twitter @palantir to always see what we’re up to. Have a great day!

AM: Hi again everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick piece of advice to help your business run smoother.  I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from one of the Founders of Palantir, George DeMet, who is going to address the need for having a code of conduct at your organization or event. GD: Hi, my name is George DeMet, and I’m the founder and CEO of Palantir.net. Today, I’m going to be talking about codes of conduct and how they can help make communities, organizations, and events more inclusive. First, a little bit of background. I’m currently the acting chair of the Drupal Community Working Group, whose mission is to uphold the Drupal Code of Conduct in order to maintain a friendly and welcoming community for the Drupal project. In the past, I have also helped write codes of conduct for open source community events, including DrupalCon, and have provided consultation and guidance to organizations and groups who are looking to adopt codes of conduct for themselves. In its simplest form, a code of conduct is a policy used by an organization to establish the standards for behavior and appropriate conduct when interacting with others in a defined space like a conference, workplace, project, or event venue. Almost any venue that serves the public, such a theater, museum, sports arena, or ice skating rink, has a code of conduct posted that sets expectations for people so that they don’t engage in unsafe behavior that interferes with the ability of others to enjoy that space. In the context of technology communities, codes of conduct fill a similar function, helping to create inclusive spaces where people can feel safe and welcome to contribute. Unfortunately, what we’ve seen all too frequently is that even as more and more people are participating in open source and other technology communities, the number of incidents of harassment has also increased. Technology communities in general, and open source projects in particular, frequently suffer from a lack of diversity, with low participation rates by women, people of color, and other marginalized populations who are frequently the targets of harassing behavior. A well-written and implemented code of conduct can help address those issues by making it clear that communities value openness and diversity, and are committed to providing an inclusive space that is free from harassment and where all kinds of people can contribute in a professional manner.  Just having a code of conduct won’t get rid of every issue, but making sure that everyone underst ands the values of your community and the ground rules for interacting with others makes a huge difference. A good code of conduct will have the impact of making it easier for everyone to participate in your community. So, how do you go about drafting a code of conduct? Fortunately, there’s a ton of great resources out there that provide a great foundation that you can build upon to meet the needs of your organization or community. Don’t worry, we’ll provide links to all of these in the description of this episode, as well as on our website at palantir.net. For conferences and other events looking for a good anti-harassment policy, the Ada Initiative’s Conference Code of Conduct is a great example for others to use. What it does well is make it clear that harassment will not be tolerated at the event, provides examples of what kinds of behaviors constitute harassment and tells folks how they can let event staff or organizers know if they feel they’ve been subjected to harassing behavior.  The code of conduct that we use at Palantir for meetups and other events that we host is based heavily on the Ada Initiative code, with some additional language borrowed from the code of conduct used by the Drupal Association for DrupalCons and other events.  It’s very important that everyone who attends your event be aware that you have a code of conduct and be able to easily access it. That means that in addition to having it posted on your event website, you should also have a printed copy on display at the event itself, usually near the entrance or event registration desk, and if you have a printed program guide, it should be included in there as well. It’s also a really good idea to mention the code of conduct at the beginning of your event or during an opening plenary session and point out who to talk to if someone has something to report. Which brings us to the question of enforcement. One mistake a lot of events make is adopting a code of conduct, but not creating sufficient mechanisms to enforce it. In some cases, where the behavior in question is endangering the physical safety of another attendee or breaking the law, the answer is obvious: event staff needs to immediately remove the perpetrator from the premises and call the cops if necessary. Often though, the answers aren’t always that clear-cut, and it’s important that your event staff or the person in charge of enforcing the code of conduct knows how to handle the situation. Ideally, you want to have multiple people who are empowered to handle code of conduct reports, and you need to have those people fully understand and appreciate the responsibility they have, as well as be folks who attendees can feel safe talking to and can trust to handle their reports with discretion.  Now a community code of conduct operates on most of the same principles as an event code of conduct. While an event code is largely designed to govern in-person interactions at a conference, meetup, or other event, a community code of conduct helps set the standards for conduct when it comes to the way we collaborate and communicate with others.  I believe a community code of conduct should be built around and reinforce the shared values of the community in question.  In my work with the Drupal Community Working Group, a lot of the issues that we deal with are not harassment issues, but conflicts between people who are really frustrated with one thing or another and end up lashing out at each other in negative and unproductive ways. In those cases, we usually find ourselves in less of an enforcement role and more of a mediator role. One of the core tenets of our community code of conduct that is we treat each other with respect, even when when we disagree, and often just reminding people of that can be enough to alleviate the situation. Sometimes however, you do end up with a situation that requires a greater level of intervention, and that’s where it’s really important to have a good conflict resolution policy and process. In the Drupal community, we encourage people to work things out between themselves whenever possible, asking for help from others as needed. We think this approach helps give people more control over the outcome of their dispute and is more likely to lead to a lasting resolution.  If that’s not possible though, folks can escalate to the Community Working Group, and we’ll do  what we can to help resolve the situation. We are very clear, though, that under no circumstances is bullying or harassment tolerated within our community, no matter how long you’ve been in the community or how many contributions you’ve made.  In addition to the resources we provide on the Drupal Community Working Group pages, another good place to check out is the Django project code of conduct, which has also been adopted by the jQuery Foundation and others. The Contributor Covenant and the Citizen Code of Conduct are also fantastic starting points for community codes of conduct that are used by a wide variety of projects and communities. There’s been a lot of discussion and debate about codes of conduct in various open source communities lately, and there’s been a lot of misinformation floating around out there. What I can tell you based on my experience is that no matter what kind of community you’re involved with, having a well-written and enforced code of conduct helps create a more level playing field for participation and an environment that helps encourage contribution and involvement that you would not get otherwise.  Thanks! AM: That’s the end of this week’s Secret Sauce. For more great tips or links to some resources regarding a code of conduct, please check out the transcription of this podcast on our website at Palantir.net. You can also follow us on twitter at Palantir. Have a great day!Resources: Ada Initiative Conference Code of Conduct:  http://confcodeofconduct.com/ Palantir.net Code of Conduct:  https://www.palantir.net/code-of-conduct Drupal Community Working Group: https://www.drupal.org/governance/community-working-group  Django Code of Conduct: https://www.djangoproject.com/conduct/  Contributor Covenant: http://contributor-covenant.org/  Citizen Code of Conduct: http://citizencodeofconduct.org/  Codes of Conduct 101 + FAQ http://www.ashedryden.com/blog/codes-of-conduct-101-faq

Larry "Crell" Garfield speaks at conferences a lot. And with all of these speaking engagements comes a vast amount of knowledge on what works and what doesn't. He shares his top tips and tricks to get the most out of delivering your presentations at conferences and camps – and to ensure your audience is completely engaged and sings your praises during and after.Transcript AM: Hi and welcome back to this week’s Secret Sauce, a short podcast by Palantir.net, that offers a quick tip on some small thing you can do to help your business run a little bit better.  I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Larry Garfield, who is sharing his thoughts on how to give a fantastic presentation at your next conference.  LG: Hi, this is Larry Garfield, Senior Architect and Community Lead with Palantir.net, and today I’m going to be talking about presenting at conferences.  I present at a lot of conferences. It’s part of what I do, [and] I enjoy it. It’s part of a service to the community, I think. I enjoy the teaching process, and I try to encourage other people to as well, because it’s a great opportunity for the presenter to learn. If you’re interested in presenting at a conference — whether it’s at a Drupal event, a PHP event, an industry event, doesn’t matter — there are a couple of guidelines to keep in mind when formulating a talk you want to give.  First and foremost, it needs to be a topic you care about. If you are bored with the topic, the audience will be bored with the topic too. No presenter can make a topic they are bored about interesting. So start with a topic that excites you, that you’re interested in talking about, that you’re interested in sharing knowledge about. The mindset you want to be in when presenting is, “I know this really cool thing. I understand this really cool concept, and I want you to share it with me.” I want the audience to get as excited as I am. That’s a good baseline for presenting. It helps if it’s something you’ve learned recently. That way it’s fresh in your mind, and just like writing documentation, you still understand the component pieces of it, you haven’t fully internalized whatever the topic is. I actually find it much more difficult to speak on topics where I’m an expert than topics where I’m an intermediate because once you fully internalize a subject, it’s harder to break it down and explain it to a novice. So something you’ve learned just recently can be very helpful. It can also be helpful to expect to learn as part of the talk. Good example here: one of my more popular presentations is on functional programming in PHP. When I first pitched that talk, I only had a slight idea of what I was talking about, to be perfectly honest! I had some understanding of the concepts, I had some understanding on how to apply them. But forcing myself to structure my own thoughts, forcing myself to look at it and say, “ok I get this, now how would I teach this to someone else?” really helped me to internalize a lot of the concepts that I cover in that talk.  Also bear in mind who your audience is going to be. Often times you can’t really predict that, but what audience do you want to have? Do you want to have a room full of developers? That’s fine. Do you want to have a room full of site owners and admins? That’s fine. Do you want to have a room full of business people? That’s fine. But think about who you want to be speaking to, and then target not just your presentation, but your description, your session submission, for that audience. That will help get the right people in the room. So now you’ve got a session that you know you want to do, you’ve got a topic you’re excited about, that you’re going to learn about . . . you know you’re going to learn in the process. Now how do we put together the presentation itself? There are a lot of different ways of doing that, a lot of different advice you’ll see. The most important, I find, is know upfront what narrative structure you want to have. Is that going to be a chronological story? It might be. Is it going to be just chapters, where essentially your entire presentation is four or five bullet points to expand on at length, That’s fine, I’ve given those. Are you going to build up to a point? That’s fine. None of these are wrong, but know which one you want to take. Are you going to make a point and then build on it to make a next point, and build on it to make a next point? Or are you going to just have, hey, here’s eight points [and] we’re going to go through them in order? One thing I do see some presenters do is the classic, “here’s what we’re going to talk about, now I’m talking about it, and here’s what we just talked about it.” I actually find in most cases that comes off more stilted than helpful. Certainly the concept of setting the stage for a presentation is helpful, and having a closure and conclusion is helpful. But making that so explicit and formal actually comes off very stilted and very clumsy.  One of the best examples here is having a framing story. I saw a presentation just recently where the presenter was talking about the process of debugging in code and started off with a story of this bug that he had in a system he was working on at one point that noone could figure it out, but it was a fun story. It got people engaged, it gave people something to think about it. Then he went through the process of debugging and tools for debugging and ways of thinking through a problem to figure out where the problem might be. And then he closed with, “and here’s what the actual bug was.” And it turned out to be one of those bugs that once you see it you’re like, “oh my god! How did we let that happen?” But people can relate to it! But it’s not just, “and here’s what we talked about.” Having a connection with the audience both at the beginning and at the end of the talk is crucially important. You want them to have a reason to listen. Hook them in early with your narrative structure and they’ll stay with you for the rest of the talk.  Good luck! AM: Thank you Larry. That’s the end of this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day.

In this episode, On the Air With Palantir host and Account Manager Allison Manley is joined by one of our magnificent engineers Joe Purcell. He gives a thorough yet entirely accessible definition of performance, why it matters, and what you can do to increase it. This episode is valuable for anyone in the midst of a web project, about to start a new project, and, of course, developers working on the web in any capacity. We'll be back next Tuesday with another episode of the Secret Sauce, but for now subscribe to all of our episodes over on iTunes.

Welcome to this week’s Secret Sauce, a short podcast by Palantir.net that offers a quick tip on some small thing you can do to help your business run a little bit better. Today’s advice comes from one of our colleagues at Pantheon. Steve Persch is an Agency and Community Engineer at Pantheon and former Palantir team member, and he’s sharing his thoughts on using the Panels module in Drupal.Transcript SP: Hi, I’m Steve Persch. Today I’m going to be talking about Panels Module in Drupal.  So I use Panels Module because I think of it as a really direct way of doing style guide driven development, which is a topic that’s getting discussed a lot in the Drupal community these days. Style guide driven development is the idea that development is directed by a style guide understanding of how a site is put together. What I mean by that is components like global headers, global footers, the styling of teasers, the styling of common article header elements is a really accessible way for clients, for stakeholders to conceptualize the visual understanding of a site.  So if you’re starting at that point with a style guide and you’re working in Drupal, it can be difficult to make Drupal match the markup that’s present in the style guide. A lot of Drupal developers like to complain about the CSS classes, the excessive wrapping divs that come from Drupal, and there’s this pain point of “how do we get Drupal to print the markup that we want.” At DrupalCon Los Angeles I did a presentation called Rendering HTML with Drupal: Past, Present and Future. Anyway, in that I described how in earlier versions of Drupal it was really common to just take whatever markup you get from Drupal and write CSS against that. It may have too many divs, too many classes . . . it doesn’t matter, just write CSS against it. As we move towards this world where where we’re doing more style guide driven development, we generally don’t want the markup that comes out of Drupal by default. Here’s where Panels Module comes in. Panels Module, I think, is a great mapping layer between Drupal’s internal understanding of elements like nodes, like headers and blocks, and that style guide understanding. So Panels has this concept called the Layout PlugIn. The Layout PlugIn is that mapping layer between a Drupal template file and the style guide design component. So you may have a Layout PlugIn called Global Header, and that’s your global header design component. You can then use that Global Header layout plugin at all these different layers of Panels. There are four main layers of Panels that I like to use. There’s the Mini-Panels Layer, which is analogous to core’s block system. A mini-panel is basically an individual block, so you make an individual block, and that’s your site header. You can look at that mini panel and you can see this uses the global header design component and that becomes a mapping layer between . . . all right, we had this understanding of a design component called a global header, and we had to plug in all this Drupal data like search forms, like menus . . . Panels is a user interface that lets you insert all of that Drupal data into a template that you can still think of as an independent design component. Doing that in traditional Drupal is really hard conceptually because in a more traditional Drupal build, the header might just be a conglomeration of things in the global template file, your page.tpl file. And it’s hard to keep track of where does this design component start and stop? Is there even a single representation of the header, or is it just a mix of menus that are thrown into the global template?  So with Mini-Panels you can encapsulate blocks. With the Panelizer level, you can encapsulate view modes. Panelier is essentially an alternative user interface on top of Core’s view modes. So in Drupal Core you have the ability to say, “this article teaser is going to display these fields in this order, drag and drop . . . cool. I’d still like to have that mapping layer too. Well, our style guide says article teasers are really illustrated list items, our style guide calls them illustrated list items. So we can map in Panelizer from the Drupal concept article teaser to the style guide concept illustrated list item. The next layer up is the Page Manager level. This is basically: what is this page? If you have a page that’s your taxonomy term listing page . . . you’ve got a vocabulary of musical genres . . . you’re going to have a page that is genres/jazz. What happens on that page? If you just have Drupal Core, that page is going to be nothing but a list of all nodes tagged in jazz. But your style guide says jazz needs to show this design component, it’s a complex design component. It shows the most popular albums in jazz, it shows these songs, it shows artists, it shows all these different things and we have a name for that component. At the Page Manager level you can map the Drupal concept of jazz page to the style guide concept of whatever is the name of that design component . . . maybe you call it genre landing page. So that’s our third layer, the “what is this page” layer. Finally there’s the global layer [Panels Everywhere], where you do things that in Core that you would otherwise do with the Core blocks system. We’ve got a global header, we’ve got a globar footer, maybe we have a global sidebar . . . panels everywhere lets you control that global template and use all the Panels UI niceness to line up your variables to say, “actually on this page we have no global header and footer whatsoever, we have just this one element. On this other page we have a variation that says we use a mini-header.” Panels Everywhere is a way of more deterministically saying how those variants shake out, whereas in Drupal Core all of your core blocks are responsible in and of themselves for figuring out, “do I show up on this page?” With Panels Everywhere you can say on a given URL, on a given pattern this is our global template, this is our global design component.  That’s why I like Panels. If you want to know more, check out the Palantir blog. I’ve basically given a summary here. There’s one blog post explaining Panels that runs down these four concepts, these four main modules, and then there’s another follow-up blog post called “Why I Use Panels” that digs a little deeper into the concept of mapping between Drupal data and a style guide or independent representation of design. AM: Thank you Steve. That’s the end of this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Enjoy your day.

Today’s Secret Sauce comes from one of our talented web designers Ashley Cyborski, who is a champion of designing in the browser. Not only is the method a major part of the design process here at Palantir.net, a deeper understanding of code and how it relates to design can allow web designers to push the limits of what their designs can – and probably should – do. We'll be back next Tuesday with another episode of the Secret Sauce and a new installment of our long-form interview podcast On the Air With Palantir next Thursday, but for now subscribe to all of our episodes over on iTunes.Transcript AM: Hi again everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick tip on some very small thing you can do to help your business be much more awesome. I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from one of our talented web designers Ashley Cyborski, who is going to champion the benefits of designing in the browser. AC: Hey everyone, My name is Ashley Cyborski and I’m a designer here at Palantir. A major part of our design process for projects is designing in the browser. At first, I was a bit reluctant to learn code. It sounds kind of intimidating, but doing so has made me happier with my designs and much more efficient in my work. Now, I’m a strong believer of working in the medium. As a web designer, it is important that we understand the medium and tools used to create our designs. Some people think that working in code will limit their creativity, but I’ve had the very opposite experience. Understanding the basics of CSS, HTML, and some JS [JavaScript] give me an understanding of what is possible. A deeper understanding allows me to push those limits and really flex my creativity on the web. I’ve written a post about this topic that you can find on our blog, but I want to go through a few of the reasons that I think designing in code is something that every web designer should at a minimum dabble in.  First, your designs will be more accurate, and more realistic. Have you ever comped up a design in Photoshop, only to have your developer push back and say “this is too hard to do” or “it’s impossible” or that you need to modify various pieces so that the designs will work? If you are the one writing the HTML and CSS, you will be able to implement these harder bits. Creative thinking, which we all practice, extends to code. I’ve found that I’m able to code out some interesting bits that have stumped my development team. When you are invested in the designs, you are invested in getting the details right. You don’t have to worry about passing it off to someone else who maybe has different priorities. Additionally, you can design with real content. Not that you can’t do that in Photoshop, but you don’t have to adjust the whole page when you change one little thing. There’s no need for random little boxes to measure the distance between list items or titles. Just type the value once and it remains consistent throughout your design. You can easily explore how various title lengths work, or how a news item looks with or without an image. And you don’t have to shift other things around on the page. They just shift on their own. You are able to realistically see how things adjust responsively. There is no need to create two or even three comps to show a tablet view or a mobile view. You can show it more realistically in the browser, how it shifts within a single comp.  The real highlight though is when a client comes back with feedback. You only have to make that change in one spot, rather than in two or three static comps. Secondly, all these little pieces give your clients a better understanding of the final design as well. Before, I often found that clients struggled to understand how a site might change as it adjusts to different viewports. But if you use code, they are seeing it as it actually is. The colors are rendering properly, as are the fonts. They can see how hover states work, and you can implement simple animations to show them things without having to provide a vague explanation that can be hard to understand.  Third, you will be more efficient once you master the code. Initially, it may slow you down a bit because you are learning, but once you get a basic understanding, you can create one comp that communicates responsive design, you can implement changes without having the page break apart. and you can set up basic styles that you can reuse consistently, and adjust in one spot.  These are all things with basic HTML and CSS that will increase your efficiency. But once you have mastered those, you can begin to add more tools such as a templating systems or things like sass, compass, postcss, or gulp that will increase your efficiency and improve your workflow. Designing in the browser doesn’t just increase your efficiency, but it increases your team’s efficiency as well. You are shortening and combining two steps of the process. Not only are you not creating as many static comps, but you are shortening the process of translating those comps into code. And since you are the ones implementing the design, it shortens the design QA process. This leads to the fourth benefit to designing in the browser, you can communicate better with your developer. Since you are implementing behaviors in your code, you don’t have to describe an interaction or animation, because you already made it. By writing the code, you have left little room for interpretation, so there will be less translation error between the design and development phases. You can add additional comments in your code that your developers can follow. You and your developers are now speaking the same language. There is no need for an interpreter which can ultimately lead to better cross team collaboration throughout the entirety of the project. You’ve already heard from Carl [Martens] in a previous podcast about design systems, and designing in the browser helps to maintain and truly utilize the benefits of a design system during the process. The fifth benefit is the ability to create reusable code. This code can be as small as a single class, or as large as an entire component. You can reuse existing components to craft them into additional, new components that maintain the base styles of your system. All of these benefits come together to make you more efficient, but the real benefit is to your clients. I spoke about how they are viewing their designs in code, as they will ultimately end up, giving them better understanding of the process and their final product. But your efficiency saves them time, which translates to either a smaller budget, or more features in their final site. So how does designing in the browser fit into your process? For me, I usually start with some design discovery and exploration, maybe create some wireframes, and static comps using my tool of choice. Only from there do I move into the browser. I’ve found that you need to get some initial buy-in before you get into the code. My static comps tend to be desktop comps, and when I code them, I begin to make them responsive. As a team, we have improved the process by including a living styleguide with our prototypes. We break each page out into its components and document these along with their elements. This is a tool for our clients after we hand over the site, and for our developers as they implement the site into additional templates. Learning to design in code can greatly improve your process and final product. So where should you get started? There are many resources online, from instructional posts and videos, to tutorials. I’ve found the best way to learn is to get your hands dirty. Take one of your existing designs and attempt to recreate it using HTML and CSS. All you really need to get started is some type of text editor. I use Sublime Text. Create one document for your HTML, name it index.html. Add a doctype to the top and a head tag and body tag. You can check online to find how to do that. Create another doc named styles.css. Use a link tag to connect the two together, and drag the index.html file into your browser. Within the body tag, write something simple like, “hello world.” You should see it in your browser. Within the body section, you can start to write your HTML, and on your styles.css page, you can begin to write your styles. You can style an element with a class or just style the element itself. Just get the initial coding bit out of the way first, and worry about best practices later. I can’t really describe that feeling of accomplishment when you’ve been working to code something and you finally get it to look right in the browser. It is really awesome! I really think that learning the basics of designing in code can help to improve your process and increase your efficiency. Your clients will really appreciate it as well. I hope I’ve encouraged you to give it a chance! Thanks. AM: Thank you Ashley, and thank you all for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day!

Our Director of Professional Services Ken Rickard joins the Secret Sauce podcast today to tell us a little more about our consulting services.While we take on epic, end-to-end projects often, we also find that some clients don't need the long-term services. Instead, they need strategic help with a specific challenge, or perhaps require staff augmentation – in particular with Drupal projects – for a limited time.What works and what doesn't with such engagements? We always structure consulting engagements to ensure the work we perform adds the most value to your team and organization, based on a frequency (often weekly) that ensures your goals are being met.Need a helping hand? Let's schedule a time to talk.TRANSCRIPTAM: Hi, welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Ken Rickard, our Director of Professional Services, who is going to give a quick plug about our consulting services.KR: Hi, I’m Ken Rickard. I’m the Director of Professional Services here at Palantir. Today we’re  going to talk a little bit about our consulting services. As you may know, we’re a full-service web strategy design and development firm, but we also do smaller engagements where some of our clients need strategic consulting to supplement the staff that they already have. In particular with Drupal projects, what we find in a lot of cases is clients that have existing staff who are very talented and very skilled, but don’t have a lot of direct Drupal experience. What we can do in that case is rather than do a big bundle of upfront training, what we put together is a consulting package, where you get to work with one of our experts during the life of your entire project. And it’s a very simple arrangement in which we spend a few days getting to know each other, getting the project plan together, and in particular structuring the build of the project so that you don’t have to learn all the parts of Dupal first. So we can start with some content modeling, then you move on to building out content types. Then you start layering in Views and Panels, and all the other things that make a site functional and exciting.During this whole engagement, instead of contracting us or someone else to go out and build it, your staff is doing the work. And what we’re doing is having an expert guide you through that. So we do this with check-in meetings. We set these up as two simple meetings a week. Generally on Monday . . . first thing Monday morning we get together, we meet for about a half hour and review  what are your goals for the week: are you trying to build out Events? Are you trying to build out Single Sign On integration with an LDAP service (which is a very typical thing for our university clients)?As consultants, we walk through the problems and the challenges you’re trying to solve that week. We point out opportunities that you might have overlooked, we point out solutions that might already exist in the marketplace, and we look to the pitfalls that you might run into, such as, “if you try to do it this way you may run into this problem.” Or,  “if you use this module, it may prevent you from doing this other feature that you’d like.”That helps you plan out your week. It also lets us ask, “is there anything we need to do to supplement you this week? Do you need any additional research done? Do you need us to review any specifications?” or things like that.Then we meet later in the week, on a Thursday or a Friday for about an hour, and review the work you’ve completed. It’s peer review. It’s the chance to walk through and see, “did it function the way you expected? Did you run into any unexpected bugs? If so, how do we troubleshoot those?” Because what we find the value to this consultation is . . . I would say 90% of the time your team is going to get it right. They’re going to have the right answer. But there are two things: number one, they may not know that they have the right answer, and that’s really discouraging. It puts the project at risk and it puts the team in a very bad position because they are just uncertain. It’s very hard to move forward confidently when you are uncertain, so we can come in and help provide that level of certainty. The second piece is in the 10% of cases where they don’t get it right the first time, it’s generally because they’ve either misunderstood a fundamental concept that’s not well-documented or is peculiar to Drupal, or because they’ve run into a very deep structural bug that needs expert analysis. So we’ve done several of these engagements with small clients and with large clients, and they are very very effective capacity builders. The other thing that they give you is a safety net, because if it does turn out that the project is bigger than your team can handle, we have someone positioned to step in and say, “ok, here’s what you’re going to need to complete this project,” and we can then ramp up a team to assist.We’ve had great success with this approach with a variety of clients, and we’d love to work with you on it. Thank you.AM: Thanks for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. 

This time we're joined by Palantir.net Engineer Kelsey Betham who tells us all about exporting features in drupal, including why and when you should, and how doing so could be a huge benefit should something go horribly wrong with your site. The full transcript of the episode is below.We'll be back next week with another episode of the Secret Sauce hosted by Account Manager Allison Manley, but for now subscribe to all of our episodes – including our monthly long-form interview series called On the Air With Palantir – over on iTunes.TranscriptAM: Hello and welcome to The Secret Sauce, brought to you by Palantir.net. This is a super short podcast, just a few minutes every week, that offers a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Kelsey Betham, one of our fantastic engineers, who is going to talk about exporting your features in drupal.KB: Hi. I’m Kelsey Bentham and I’m going to tell you about why should should export all of your features. This seems like the sort of thing you don’t need to do after you launch your site. But you’d be wrong, because at some point or another someone else is going to have to set up your site. Whether it’s because they are fixing a bug, or they are learning how it works, they’ll need to know what’s going on. And if you don’t keep your features up to date and exported, the only place that information will exist will be in your database. And there’s a chance that something, somewhere, will go horribly wrong, and you want to have it backed up in as many ways as you can manage. And you can backup your features by going in through the Drupal Admin interface. You can log in with a user that has the appropriate permissions to update your features. Go to the “Configuration” menu on your Drupal site and go to “Features.” Here you will find a helpful list of all of your features and their current status: whether they be up to date with your database, or in some way different. If you have the Diff Module installed you can also check to see exactly how the code differs from the database. You’ll want to check on this to see exactly what’s changed and be able to verify that all the changes that have been made are changes that you actually want to keep. Once you verify that all the changes you have are ones that you should have, you can go and click on the “Recreate the Feature” button. This will allow you to export the feature to exactly where it is, but updated with all your current configurations.Doing this sort of thing will help in the long run because it makes it much much easier to ramp people up on projects, as well as keeping anyone outside of the immediate project team aware of exactly how things are working at any given time. Thank you very much for listening, and I hope that you keep all of your features updated in the future!AM: Thanks for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day! 

Giving feedback on how someone works isn't always easy, especially when it comes to your colleagues. Nor is it easy to receive it. But this act is very important for a number of reasons when done tactfully and constructively.Our Director of Operations Colleen Carroll talks about what works and what doesn't when both giving and receiving such feedback – not to mention the filters to consider when doing so – and the positive impact cultivating a culture of feedback can have for your internal teams. After all, it comes from the desire to improve something. How could your organization benefit from such a culture?Look for this interview-style format monthly on the second Thursday of the month, with accompanying short form installments that provide tips, resources, and other quick information via our Secret Sauce podcast every Tuesday.Want to learn more about how we cultivate a culture of feedback at Palantir.net? We're all about sharing.And do you like what you hear, and are you a client or partner of Palantir interested in being on the podcast? Let us know!

Wouldn't it be nice to have a butler on hand to help streamline things? Well, in this case we're not talking about a person who comes and waits on you, but rather an impressive and integral front-end development tool developed internally at Palantir.net to help automate some of our work.Butler does a lot of things and has plenty of features, which our Front-End Developer Lauren Byrwa talks about in this week's short-form podcast called The Secret Sauce. Things like:Gulp integrationCompiles your Sass and rebuilds your prototypeMoves your prototype into Drupal 7 or Drupal 8Refreshes your browser so you can see updates simultaneously in multiple placesPlenty of optimization options, too, so you know where exactly the performance issues are coming fromThanks for listening, and look for our long-form podcast On the Air With Palantir this Thursday!

Account Manager Allison Manley lets Senior Designer Carl Martens take the lead this week, as he explains the importance of thinking about Web sites in terms of design systems rather than pages, and goes on to talk about the benefits produced by taking this approach. We've seen design system thinking make a huge impact for our clients time and again because it creates a truly modular, extensible system onto which they can build for years to come as their organization's needs and goals evolve.We'll be back next week with another episode of the Secret Sauce, but for now subscribe to all of our episodes – including our long-form interview series called On the Air With Palantir – over on iTunes.

In this installment of the Secret Sauce, Project Manager Tom Jones discusses the helpful exercise known as Like, Wish, Wonder. It can help your team overcome groupthink and stay engaged during a project kickoff.So grab a post-it note and marker, and start answering some important questions: what do you like about your current site, product, workflow, etc? What do you wish it could do? And then what do you wonder about it? The wonder is more challenging, and looks toward future goals. Take a listen, let it sink in, and consider it for your next kickoff.We'll be back next week with another episode of the Secret Sauce, but for now subscribe to all of our episodes – including our long-form interview series called On the Air With Palantir – over on iTunes.

This is the first in our weekly bonus podcast that deals with shorter tips and resources that will help you with some straightforward facet of your web project. It's a compliment to our monthly, long-form podcast On the Air With Palantir.That's why we call it the Secret Sauce.Some episodes will focus on strategy, design, metrics, or other such topics, while others will be more technical in nature. Whatever the focus, we want these to be useful for you, so we draw from our real world experience.This time around Allison Manley lets Larry Garfield take the mic to talk about Drupal 8, how you can prepare for it properly, and how the changes in this new version push us toward a content strategy approach. While applicable to anyone considering Drupal 8, this particular episode is mostly technical in nature and geared more toward site builders and developers.Look for the Secret Sauce bonus podcast released weekly on Tuesdays.

We're very excited to kick-off our new podcast called On the Air with Palantir, and welcome you to listen to our first episode with Andy Gradel and Christine Fagan from Main Line Health System (new site not yet launched).In this episode, our resident podcast veteran Allison Manley discusses the project, the importance of analytics data and developing a sound strategy, user-tested decisions, design, platform challenges, and much more with our stellar client stakeholders.Look for this interview-style format monthly on the second Thursday of the month, with accompanying short form installments that provide tips, resources, and other quick information via our Secret Sauce podcast every Tuesday. We'll update our iTunes link above once it goes live there.Want to learn more about our services, and how we drive success through strategy and design for our clients? We're ready to help.And do you like what you hear, and are you a client or partner of Palantir interested in being on the podcast? Let us know!