What is MOps hacking? Is that even a thing? Sadly, it is.

As MOps pros, we get caught up in all of the tools at our disposal that can do a variety of cool things. We often build overly complex processes or build too quickly without thinking about the downstream effects and limiting technical debt.

MOps hacking is a real thing, causing real issues, and it needs to stop.

Tune into this episode of fwd: thinking where we go in depth on MOps hacking and what you can do to put an end to it.

Transcription

Crissy:

Okay. So on today's episode of fwd: thinking, we're covering maybe a controversial topic, but why we think people should stop MOps hacking. So we'll talk a little bit about what that is. And I think this comes out of, everything we're doing recently talks about how to be more strategic in marketing operations. And one thing that I think is keeping people behind, but also just our departments behind, is when a lot of what we're doing is just MOps hacking.

And I think just given the fact that we're close to technology and all the processes that you can put in place, there's a lot of practitioners who are just falling onto all of these habits. And we'll talk about what that looks like and all the issues that could come up from it. So, do you want to kick it off?

Charlie:

Yeah, it's a very nuanced topic, and I think everyone has an opinion on hacking or what is an acceptable amount of stretching tools maybe beyond their capabilities. And some people I think have some pride in taking a tool that isn't 100% meant to achieve a certain job, and then finding out a way of doing it. And I think there's definitely a time and place for that. So I think articulating what we really mean by MOps hacking and the nuances there, I think is going to be important.

So really at a high level is building processes, adding on certain aspects and processes within tools, without really looking at the big picture. And trying to account for ... If certain edge cases that you're trying to build things for, that don't really require that level of complexity than what you're building. So maybe someone's come to you and they've asked you for something. "we need to get this." Certain data or certain report, or certain process build, and there isn't really an easy way to do it. So you go and you hack away, and you build random processes that you're not 100% confident in.

Crissy:

Totally. And I think the problem with that is a lot of the times you're over-complicating things, and just putting in complexity for complexity sake, because you needed it. You're not really thinking and going to all of the people that are different players in the systems, and figuring out what's going to be scalable. You're not really thinking about the longterm impact as well. Is this sustainable? Are we going to have a ton of errors? Will this cause sync issues, performance, can it be impacted?

And I think you see this a lot too on the Salesforce side, where maybe there's a ton of process builders, all for the same object, that are all executing in different directions. And you wonder, why am I having CPU limits, why am I seeing errors on the market automation platform side because of this? And it could be because you were just hacking things together as we would say, and doing that means there's going to be definitely longterm impact.

Charlie:

Yeah. And you haven't looked at the big picture of your whole stack, and how everything interplays with each other. You've just gone, okay, well, I have this one thing I need to achieve, let's just build it all out like it isn't going to impact and have any other downstream effects, and then you move on. So a lot of the time stuff like that is really hard to troubleshoot. It's impossible if you leave and hand it over to someone new to explain it to them. And also a lot of times it's hard to document. If you're finding it hard to document something, then you've probably hacked it together. And if it's causing a lot of errors that you don't really know what's happening, then you've probably hacked it together.

Crissy:

And then the sad part is too, you're probably building something for maybe something that isn't even really long term. Someone just asked for this request, and you're just quickly responding and building something for it. And so I think that also means there hasn't been this discretionary questioning on, is this something that we need? Is it going to be purposeful long term?

Charlie:

Yeah. And I think the over-complicating part, that's something that's a really interesting part of marketing operations, because what we do is relatively complicated. And we thrive under that. People who like marketing operations, we enjoy building things, and we enjoy taking on challenging projects and trying to think it through. And a lot of times that does need a complicated approach.

Charlie:

However, it's over complicating it that's the issue. A lot of times you can get the majority of the value with something maybe a little bit simpler, that's maybe going to cause less stress in the system, cause less errors, be easier to troubleshoot, easier to document, easier to manage overall. You might not get 100% of the way there, but that extra complication at the end there, to get exactly what you want, and maybe you need to create 20 more fields to get there and use Process Builder or Apex in Salesforce, and then a load of other complicated, smart campaigns in Marketo to do it. When in reality, maybe you could have scaled down the scope of what you were trying to do, got the majority of the value, and you have a much more sustainable build than you did if you're just over complicating it.

Crissy:

