Each and every Friday our AIMCLEARians host a discussion about what’s on our minds, what we are hearing in the industry, and more. In this Fireside Chat we are digging into tools, APIs, and apps that empower marketers to apply quick solutions without requiring a lot of IT heavy lifting. But in the absence of IT oversight, these marketing MacGyvers can unwittingly open up security holes putting company and customer data at risk.
Join AIMCLEAR‘s VP of Product Innovation Michelle Robbins and our Systems Administrator and IT Lead Alyssa Friesen as they cover best practices for Martech adoption. We’ll share lessons learned in the trenches and how organizations can be both agile and secure. And here we go!
Read Our Friday Fireside Chat
Michelle: Hello and thanks for taking your time on Friday afternoon to join us for AIMCLEAR‘s fireside chat. I’m Michelle Robbins and I’m joined today by our systems administrator and IT lead, Alyssa Friesen. I’m AIMCLEAR‘s VP of Product Innovation, leading marketing technology and data strategies.
We appreciate your time and hope wherever you are and wherever you’re joining us from, you’re staying safe and healthy. Today, we’re going to have a pretty casual conversation about the challenges companies, and specifically the IT departments, have in controlling and securing platforms, data, and apps in organizations of really every size, whether you’re a small business or a much larger organization.
So, let’s kick it off. What are MarTech MacGyvers? What do we mean when we talk about MarTech MacGyvers, right? I use this phrase generally to describe anyone in an organization that needs a solution to a problem. Being a self-starter, they’ll seek out that solution independent of consulting with the Dev or IT teams.
Now, I don’t know if everyone saw Scott Brinker’s latest uptake to the MarTech landscape. He released it a couple of days ago. Might’ve been yesterday, in fact. He now lists about 8,000 technology solutions from large scale platforms to software that essentially operate as an API hub, down to browser extensions. So there’s really a solution or combinations of solutions, for any problem out there that you can imagine.
Now, what we want to talk about today are the pitfalls and problems that you want to avoid and how getting everyone on the same page with MarTech governance is the key to doing that.
So, let’s kick it off, Alyssa, with talking about the importance of a structured MarTech onboarding process. You were one of the first colleagues I interacted with at AIMCLEAR, and you’ve got a really well-defined onboarding process. Talk a little bit about how that helps and how it helps especially get in front of MarTech MacGyver type situations.
Alyssa: An onboarding process is – a lot of times you’ll have one set up, like HR will have one set up or the team that they’re working on, not just to say, “Here’s our handbook and here’s how we work as a team.” But having an IT onboarding checklist is really important, both in terms of making sure that they’re set up correctly and know how to use everything. Also as an introduction. It’s really important that they’re not scared to come to IT thinking, “Oh, this is a dumb question.” Or, “This is something that they’ve talked about before…” I really view it as both because I could easily send somebody the link to our Wiki and say, “Here’s all the information that you’ll need for working here.”
But the onboarding process really adds that familiarity and then lets them know that you’re there to help them with questions. In terms of MarTech, the onboarding is definitely important because people need to know, for one, what tools you have. That’s one of the issues that you see in a lot of the roll-your-own solutions is that somebody is like, “Oh, well, I decided to put all of these pictures on imgur because I didn’t know where else to store them.” During the onboarding process we would’ve said, “Hey, we use box for all of our file storage, and you can have public pictures and stuff.” It’s important knowing that all of those are options.
Same goes for having people running their own types of chats, having a messaging thing, or even using their own personal Gmail to message people and instead saying, “Hey, we have a corporate Google chat that we use.”
A lot of those onboarding processes are key in showing them that they exist and also how to use them. Personally, I will physically show people how to use our systems, and then also give them documentation. Your first day is always really hectic and you get 15 programs thrown at you. There’s no way I expect somebody to remember all of those for the rest of the time they’re working there.
Michelle: Yeah. Talk a little bit about the Wiki that you developed because I think that is something that’s key as well. People don’t think a lot about process and process documentation and how important that can be, not just for getting a handle as a new employee or new person in the organization on how things operate and where things live, but in understanding it helps establish institutional knowledge. So that everyone that, let’s say that you decided to take a two-week vacation to France or something, right? And you were out. We need to have a place to go where everyone knows, “Okay, if you have a question, Alyssa’s not here, we have all this documentation. All of the processes are here.” Talk about that and talk about your creation of that.
Alyssa: That’s something I had started working on a while ago. A year or so ago, some point after I came back from maternity leave. I came back and I was like, “Well, what is this? What is this system doing here?” And the team said, “Well, we didn’t know what to do.” So, that was a little bit on me. But documentation is definitely important to a business of any size, right? If you were a one man shop even, you’re going to want documentation so that if you bring somebody on, you’re not sitting there trying to scramble and remember how you do everything.
To build the Wiki, what I started doing is every time I trained somebody, or we got a new system, I would take screenshots and have instructions so that people know how to use it. The Wiki is great because it’s…  we use it.
It’s a Google site, so it’s free within using our G suite; I don’t have to pay for a domain. I don’t need to worry about other people outside of AIMCLEAR seeing it, because within G suite you can set permissions to ‘people with email addresses in this domain.’ It’s been really important and really great. I think it helps a lot of people, especially in the past couple of years as we’ve added more remote people where they can’t turn their head and yell at me across the room.
Michelle: Yeah. I was going to ask if there was a different process with onboarding remote employees versus a local employee, or if you basically have the same process regardless.
Alyssa: It’s generally the same process, where we would have the remote employee come into the Duluth office so that I can be with them and show them everything. I guess there’s actually, there’s some fewer things that they need to know about, just in terms of how to use our printer in the office or the doorbell.
Michelle: What I found really helpful about having a Wiki, and this was something that we had at a prior organization that I worked as well, is that not just for having one place for institutional knowledge, but every department can add their own systems and processes in that structure and then it becomes searchable.
It should really be everyone’s first stop for, “I need a solution.” Maybe we already have this, maybe another department is using something similar, that kind of thing. So having a place where employees can go and understand the totality of what an organization is doing with their MarTech is really, really critical.
And when we talk about that, the suite of MarTech or the MarTech stacks that get built within organizations, the really, really important part of that is, vetting, right? Vetting the tools and services and apps. A lot of people might think, “What’s the big deal? I’m not bothering IT or dev and I can solve the problem myself. It’s a small little tool or a small little app” They have really good intentions, but they’re not thinking about the potential for harm. If you could talk a little bit about the importance of properly vetting third party tools, services, and apps, and why folks really need to work with their IT staff on this.
Alyssa: Yeah, definitely. That’s one thing that a lot of people, either in a personal capacity or when they’re adding things at work, that they don’t think about. They think, “Oh, this is a public application or something. It’s gotta be safe. It’s on the internet, but I’ve heard of this brand or something.” But, in reality that really doesn’t mean anything. And, something can be safe for personal use, but not good for business use.
An example that I have is that you need to make sure, how much of your stuff is being public. When we started getting our MarTech team on to GitHub, I probably should have of done a little bit more for research and training on the default project settings and stuff. It wasn’t until I was sitting at the Google Next conference, that I had stumbled upon something. It was a link to a gif that they used as their user profile and I ended up finding that a lot of their repositories were public. I was like, “Oh God, there’s a client ID in here.” And that doesn’t necessarily mean something to anybody, but if somebody knows what to look for, it can be big, and be dangerous.
Michelle: Â Yeah. I definitely want to talk about data security overall and how people rolling up their own solutions to things are not working really tightly with the dev and IT teams.
You can have problems like that. And, it’s interesting because no one’s going to adopt a massive platform, right? No one’s going to go, “We don’t use Salesforce. I think we should use Salesforce. Let’s deploy Salesforce” That’s something that’s going to involve a lot of stakeholders and a lot of different people because it is a massive platform and there’s a much bigger investment to be made.
But people don’t really think twice about things like browser extensions or WordPress plugins even, right? In the 12 years that I ran technology for a media company we only had two problems: One of our flagship publishing sites, and both of them were the results of nontechnical staff using, one was a browser extension and one was a WordPress plugin that did some very bad things inside a database and almost brought the site down.
And I caught it pretty quickly. But that resulted in much stricter policies around permissions and who had access to what. And, that’s a tough line because marketing is more technical these days by nature, and a lot of the people doing marketing are more technical than maybe would have been in the past. And so, they make assumptions about their level of technical expertise and they’re thinking about utility. “Does this work for me? Does it solve my problem?” They’re not going to think about the teams that an IT staff or developer would think about. And that’s why you really need to work with those people because they’re going to think about those questions and they’re going to understand the implications of any different thing you’re thinking of using.
So, work with your IT teams. This is the big takeaway here. When talking about people rolling up different solutions and the fact that there are so many solutions out there right now when we look at redundancy and cost containment with respect to MarTech.
We’re talking about any organization that can be anywhere from five to 10 to 20 people and imagine all of those people rolling their own, right? Using this tool, that tool, this tool, that tool. What kind of problems does this open up?
Alyssa: Having all those free and paid tools and digital subscriptions, one of the problems is that when people are rolling their own, you’ll find out that you’ll have four people paying for the same tool. It’s not like a one user tool so, there’s money that people are often losing because we’ve got two instances of PythonAnywhere and we could have one account with two logins. It’s the exact same price and we can drop this. You don’t want to be redundant in what you’re paying for.
You want to be really careful about your data redundancy. You don’t want to have copies of anything important, confidential, or private somewhere that you don’t know or can’t access.
We have a password management system. I can’t have somebody saving that to their own password management system because then if they leave, if that client leaves, or if there’s a breach, I need to know who has access to our information and how to remove access from them. That gets really difficult because you can’t really police everybody. I’m not staring at everybody’s screen all day long. That sounds mostly really boring. So yeah, that’s the big issue, not knowing. Especially with things like GDPR coming up, you have to be extremely careful with where your data is located for current clients, current projects, and current employees.
Michelle: Yeah, it gets really difficult. If everyone’s not essentially standardized on the same tools, and that can be hard because especially as you have people coming from companies who use one specific tool, or there’s one tool they really like, and it works really well for them, it’s really hard to move people off of something they’ve always worked with and onto something new.
Even when you’re talking about, internally. We use a specific project management tool. If we suddenly were to decide we’re going to use a different tool I think we’d probably see some people going, “But wait, wait, wait, wait.” You know, because everyone’s comfortable and understands and knows how to work within this thing.
So, it’s really natural, I think, that people want to bring the tools they’re used to with them into an organization or into even working with clients or things like that. But there are so many reasons not to that. My approach, in all of the roles that I’ve been in, I’ve always worked cross-functionally, and I’ve always worked with multiple departments and people would come to me and usually say, “Oh, I want to try out this platform, or can we deploy this tool?” Or otherwise get distracted by new shiny things that are out there in the industry or that people are talking about as being, “Oh, this thing’s great. You gotta try it.” And I would always ask the person, “What problem are you trying to solve? Don’t tell me about the tool, tell me about the problem.” Because understanding what they need from the tool really helps you understand how you can analyze your existing MarTech stack and your existing suite of tools. Because very often, I found people didn’t realize we already had a solution for that.
It’s like, “Oh, we have that and it’s part of this platform,” and they never realized it. On average, I think, I found that, especially when you talk about big platforms, any kind of big, piece of technology that has multiple components or multiple feature sets. I found that people use about 20% of a platform and it’s the key 20% that they need.
So that’s what they live in, and that’s what they use every day. They never think, “What else can this do? And can this also solve this problem?” And more importantly how does this piece tie into the other pieces that we’re using, that everyone’s using so that everyone can be on the same page about things and getting communication across departments.
All of this really is related to how you roll out a Martech stack. And this is something that actually our CTO, Joe Warner, and I are gonna be talking about on our May 8th Fireside Chat. We’re gonna get into building MarTech stack and how to avoid a lot of the things that we’re talking about when you’re looking at the build process.
Something else you touched on was understanding the data. You know, data security and how, beyond expense, things that can result from having a Frankenstack. And having solutions getting rolled out in every different direction. Threats to company and client data. I discovered a similar problem that you mentioned, where not understanding where all the data lives, where we had an editor who was using a database completely outside of all of all of our systems. It was actually pretty significant portion of workflow. It was something that we literally stumbled upon and we’re like, “Oh, if anything can happen to you or if you had left, all of this, pretty significant piece would be gone.” So, we worked with how we could integrate that. Did we already have a solution for that? And again, I think communication is super important. What other tips do you have, with respect to getting everybody sort of on the same page?
Alyssa: That’s difficult sometimes because, you can have all the tools, wikis, rules, and stuff in the world, and you’re still going to find an employee that’s like, “Nope, I’m going to save all my passwords in this spreadsheet.” It’s like, “No, you can’t do that.”
But I think part of that is really having people understanding how things can be compromised. And that, yes, you have a password on here and it’s 37 characters, but that doesn’t make it immune to somebody else getting in.
One of the things that I add on every, every single system that allows it is multifactor authentication. That really cuts down on social engineering attacks, phishing, and a lot of other man-in-the-middle browser attacks. That really helps with those and that’s one of the security pillars that I’m focusing on.
Also, I like to educate our users about things that happen. They might not always care, but when a system has a breach, I let people know and I say, “Hey, this system had a breach. Our emails were not affected, but a client might’ve been.” Or we can say, “Hey, there was a breach here, but it only affected users that didn’t have this particular security policy in place, which we have.” I think that really helps to show our employees the things I’m doing. They probably do slow down your own processes and stuff, but there’s a good reason for it. Here’s an example of the time that they worked. It’s not saying, “Here’s this rock, it keeps away bears. Look at it, there’s no bears.”
Michelle: So, we have a question from Steve Walther who’s joined us. It’s asking if we can talk about the difference between how in-house and external client files are managed.
Alyssa: Okay. I would actually say for us in-house marketing and other tools and external clients, they’re generally the same because we really want the same kind of security on our own files and processes as we do on our clients.
The the main difference would be that employees have access to almost all of the in-house things versus client files are by team. An example, I am not a web developer, but I would have client access to some of our web development files. Not necessarily passwords. That actually is partially because we like to allow people to explore. Be inter-departmental about their work. But the client files are available if you’re on this team.
I really abide as much as I can by the least knowledge, not least amount of most privilege. Where, if you’re on this project, you can have access to it or if you’re on this sub-project of this client, that’s what you get access to. And that really helps in how we manage them. I don’t know if that entirely answers you.
Michelle: I think he might also be wondering specific technology wise because there were times where we need to share across their internal system with our internal system. Right? And we use Box, they might use Dropbox or they might use Google drive. How do you find the best way to manage that?
Alyssa: That ends up getting a little tricky. Especially because some systems mesh together really well and some are way out there. It ends up having to be a client by client basis. What works for us, if we have a lot of files that need to go back and forth, ideally we add them to our systems. Because then I can manage them and make sure that the correct people have access to it. Otherwise, we will occasionally have to roll up an instance of Dropbox. If that’s what a client ends up liking, maybe that’s the only thing they know and they really strongly prefer it. Then for that, we might temporarily have an extra system for a specific client. I’m not gonna force my ways on all the clients, just all of the employees.
Michelle: Okay. We have a question from an unknown AIMCLEARian who is wondering how to win IT points. So, talk about IT points first and give some context and then get some tips, cause we’d all love them
Alyssa: IT points are something I randomly started in quarantine where I’m giving people IT points for things. I’m not going to tell you all the ways that you get them, but some of the ways are when people- instead of asking me for something… I get questions like, “Oh, who’s in this group email?” And then they realize, “Oh, Hey, there’s a whole spreadsheet that tells you that.” I’m just putting it out there, guys. FYI.
Michelle: That spreadsheet, is it in box, basecamp, or drive?
Alyssa: Oh, it’s in drive. It’s linked in the Wiki. So, I’m trying to help incentivize people. I had somebody ask me a question, “Hey, a client needed us to make an account for this. What should I do with that?” And I was really happy. That’s how Tim got some points because I really needed somebody else to not create the client account. This was within Bing and you cannot transfer the account. It’s just not possible.
Michelle: I think it’s great. I think that the culture at AIMCLEAR is so open. I love that you have a point system. I love that you’re open to everyone coming to you and asking you questions and working with you.
Because all the problems that we’re talking about really are more problematic. And, more than anything, they’re communication problems. With people either not feeling that they’re going to get the kind of service that they need as quick as they need it. If they need some particular solution, they might want it when they want it and don’t want to wait for it to be vetted. Don’t want to wait to see if it can work and can integrate and everything. And I think that the better communication structure you have in an organization, the less of that you’re going to see. With everybody feeling open to discussing things and working on a problem together and being open to other people’s input because it’s entirely possible that we’ve rolled out a piece of MarTech that we love and we think is great.
Something that I’ve also seen organizations struggle with is that there are platforms that were 100% designed for engineers by engineers without thinking about how a normal person is going to use this. And so, the engineering team might love it because we understand it and it’s, “Oh, super easy. That works like this.” But you put it in front of someone who’s not technical and it’s, “This is a mess and it makes no sense.” That means we need to go back to the drawing board and maybe not inject our own bias into tool selection and find something that works for the people that need to use it. Because nine times out of 10 we’re not the ones using it. They are. So, I think that’s really important as well.
Alyssa: Yeah, definitely. I’ve for sure had times that I’ve looked into a tool and I’ve thought, “Hey, this is really intuitive. This is really simple.” And then I’ve put in front of somebody and I was like, “Wait, shoot. This is really intuitive for me. It’s not necessarily to somebody else that isn’t in all these tools all day.”
Michelle: So, at this point, I’m wondering, we talked about managing MarTech MacGyvers. Is it any different now that we find ourselves in the situation where a large majority of workers, and especially those that are fortunate enough to be able to work from home, have become remote? Are there any special process changes that need to be considered or are top of mind for you?
Alyssa: Yeah, luckily, because AIMCLEAR has a few remote employees anyway. I’ve been working over the past two years to get our VPN system up to par.
So we’re lucky that we have good systems and processes and documentation in place so that working from home really didn’t make a big business difference for us, aside from, you know, having children in the background or dogs and things like that. But, yeah, I know a lot of other businesses have definitely struggled with that because they’re an office that everybody’s got a desktop and that’s the only way that they can get at, or they’ve only got network access storage.
I know I read an article that the ports that is used for RDP, which is the remote desktop protocol, so that they can remotely access things like servers and other computers. That port saw, a huge percent increase in being in being found open on the internet, which is really dangerous because you can’t have that port open. I’m sure a lot of, a lot of people regretted that.
The challenges for, and unfortunately a lot of those challenges to really negate those need to be started before you suddenly have to work from home. It’s going to be really hard for a company right now to buy a VPN system and get it installed and remotely train all of your employees to use it. But, it’s the only option for some people. Otherwise, this is actually, again, having that documentation and having it available for everybody because if somebody is used to always turning around in their chair and asking somebody else a question, which is great and that works for me too, but if they need to look something up or they…Or they’re maybe having trouble with their chat system, something like that. It’s good to have other places that they can find that information.
Also, I think one of the big things with the working from home is having users really feel comfortable asking for help and asking questions. I’ve often gotten emails or chats saying, “Hey, this is a dumb question,” or “Sorry for bothering you.” It’s like, “No, it’s okay. I want you to ask what you think is a dumb question or bother me instead of, spinning up a new Google cloud project and taking a whack at it.” I would take a hundred dumb questions over somebody doing something themselves and making a big mess afterwards.
Michelle: Always better to ask questions first. Well, this has been a great chat, Alyssa. I hope folks have learned a few things. Why don’t you wrap us up with some of your top tips before we head off stream?
Alyssa: Some of the takeaways are… One of the big things moving forward is to have an onboarding process. It doesn’t matter if you’re a small two- or three-person company or you’re a larger organization. It’s really important both in terms of getting people to know what your tech stack is, how to use it, and how to access information about how to use it. As well as making yourself seem a little bit more personable and you’re not the IT person in the basement that is going to snarl at you when they ask for a password change. I think all those things are really important for having an onboarding process. It also helps you get reacquainted with what you have and how to use it.
Another one is to empower your employees but set limits. I do allow people to install some browser plugins, but then I have a system… If you use Chrome and you use G suite, it can tell me what browser plugin somebody has installed. So, I’m giving people a little bit of leeway and stuff because it’s not really feasible to go and whitelist everything that you want to allow and then block all the other things. Giving that to people so they don’t feel like they’re locked in and there’s no change. And empowering them to also come to you and not just sit there wondering what they’re going to do with themselves.
Then along that with the browser plugins, monitoring people without invading them. We have a remote desktop system that I can remotely help somebody with. But, as I tell them on the onboarding process, I will never log into their computer without telling them first or without them knowing. Same for if we need to access something in their email. I always to tell people that, “Hey, we’re looking for this, I’m looking for this file and I’m gonna end up searching some of these things.” I think that’s an important thing and that helps figure out what your MarTech stack is and monitoring it.
Vetting new tools is always really important, obviously. Seeing what they access and what they request. When you connect something to Facebook, it will tell you, “Hey, this is going to access your profile name and the names of your friends and your likes.” A similar thing is available for a lot of tools. When you connect something with G suite, it tells you what it’s adding. Those are the ones that are definitely important to vet.
Auditing existing tools and extensions, because sometimes… Programs and applications should in theory tell you when they are accessing something extra or changing what they’re accessing or how they’re doing it. But, the fact is that they don’t always, especially if you have little third-party tools that aren’t a professional organization and they don’t necessarily know what all of the rules are for that. Auditing the existing ones helps because sometimes there’s new features that will let you remove other things in your stack and be more integrated and possibly cheaper.
Having clear documentation as we discussed. It’s good for your employees because they can access information that they need whenever they need to. But it’s also good for yourself as the IT team because then I don’t have to worry about if I am gone for four days, is nobody going to be able to do anything. Sure, they might have to be reminded that the Wiki exists and it has a search function, but that’s not something that gonna keep me from enjoying a vacation. There’s enough information there that the company is not going to come to a standstill, and that’s really important as a business owner too. You need to follow the hit by a bus rule where, “okay, if this person gets hit by a bus, will we be able to replace them?” And obviously nobody wants to think about what if the company needs to replace me, but I think a good IT person is going to consider that because it helps them and the company. I know there are some administrators that worry too much about that where they say, “Hey, there’s all this documentation for everything I’ve done. They could really easily replace me.” That, that’s hard. You just need to do it anyway for your yourself and your company.
Finally, being accessible for your employees, clients, or anybody really to ask you questions and being friendly. I’m not gonna grumble about needing to walk over to somebody’s desk to take a look at their mouse or say, “Oh, well, I’ve got 10 minutes left of the day, you’re gonna have to wait until Monday for me to reset that password.” Because all those things are not accessible. If you’re not accessible and they don’t want to go to you, they’re definitely gonna try and roll their own solution. They’re say, “Okay, I’m tired of having to ask IT for this because they always make me feel like an idiot. I’m just going to make my own thing and then I won’t need to ask them.”
Michelle: Absolutely. I think that’s critical. It really is. So, well, I don’t think we have any more questions. I want to thank everyone for joining us today and encourage you to plan to spend the same time next Friday afternoon, same bat time, same bat channel.
We’re going to discuss how crises changes buyer behavior, and for that one, that’s going to be a conversation with our founder, Marty Weintraub, our CMO, Susan Wenograd, and our VP of Public Relations Joe Thornton. So, until then, stay healthy and be well friends.
Join the AIMCLEARians every Friday at 3:00 CST onÂ
