On the Air With Palantir, Ep. 08: Los Drupaleros

September 8, 2017

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.

00:0000:00

On The Air With Palantir, Ep. 7: Getting Started in Drupal

January 9, 2017

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.

00:0000:00

The Secret Sauce, Ep. 35: ‘Twas The Night Before Moving

December 20, 2016

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!

00:0000:00

The Secret Sauce, Ep. 34: Remote Teams

October 17, 2016

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!

00:0000:00

The Secret Sauce, Ep. 33: Collaboration Tools

October 11, 2016

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!

00:0000:00

The Secret Sauce, Ep. 32: Documentation and Training

September 20, 2016

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!

00:0000:00

The Secret Sauce, Ep. 31: Understanding Your Company’s Purpose

September 13, 2016

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.

00:0000:00

The Secret Sauce, Ep. 30: The State of Workbench in Drupal 8

September 6, 2016

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!


00:0000:00

The Secret Sauce, Ep. 29: Benefits of an Iterative Design Feedback Process

August 30, 2016

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!

00:0000:00

The Secret Sauce, Ep. 28: Project Stewardship and Understanding KPIs

August 23, 2016

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!

00:0000:00