Yeah. So I think you're starting to see what is MOps hacking. And so, let's talk a bit about the issues. So we talked about, we're not building for the future, we're just building for the present. And like you said, there's downstream effects to that. It's likely that whatever you built is just disposable, and it's just going to get ripped out. One, because it can't be understood, and also it can't scale. It just causes too many errors.

And then a second one would be, if you ever left, it also could be ripped out because it's just too complex for someone to go in and figure out what the heck is going on here. And so again, disposable. So a lot of your work you can see here, could just end up going to waste. And if you actually put some strategy behind it, built something that's going to scale and then documented it, even once you leave, it would have a long lasting life to it.

Charlie:

Right. And then one of the other issues, is that a lot of times this is done in a silo. You just go, "Shit, I need to get this thing done. Okay, I'll go do it. Okay, let's just build all this stuff as out loader fills to Salesforce. Let's just build it all and it'll be fine." And then a lot of people go, "Hey, what's this field used for? How is this field being updated?What's going on? I'm seeing this sync error, but I didn't even know we had this field."

So because you're working in that silo, and you're building it all without going through proper procedures with the rest of the team, and making sure it's part of your roadmap, the rest of the team could be completely thrown off. And we've seen some Salesforce instances that have been so bogged down, that the whole Salesforce instance is unusable sometimes. And that is all down to just hacking.

Charlie:

Obviously that's probably multiple people joining, hacking away, leaving, another person joining, hacking away, leaving. And they'd all worked in silos, they all haven't been communicating well. And where does that get you? Unusable instance, where one person comes in and goes, "Okay, I don't want to work like this anymore." And they have to just rip everything out and start again.

Which, that happens a lot. How many people have just ripped out the whole Marketo instance and started again? That's because of hacking.

Crissy:

Yeah. And then I think going into that on the planning side, you don't really have a plan, so you're just building cool things with different technologies, but not thinking about the goals of the business. And so you're looked at as just a department, who's just doing maybe some technical things, but you're not really looked at as a strategic leader, or someone who's really building something that is valuable to the business, because it can't be tied to the goals of the business.

So, you might be building some amazing things, but when people just don't understand them, or they don't see how it aligns to the goals that they're working toward, your team is not really looked at it in a very strategic way.

Charlie:

Yeah. And a lot of times you might be building this in tools that aren't really part of your main stack. You might get a trial of a tool or introduce a new tool, that no one else really knows is there, and now you've got even more problems. There is a certain level of problem when you're hacking away in your existing systems. Now you add on another tool, with another integration, whole other bunch of complexity, you hack away in there. And there's some people that didn't even know you have that tool. Communication between sales ops, biz ops marketing ops. And it just can create so much time wasted and so many issues.

And I think just finally, we get it. And I'm sure we've been guilty of this. There's probably people listening to this video going, "Huh, I remember you. Seven years ago you built this one thing, or you created all these fills that you shouldn't have." And that is hard. You have-

Crissy:

It's tempting. That's the harder part. The easier part is to just get that person happy, build something that they're asking for, do it with the best that you have. Move fast, break things. Especially when you're in a startup. But there comes a time in your company's life or your career where you just need to stop doing that.

And slow down. And we see that a lot now, because I think so many people have done it enough, where we're seeing the downstream effects. And because all these systems and tools are intertwined with each other even more, it makes it more tempting for MOps people to really over-complicate things, over-engineer things. And yes, it's cool. Yes, it might help you get someone off your back, but really taking the time to figure out how you can maybe take a more strategic approach, or maybe lengthen that out, it'll really help you in the long run. And just for your career when you leave. Someone will be like, “XYZ did an amazing job here, and we'll keep the stuff that he or she built.”

Charlie:

Yeah, we're never going to work our way up in an organization if people think of us as just hacking our way through things, and then we're just dealing with troubleshooting and errors and issues, and just fire-fighting the whole time. And then leaving, and then someone else joining and then they have to do the whole thing and rip it out again. And then they just do it. Marketing operations has got itself in a bit of a cycle with that. And we have to break out of it. We have to think more strategically and build things properly.

Crissy:

Yeah. So moral of the story, stop MOps hacking, and also just be more strategic. We had our previous episode on the ways that you can elevate your role in the marketing ops department and be more strategic. So go back and look at that.

Charlie:

That's anti-MOps hacking video that one. How to anti-hack.

Crissy:

Yeah. But I think that'll how you can really find the antidote to this MOps hacking. So yeah. We'll see you on the next episode of fwd.

Charlie:

Yeah, see you then.