Episode Transcript
[00:00:10] Speaker A: All right, welcome to Arbery digital experiences. This is episode twelve, and today we're going to cover what roles are needed for a successful AEM implementation. And so on this particular podcast, what we're going to do about the roles involved in AEM, which in a lot of cases could be extrapolated out to basically any other digital experience platform, whether you're talking sitecore, you're talking drupal, you're talking optimizedly, contentful, whatever.
In any of those implementations, a lot of these roles are going to be the same. Some of them are not going to be the same. Some of them are specific to AEM, but we're going to go through all of them now.
And this is, we really want to go over what you need to do to be successful. Not just a one off sort of a project type of thing, but if you're a site owner, what also do you need to be continuously successful? What skill sets, what are the differences between them, so on and so forth? What are the ones that you should have in house and what are the ones that are, are even appropriate to hire out for or should be hired out for, or you're going to only going to do it in a pinch.
And the audience, the sort of people that I would love to listen to this, if you could, is not just, well, am site owners for sure, but also recruiters or anyone involved in technical personnel. Because if you are recruiters, ever sent an email to some potential AM candidate, really, just please plug this in to walk around the block, give this a listen. Cause I'm gonna make it worth your while.
Now, as a disclaimer, I work for a digital services agency as a solution architect and an AM architect. So you should know that. But at the same time, I've also worked in house as an in house staff engineer for various sites directly. So on one site all the time, I've been a managed hosting guy and I've been a product owner, UX designer, copywriting personnel, stuff like that. So I've kind of worn a lot of different hats in this. So I'm going to try to make this relevant to anybody. Hope this is going to be helpful with me today. I've got Hank, Toby, who is the director of business execution at Arbery Digital.
And Hank, you have nothing particularly been in am recently, but you have been in a, I guess, analogous sort of a big site of late. This is a. Yeah.
[00:02:50] Speaker B: So a lot of these same rules are filled at the job I'm currently at, where I'm a project manager. But there's slight differences between what we're running over there and what we'll be talking about here with AEM specific roles and the breakdown of those rules.
[00:03:06] Speaker A: Yeah, and this is, I mean, this is, I guess, too. I mean, we got a whole nother podcast on. On the differences between AEM and other, you know, you've got monolithic, you know, big monstrosities, kind of like AEM. You got ones that are super composable, like what you've got with the company where you're at right now, where they're based on strappy CMS. That's right. And then you've got other things that have plugged into it where you've got, you know, yes, it takes a lot of specialized skill to learn AEM, but it also takes a lot of specialized skill to learn that whole layout of everything that you've got, because it. I mean, learning AEM is one thing, but at least if you learn AEM, then you pretty much, you can be useful on another AEM project. But if you learn, just learn strappy and you try to move in to your infrastructure, I mean, it's not like you're totally hitting the ground running and you're useful. I mean, what would you say is the average length of time it takes to have somebody be genuinely like, okay, good, I can give this, this person really understands what's going on here, and I can give them something to do. Yeah.
[00:04:17] Speaker B: I was recently talking about this with one of my colleagues at our customer, and we were thinking it was at least six to nine months, which is pretty crazy to think about it, but it's.
That's what we both thought it would take to really get your hands dirty on the system and really fully understand it.
[00:04:35] Speaker A: Yeah. So, so the thing is, is that, and that's. That's what.
That's where it's not. There's not a one size fits all, and there's not a cure all in any of these personnel discussions and project discussions, because you could. Because you can't necessarily just say, hey, we're going to just hire six developers who know strapi, and then they're going to just be useful on this six month project, because at the end of six months, they're barely going to be really understanding how the whole system works.
[00:05:05] Speaker B: I do think if it's a more compartmentalized project where there's a set goal and it's due x tag, and then we're kind of going to run it on our own, that's a little bit easier. Starting from scratch is a little bit easier, but especially when you're moving into an existing infrastructure, I could see that ramp up taking a lot longer.
[00:05:23] Speaker A: Yeah. Yeah, indeed. And that's, I mean, I guess that, so we're going to go through a bunch of these different roles in this podcast, and we're going to try to talk through, you know, what are the, what are the specifics of what they should do. But one of the themes I want to keep coming back to is whether or not it's a thing that it really makes sense to have at your company.
When, when does it make sense to have it and when does it make sense to hire it or when does it make sense to bring in an agency that does that thing? I mean, I mean, it's a little bit analogous. I mean, before the podcast, you know, we're talking about home rentals, and that's one of these things, too, where it's like, there's specialized skills in all of that, too. And when you talk about, like, for example, you know, like, so you're going to put copper downspouts on the side of your house that like, copper downspouts people who know how to work copper gutters. That's a whole, that's its own career, basically. And you, if you know gutters, you don't know copper gutters, right? And so you could, we could learn how to do copper gutters. But why you're going to be able to do that, learn that skill, you know, arduously and be able to do it exactly one time. You, you know what I mean?
[00:06:29] Speaker B: So that's a perfect analogy.
[00:06:32] Speaker A: I think so, yeah. It's, it's, it's a. So we're gonna try to, we're gonna try to keep it real on that, on each one of these. And which, which are, which are the ones that you should definitely keep. And I guess in, in starting that off, I got a big list of, list of things. I'm gonna try to go through these.
I think I've got most of the roles, but I really hope that if somebody wants to bring in a role that they're like, hey, you didn't mention my, you didn't mention this role and it's totally vital. And why don't you bring this up then? Please leave a comment or just reach out because, well, I mean, heck, maybe I'll just have you on the podcast and you can explain your role.
So, but starting from the top, so you've got in any site implementation, any big AEM site or this would also be applicable with any other digital experience platform is you're going to have a project or product owner who is there calling the shots and running the show. And this is a person who almost, so this is the person who hires the people, who is the one who is managing the budget of things, who's setting the big broad goals for what's going to get done and so forth. And this person is almost going to be uniformly a full time employee of that company.
This is, this is, out of all these roles here, that's the only one. That's the only one really, that is, is, um, I've never ever seen that outsourced. I've never seen the entire ownership of a site outsourced. Um, besides, what is the.
[00:08:06] Speaker B: Sorry, uh, what is the typical title of someone who has, uh, is the product owner or project owner?
[00:08:12] Speaker A: I mean, this is usually somebody who's a, who's either, I mean, in some cases they're a vp, in some cases they are an AVP, in some cases they're technical director.
They're almost always director level or above because in any large site, and this is, we're mostly dealing with large companies, we're talking about AEM, we're not talking about a small WordPress site, because a small WordPress site, you know, the person who owns it is like the dentist and you know what I mean? And that's different. That's totally different. And yes, you can, you can totally outsource that kind of stuff because, yeah, if you're, if you're like, you don't have a technical, technical director, vice vice president of information systems when you run a demo office. But, but in this case, you're talking about massive it organizations. And yes, the person who owns the.com for a major brand is, is going to be, is going to generally be a director or vp of some sort.
They, and a lot of times, depending on the size of the company, a lot of times they will have sometimes even vps or directors and so forth below them. And depending on the size, again, you could have directors in terms of who are running QA, you have a director who is just running site reliability or something like that. I mean, these trees can send their roots pretty deep in terms of how big do you grow this out?
But again, the leadership level there, the person who's calling the shots, who's saying what technologies are we going to use, what personnel are we going to use, what's our budget and all that sort of stuff, that person is, is going to be a full time employee.
Now, below that well, not necessarily just below that, but I guess the next one to talk through with respect to the thing that you're implementing is this title of solution architect and the solution. So whenever you're trying to figure out what is it that you're going to buy and what is it you're going to implement, this is something that you need somebody with extremely broad depth. They need to be deep and broad in terms of technologies that they know. If you're talking about an individual technology like the Adobe experience cloud stack, you need somebody who knows everything that it can do, everything that it's possible that it can do, and everything, every way that it can be implemented and mis implemented. And ideally that's the sort of individual who's brought in before things are purchased, ideally before things are purchased that year.
[00:10:43] Speaker B: All right.
[00:10:44] Speaker A: Yes. Well, now, these days, yes. And because, I mean, I've been an architect on projects and then, but a lot of times I get brought in now on this because, I mean, it's, it is another hat that I wear. This is kind of this sales buffer hat because in some cases, the, the person who's coming in with both guns blazing is, is going to be the, the technical sales on a given tool. And, and the people who generally have technical architects, solution architects to spare are ones that are trying to sell a solution into a company.
They're going to say all the things that the solution can do. Right. They're not necessarily going to talk about any of the downsides. And so you generally, you want, so if you're a big company with a big technical footprint, a lot of times you have somebody, you have a, you have an enterprise architecture arm or organization or something like that, which is in charge of managing all these different stacks that you have. And like, oh, we have our Adobe stack and we have, or here's what we use. We have chef that runs our deployments, and we've got this, here's your database stuff. And whenever somebody wants to sell into this, that person is in charge of holistically going, where does this plug in? And this is work. Let me understand it all this. Yes. Now let me, here's the solution that we want to do. They're the ones who are being that buffer at that point, but it's only the super large organizations that really have that role sufficiently, you know, staffed.
Anything smaller and a lot of that, you have to bring somebody in.
And this is a role that's super hard to have on staff full time for a smaller company. By smaller, I'm talking about, you know, a few thousand employees or even up to, you know, 1015 thousand employees or something like that. Smaller. Yeah, smaller. Right. But, so that's how many employees you have. But, but how many people do you really have in your marketing organization? Is it different? Right. So if you have some big manufacturing company or something like that, yes. You might have tons and tons of people that work in your plants. Those aren't people who are running your website. So, and those guys, those, those, they don't have an infant marketing budget. So, so you can't necessarily keep, you have to have projects happening all the time to keep a solution architect busy with saying, good, how do I, how do I design this next one? And that's generally somebody who's then going to be working for an agency who you're going to bring in. Now, these people also work for Adobe as an example. But that's, that's, that, well, they do, they totally do. And they're, and some of them are super great.
But the problem is, too, is they also work for Adobe and they're part of the sales arm, which is trying to sell a solution into the, into the company. And so a lot of times I end up having to be brought in to kind of pump the brakes on things where, where a contract gets signed and it's like, whoa, you don't want to sign that contract just yet because this is a one year contract. It's going to take me or any team, you know, six to eight months to implement this thing where you're only going to have three months of this service that you just paid a year for left by the time this thing's done. So don't buy it now, like, buy it in eight months or whatever. Like there's, and that gets salespeople mad. But it's fine. It's, it's still, it's the right call. And so you have to have somebody who's there to understand all these different pieces. And a lot of times that means different tools. You have whatever, you have all kinds of different tools that end up going into any implementation. So you have to have somebody who understands a bunch of, that's a special.
[00:14:12] Speaker B: Benefit of working with a third party like ourselves to come and be that more unbiased opinion in the room as opposed to working with like, Adobe managed services or the architect. That's right.
[00:14:26] Speaker A: That's true. And so, yeah, so, yeah, I guess that's a plug for what I do is like to, I like to be able to be a buffer like that, to be able to make, to have somebody do something that makes sense.
But once you've got a plan, like once you feel like, here's what we're going to implement, it's going to be implemented in this way, we're going to use these tools, it's going to take about this long. We need about this many people.
Here's the general plan. Generally the best thing to do too, is to do these things. You've got a planning and an implementation plan. They're two separate plans. Sometimes they're two different crews that are doing this because you don't want to start an implementation plan that has an implementation project that has a planning component because the implementation has already started. And you're like, hold on, we just planned it now. We found out that we need seven developers and not two.
And then it takes time to bring some of these guys online. And I mean, even big shops don't necessarily have 20:00 a.m. developers sitting on the bench just waiting for your call, operators are standing by. Kind of a thing. Like you need time to be able to put those guys together.
So, yeah, so I definitely recommend doing them in pieces, though. Once you got a plan, then you kind of get to this next person or this next role, which is probably one of the most ambiguous roles that I've got here, which is the AEM architect.
And it's so an AEM architect, similar to any other software title, architect kind of gets thrown all over the place in terms of what, what do they want? Like if I get a job thrown at my and said, hey, I'm looking for an AM architect, I'm like, what? What does that mean exactly? What do you want exactly? Like an AM architect should understand the full breadth of the product. They should understand everything that it does. They should under they, I mean, and this is where they also need to be able to be, to lead a development team, they need to be able to do the doing of running the project and I, and do the project as well. But what kind of is the difference? And you and I were talking about this earlier, and this is super astute, what you were saying earlier on, the difference between a developer and an architect, and I never really, yeah. Tech difference between a tech lead or lead developer and an architect is really that the architect has to have seen, have seen enough to know really to be able to make a pretty good call on everything that a piece of software can do. So that if somebody says, well, should we use AEM to store, to connect to this backend database and store it in like, well, I know a can do that am shouldn't do that and I've seen it and it catches on fire and we shouldn't do it that way, you know, so that, so you need to know enough about that. A lead developer yes. Needs to be able to do the doing of all that sort of thing but the architect needs to be able to sit one level up besides that. Yes. Needs to be able to go in there and pitch in and say go, you need me to write this service, I'll write the service. Or you need to go and configure this thing.
[00:17:47] Speaker B: There's definitely an aspect of experience and skill that might actually align the two in a lot of ways, especially on the experience side. But then there's those soft skills too, right?
[00:17:57] Speaker A: Yeah, yeah.
[00:17:59] Speaker B: Being able to be that bridge between business and have those communication paths.
[00:18:06] Speaker A: Oh totally. Yeah. And so because you've done project manager and kind of ba to a degree at your current role too and a lot of times I find that as an architect you end up kind of having to do be a little bit of a bae also of like, oh, you want this feature? Give me a second to decompose that feature into what it's going to be. Okay, good. So, okay, you know, Charlie or you know whatever, you know, Sridhar or whatever, like how long do you think it's going to take to do that thing? Okay. Oh, so and you come back and say good, it's going to take us six months to make it like that. Can we do it a little bit smaller or whatever it is like just to set functional and business, you know, to be that bridge on business requirements and stuff too.
But the other soft skills is debugging personnel and making sure personnel have what they need to be effective because a lot of times it's like if you got a team of, let's say you got five developers and maybe a QA person or something like that that are working right. Those five people are going to be doing random unproductive stuff without somebody really technical who can get with any single one of them and say, hey, so at sprint planning this week. So when we were talking about that feature, did you, did you, what did you get out of that? Oh, you totally didn't understand. Great. All right, let's clear that up right now. You know what I mean? Because sometimes even the most talented people, they'll get bugged and they don't want to talk about being bugged, you know what I mean?
It's embarrassing. So. And different people have different you know, responses to that sort of thing, too. So being able to get in and work with the team and keep the whole team productive is kind of your job also. Yes. You could say it's a, it's a PM job and a super on it, highly technical PM can do that, too. But I think you're asking a lot. You're almost saying, okay, all right, architect, I want you to do, to be a PM if you're going to have them do that role.
[00:20:21] Speaker B: And in my experience, everything works best when the project manager and the architect or the project lead, or hopefully all three are very much on the same page.
[00:20:33] Speaker A: Yes.
[00:20:34] Speaker B: Steering the team was the same goal.
[00:20:36] Speaker A: That's right.
[00:20:37] Speaker B: I think that's really a lot of the leadership on a project.
[00:20:40] Speaker A: So, yeah, yeah. And it's so, again, yeah, I think that, and that sales deflector is also kind of inherent in the Am architect role to a degree, too, because that'll come in and somebody will try to sell into something. This is where. So an AM architect, I think, works well, can work well either. Either as a, as a hired gun or as a full time employee. And a lot of times you do need in larger sites, it's important to have somebody who's wearing that. And basically in almost any good sized organization, it's important to have an architect on staff because a lot of times, just the full time, just what goes on is some vp was like, hey, I went to a conference and they told me all about this great thing and it uses AI to something or other and the architecture is like, okay, good. I've used this and it doesn't actually work. It's like, or guess what? It's irrelevant. This tool sounds great on a spreadsheet or on a PowerPoint or whatever, but it's irrelevant.
[00:21:55] Speaker B: So I feel like an architect also works well, at least in some of the past projects Arbery's done where they kind of come in, point the team in the right direction, like more of a consulting situation, and then are able to back out or not be so on top of everything, maybe not 40 hours a week.
[00:22:14] Speaker A: It's true. It's true. And I mean, I like that model.
[00:22:18] Speaker B: For architects as well.
[00:22:19] Speaker A: I do. And I, you know, and I want to hope that it's long term, financially valuable, because it's one of these ones where after being a consultant in many different capacities, I hate when a solution is sold in that is so complex that it requires people, huge staffs of people to continuously work it. And I would much prefer to work myself out of a job and make a. Make a company be successful. And when I'm brought back in, it's to do something new and cooler and to add functionality that really brings value as opposed to.
[00:22:54] Speaker B: I think we've seen that with some of the customers you're working with right now.
[00:22:58] Speaker A: Yep, yep, yep.
I've got one project right now that I happen to be very. I'm very pumped about it.
It's probably the most pumped. I've been about a development project in a long time, and a lot of new tech working directly with Adobe on it, and. And I do very wholeheartedly feel like we're gonna.
The next engagement that we have on it is gonna be to build new stuff, and it's not gonna be just, all right. It's gonna keep breaking. You're gonna keep it. Keep calling me. And, like, it's. It's. It's not gonna be that. We're gonna. We're gonna just be building newer and cooler stuff. So it's. It's something that I'm really. I'm very excited about. So, yes, I think it should be. The other thing I wanted to say, though, I think I've said a couple of times, like, this whole sales deflector thing, I do want to make sure I have to do the opposite also. And sometimes you have to chase, because sometimes salespeople are notoriously difficult to get hold of when you actually do want to buy something. And I've had that experience recently, too, where I'm like, we need this product and we need a rhino, and then you got to, like, everybody is used to, like, this whole long sales process where you just, you know, you get this, and then you actually, like, you know, like, no, I already know what I want. I want that thing. Sell me the thing right now. Give me the price. Well, if we can give you the price right now. Like, no, give me the price. Time to buy it. Like, so you have to kind of go both ways on that, too. And, like, tell the. Tell the. Tell the company you're working for. Like, no, no, we need this now. We don't need this later. We need this right now. And so, so there is that. There is that piece, too, that it does, again, fit into that architect hat. So you're sometimes the sales guy's best.
[00:24:43] Speaker B: Friend and sometimes their worst enemy, depending on that value to head.
[00:24:47] Speaker A: That's right. That's right. So I hope I don't make too many enemies who I've torpedoed. Sales deals. Like, hey, no, I'm also very good for sales deals. Just remember?
But yeah, so the next one on the list is an AM developer. And so this is one where again, depending on the needs, this can be more than one thing.
AM developer is super specialized skill. It's not. So if you take your average like CS major coming out of college and let's say they learn Java in college, they're not instantly viable as an AM developer. You can make them into an AM developer. But am development has a lot, there's a lot of tribal knowledge, a lot of domain specific skill that's involved. Am has got its own templating language, which is different than anything else that you kind of, you have to know in addition to your out of the box kind of CSS and JavaScript type stuff, heavy duty Java. A lot of times you need to know lots of other things because you're connecting to other things. So you need to know how to get in and out of various APIs, you know how to talk to SQL because half the time you've got some crazy, you know, 15 year old SQL database that you're trying to extract things out of, you know, and run with. So it's a, it's, it's definitely a skill to, to know what you need in terms of is this person going to be primarily front end or primarily back end is important to, to define when you're defining the skills that you need for a particular project because front end guys are, especially these days with the advent of much more of this edge delivery stuff.
Edge delivers new tech from Adobe. It's replacing, it's the direction that Adobe wants a lot of the front end to go in the future. They're like, in the future everything's going to be edge delivery. I think it will be, but a lot will be, there's a lot of things that get kind of shoehorned where, you know, kind of the, you know, you know, all I've got's a hammer. So everything's a hammer kind of a thing that am gets used for that a lot. Right now. Like we need a microsite, I've got AEM.
You know, it's like, nah, it wouldn't be the best for this thing.
So the, so edge delivery is, is something that I could get a CS grad at a college and say, yo, you're going to be my new edge delivery front end person. Are you sharp? Can you learn new stuff fast? How's your CSS? Like, good. Great.
Put you to work.
So that sort of thing is, and that is one of the big pluses on edge delivery. Is how quickly you can get people to speed.
[00:27:35] Speaker B: Have you ever worked in projects where the back end developers and front end developers are the same people, where there's a lot of cross functioning those teams? Does it just size of the project and what the ask is it depends.
[00:27:46] Speaker A: On the size of the project. Yes, it depends on the relative skills and proclivities of the, of the peoples involved. Because sometimes you got people who really, you know, like a good front end person, it's its own, like, it's funny because back in the, in the olden days, you know, webmasters, it was, you could just kind of be a jack of all trades and you could kind of do everything full stack. Yeah, right. Yeah, full stack with AEM is kind of a lie. You basically, you're saying I can't really do anything very well. Yeah, because it's, because back end development, especially doing it well and especially doing it where you're not going to cause a massive reliability problem later, is its own total skill. And then front end developers, and I've seen those guys go, and I'm not a front end developer, and those guys are wizards and it's its own skill. So yes, there is overlap and just like DevOps, where you have to have the operations guys and the developers speak in the same language with a lot of the same goals and so forth, you have to have, it's Dev. Dev in that case, you have to have those guys also on the same page, but not necessarily be the same people.
[00:29:04] Speaker B: Okay.
[00:29:07] Speaker A: But on that subject too, in terms of the specialities of those, you've got other AEM technologies that require their own developer skills. So AEM forms. But sometimes you'll see, you know, we need Am forms developer. So am as a product can make a form, right? You can make a form with core components and make a form that's not AEM forms. Am forms, confusingly, is its own complete project. A product used to be called lifecycle, it was, and now it's mostly in the cloud service, basically a brand entirely new product. But it's for doing things like adaptive forms and PDF generation and things like that you would need if you were a bank or a healthcare provider. Like, hey, I'm going to generate, based on this data that you input, I'm going to generate a legal document for your new insurance policy that goes to Adobe sign, you electronically sign, and that goes and goes to all the different places that it needs to go. This is for the real deal, digital transformation stuff. A lot of times I hate that word because it gets used for total random stuff like designing a new website is digital transformation. I don't give me a lot of things, give me now, but no real, real deal digital transformation is if it was a silly manual, okay, I take this and I stamp it and this and it goes over here, triplicate, carbon copy, like if it was that, and now it's this fancy system where the whole thing can happen. Self service with no personnel involved. And you just got have somebody who's monitoring it all. That's transformative because you can do things that where you said, okay, well we can process one of these applications within two weeks and now you can process it within 24 hours. Like that's a big deal for a company. So that's forms, that's its own skill. So if you need forms development, you need an Am forms developer who's worked with this stuff because it is its own whole domain that you kind of need to know about. There's crossover.
[00:31:10] Speaker B: What industries have you worked with where forms is the main or is it a bigger deal than others?
[00:31:18] Speaker A: Well, basically any place where there are documents that go around. So financial services, health care, I mean even some types of purchases and so forth require forms that cruise around and stuff like that.
Personnel, you know, hiring and stuff like that, that's another one.
But for the most part, a lot of that, yeah, Finserv and healthcare are massive forms and in fact, I would say, I don't know, 75% of the ones that I've worked on have had an AM forms license. So, but a lot of times it's underutilized. Unfortunately, forms is expensive, but what's really expensive is not using it, buying it, not using it, that's really expensive.
But then, but then one thing that almost everybody has is assets, and doing assets development in some cases is its own thing and really utilizing assets as its own thing. So sometimes, and then sometimes that busts out into other sub specialities like, oh, with assets, taxonomy is a big deal.
How you name things, how you put things together, ways that you enforce taxonomy, ways that you say goodwill, anything that goes into this folder is automatically tagged in this way. I'm going to manage my taxonomy in this way so that you end up with another job, with larger sites of information architect, which is its own job, not even necessarily am domain specific. So somebody who does IA work could do it in many other fields and a lot of times super good. It's a big information architecture book that I read once and I'm like, wow, this is a super big job.
I'm glad this is not my job because there's a lot to this lot to think of. And so there's a big healthcare company that I work for, and they, this is a job that they even have a separate product which manages their taxonomy and makes sure that nobody starts tagging things in this way that could get them in trouble or could be confusing because it doesn't have to do. Yeah, so that's something.
But so, yeah. Forms assets. Okay, good. Well, then that gets us onto our next thing, which is QA.
So, and this is something that spreads the gamut between, between AEM world and any other DXP is a good QA. And you've got, and this is an engineering job. A lot of times, though, you want get somebody who's doing QA for you. You want somebody who's, who you're not going to have to train on Am from scratch because otherwise, that's a, that's a, that's a tough, that's tough hill to climb in the middle of a project. And I've experienced that a number of occasions. This is where you got to get.
[00:34:06] Speaker B: You'Re saying you want an AEM experienced QA engineer, ideally.
[00:34:11] Speaker A: That's right. It doesn't have to be somebody who's got AEmQa in their title someplace. That's, that would be an arbitrary. And I've, and I've, and I've had hiring managers try to, try to say, oh, well, we need to get an AM developer as our QA. And I'm like, you don't. Not really.
But having somebody who's actually seen it and worked in such a system is a really good idea because there's a lot of gotchas and you have to know what to test also. That's the biggest thing. That's the biggest problem, too, with QA, is that if you're going to go and say, good, here's my site and here's the way we migrated from the old one to the new one, and here are the language mod. So we used to be locale based and now we're language based. And this, and this. Good. I want you to set up your test cases for this. And they have to know, they have to be able to run with that because otherwise, if you're having to think through as an architect or as a lead or something like that, all the test cases and now you're the QA, so you don't want them to be just a QA robot because that, I've also seen that, too, where you have somebody who isn't necessarily a developer. And they're just, they don't know what to test. They can script, but they don't really know what they're doing. And then it's, then it's like, then it's kind of QA at that point is kind of a camouflage hole. It's not really like you're like, oh, I got Qa happening. It's QA and, but it's, you know, it's not really. Yeah, you need somebody who's thinking through these things in advance and, and ideally generating.
So in AEM, too, there's a lot of different hooks to be able to go and put things in CI CD along the way where you say, good, when this deployment runs, I want to do to use whatever sauce labs or something like that to go and click through this thing and do an automated test just to make sure I didn't break anything with this deployment. And so somebody who can plug into that sort of a pipeline is huge because then you could massively increase the velocity of your deployments safely because then you can say, good, I can deploy this. I can deploy this twice in the same day if I want to. I know, because when the deployment runs, it's already run a test to see if I broke anything major. So all I have to do is test the things that I changed. So it's kind of a big deal to have a good QA engineer.
So this. So next up, so, authors. So we've mostly talked so far about all of the development that goes into developing on AEM. And I guess this is, this is where it's kind of similar to the environment that you've been in, in that you've got all these other places where data needs to go in and where data needs to be moved around and all that kind of stuff, which it's its own kind of domain specific skill with AEM, because you need to know how to tag, how to use components, how to composite a page based on tool, based on blocks of composable, like, okay, this component does this specific thing. Or if you're working in edge delivery, this block can be used in this certain way and then they're used to developing on that. I would say an AM author, the more classic way, not the edge delivery way, is a deeper learning curve. So if you have somebody who's, who's doing that, it's really important to have somebody who's worked in that environment. You can also train other authors because a lot of times because AM is not a simple, super simple system. So having somebody who can train authors on that island, kind of important now.
[00:37:53] Speaker B: Are authors and front end developers similar role or authors more kin to like almost the marketing team.
[00:38:03] Speaker A: They're more on the marketing side. They're, they're, they're going to be ones who are actually inputting and compositing all the content that's there. And a lot of times, too, you have assets administration that goes into that where, where you've got, I mean, let's just say you've got a big brand, like a sports brand or something like that, and you've got, or you've got a brand that does whatever physical products or manufacturing or something like that. We've got a bunch of products. You have places where all those images are stored. You have photo shoots that are done. You have product images. Product images sometimes need to be done in different languages and stuff like that.
So administering all that and getting the content in, there is nothing usually at all part of the development team.
But there's interfacing that gets done is whenever there is a new feature that gets rolled out, then there's training and so forth. And so, so the larger the team, the more that has to be kind of formalized as a role.
Sometimes there is somebody who's kind of the main person who's, who's involved in like kind of the scrum master of the, of the development team ends up being the person who writes the release notes for the authors and says, okay, we just roll out this new component that's a new video player totally doesn't work like your old video player. What you do is, and then shows them how to use it and how to organize things. I've seen that work pretty well. But then all that authoring is generally completely detached from your development team if it's all part of the development team. And that just, that's kind of a car crash.
So there's a lot of other, I guess, adjacent to AEM roles which I've also seen get kind of.
Sometimes it makes a lot of sense to have somebody who knows AEM, and sometimes it makes no sense to have somebody to require that the person knows AEM in order to say, you have to, you know, you have to be an AEM guy in order to be on our site, you Know, kind of a THIng. So one of them that it, that you do need AEM specific skill, is it. So, so in AEM, you've got two totally separate products. One which is cloud service, one which is AM self hosted or on premise, which is, which is currently AM 65.
So between 6.5 and cloud service. If you're running six, five, you basically need somebody.
Either. You either need a company who's managing that whole hosting of it and all of the care and feeding of AEM, you need somebody who's doing that.
Chambers plug. Arbery does that.
Or you need a Whole team on site who is working with that. And a lot of times, too, and this is something else that we've kind of found over the years, is so if you have guys who are running folks who are running AEM, and they're, they're operationally in charge of AEM, and this is, this was my job for a lot of years. So I know all of the, you know, pain and, you know, post traumatic stress that goes with this is that we call that. Yeah, yeah, we call it that. So the, a lot of times you'll run into issues that are poorly documented because am being a huge system with so many integration points. There's so many different ways that it can catch on fire. And so there's so many different ways that people have learned to do things over the years, which may or may not be a best practice. So there's all these different ways that it can just break catastrophically.
So with that, a lot of times your only way of getting a solution to something is a ticket that you open with Adobe. Those tickets don't really have. And unless you're hosting with Adobe and it's a priority one site down, it might be three weeks before you get a resolution to your question.
So that's where in some cases, it makes sense to at least have the services of somebody. Again, we do this, but to have the service of a company who can go and say, good. To be kind of a buffer between you and the sla of an Adobe ticket, like, oh, yeah, you do need to actually open an Adobe ticket with this. This is a product problem. Or, or let me just help you and solve it right now, because a lot of times what? Adobe will point back and say it's problem with your code. So, sorry.
And, and then there it goes.
[00:42:41] Speaker B: If you had to name that role, what would it be? It would be like infrastructure architect or engineer.
[00:42:47] Speaker A: Yeah. So it supports. Naming that role has been a problem. And I've actually tried and failed a couple times to put the right name on my LinkedIn when I was doing that as a role. But, but, yeah, but it's, it's a, it's a combination between. Yeah, infrastructure architect is one way to put it, but Am DevOps is another way to do it because a lot of times it just has to do because unfortunately, this is an unfortunate part of the way that the AM product is designed is that there's a lot of ways.
The way that you enter content, put pretty pictures into AEM, and the way that you change critical configuration is in the same interface and it's by design.
And that was one of the selling points of it at first. Everything's content, but it's also a problem. And so people can change a critical runtime configuration with the click of a button that can have huge ramifications and then untangling that is difficult.
So, yeah, so DevOps is a big deal. Turning this kind of thing into infrastructure as code is a big deal.
That also involves, though, lots and lots of monitoring expertise because of how complicated it is. There is a million different ways that it can explode.
And you want to have all of those on a graph.
This has always been kind of like my North Star, which has really served me really well. Is that with any site, any site does different things? Yes, it will serve pages, but it also connect to different things, publish things at different times. Sometimes it's got a commerce system, sometimes it's got a database, sometimes it's got this or that.
Anything that's super important to the site should be on a graph and you should be able to see its performance, how it is right now. And you should be able to see on that graph when it starts to keel over, before it keels over. And so, and if you can do that, proper response. Yes, so, and then, because then you can put thresholds on those graphs and get alerts where they matter because it's the traditional DevOps guy problem of, or the sysadmin problem of alert overload. And when it's always just pinging you with like, oh, hi, cpu this and all this, and you're just like, I just turn off those emails. You know, you go, why did it go down? Like, I turned off those emails?
[00:45:23] Speaker B: So we've, we've been running into that, but it's getting a lot better.
[00:45:28] Speaker A: Yeah.
[00:45:29] Speaker B: Customer DevOps situation there. So I can see that being a.
[00:45:33] Speaker A: Very commonplace, but that whole single pane of glass on that customer. Yeah, you know, that's, that's, that's one of those ones that just like, you just keep sticking stuff on there until it's, it's all on there. And that's where also the right, selecting the right tool that can do that. And this is one of these ones too, where, you know, on the subject of not being the sales buffer. Sales, you know, enemy. Enemy of sales guy. Monitoring tools. That is one where I had to say, guys, you got to spend the money on the monitoring tools. Select one that works. Here are the ones that I know that can work with your situation. You got to buy one because. Or you can just decide you're just going to keep going down because I've seen that too. And you know, we're like, oh yeah, we've got everything cached. It's all good. Like, okay, good. Well, every uncached page has been dead for 8 hours.
Did you, were you aware of that? You weren't aware of that because you weren't, you didn't have any of these things graphed. So some of these things are really kind of serious. And so it's really good to have, to have that role properly manned. This is one where. Go ahead.
[00:46:43] Speaker B: Yeah, I was just wondering, how important is it for the DevOps or the monitoring and support team to be AEM experienced, something of someone who might be migrating to Aamdeh? Would that DevOps team that need to be trained, is it going to be kind of a natural switch to them or.
[00:47:01] Speaker A: No, it's not natural. It's not natural. It feels very unnatural. In fact, most people who've done sysadmin. So there's some things where if you've done it before, you can get trained up fast. Like if you've done a bunch of other java application monitoring, you work with JBoss or Glassfish or Tomcat or solar. A lot of these ones, if you manage big arrays of those things, you can get the feel of am provided you've got a mentor, somebody who can kind of show you all the ropes. There is basically no am operational training, even from adobe. So there's, there's a couple pieces of it, but it is, there is one of the hardest skills to learn because you just basically have to have sites that go down for a long time and then you learn it. Unless you have, unless you have somebody.
[00:48:01] Speaker B: So you're going to be relying at least initially on the experience architect or the person who's been there, done that age.
[00:48:08] Speaker A: That's right.
Which is again, one of these ones where like, I love, I, I love the idea of working myself out of a job because I feel like that, that really provides a value. That is a value, not just making myself invaluable, that you can never fire me kind of a thing because that's the more traditional sysadmin. Like, oh, you can't ever you know, stroke my long gray certification, and I just. So, okay, yes, well, only I know about this, you know, where all the skeletons are hidden. If I can, if I can train up a bunch of sysadmins on how to be successful on that, then that, that's just super great because that is a hole right now in am world of being able to do that.
Also, in terms of, is this something that you could have in house?
Even if you've got a software as a service thing, even if you're using am cloud service, you still need ops guys. You still need somebody. Somebody who's got to be wearing that ops hat because, and I'm sure you've seen this on, on your project, too, is that it doesn't matter what SLA, such and such a company has on their service, it's going to go down sometime. There's going to be a reason why it doesn't work. Oh, yeah. We were up the whole time. Okay, then we rate limiting me. Oh, yeah. We were rate limiting you. Okay, good. It wasn't a ddos. We were, you know, you were down as far as we were concerned, you were down. Um, and so it's, it. So somebody has to have their eyes on it. Even if it's, even if each service supposedly has ops guys, it still needs somebody with their eyes on, on the pulse, their finger on the, you know, like, good. Is this patient alive? Is this patient?
[00:49:53] Speaker B: It needs to be up. You better be checking.
[00:49:55] Speaker A: Yeah, yeah, that's right. Unless you don't care. You know what I mean? Like, I mean, like, back to like, you know, the dentist office thing. If the dentist office website is down for 24 hours, you know, nobody's teeth fell out of their head. But, but if, if you're a bank and nobody could pull rates that entire day, those are how many customers just lose or how much customer, you know, reliance and trust did you lose when your own website went down? You're like, I don't know about that bank. I don't know about that as a place to put my money, you know, sort of a thing. So it's, um.
But, but, yeah, that, so that infrastructure architect, kind of the, kind of the AEM specialized system admin guy, I don't think that that is something that any company should require that they have in house. A, because that, because, like I said, because you can't train them, you can't make them, and there's not a lot of them. So, so there's not a lot of AEM sysops guys around. Um, they mostly work for Adobe. I would probably say 90% of the ones out there work for Adobe right now. So, um, so it's tough. It's tough. Um, so, so that's the kind of thing where, yeah, you could train up, you can train up guys or, or get, get up, get an architect who knows AEM to say good, you, you know, bring these guys up to speed, work with them for the next year, you know, and then, and then, you know, let's, let's, let's build some sysadmin guys out of all that.
Um, so one other thing before, I mean we're, we're, we're, we're getting toward the end here. One of the things that I want to bring up too is that there's, so there are a couple other architects and people that you commonly have on a project like this, which are their own thing. Sometimes they get kind of glommed into am, but they're not, and they're their own thing. For example, Adobe commerce or whatever commerce platform you happen to be using, you know, your magento hybris Spotify or, sorry, Spotify, Shopify, you know, stuff like that. So those have their own architects. They can know about AEM. You don't have to, if you're going to implement a commerce platform, you don't have to have AEM guys. Those people can work together. Your am architects can work together with whoever's a shopify architect that totally works. And there is overlap in both of those too. Yeah, you should know a thing or two about am if you're a shopify person or if you're a hybris person. And likewise you should know the basics of how SAP commerce works if you're going to be implementing, but you don't have to have, you don't have to have AEM on their resume.
Adobe experience platform is confusingly also, you know, people think it's the same thing as AEM. It's not its own thing. It's a whole customer data platform. And you don't need to have AEM experience to implement AEP and AAP can be implemented on things that aren't AEm. So that's its own series of experts. And most of the time if you get an AM architect, you say, hey, can you implement my AP solution? Most of them will say, no, I don't know anything about that. So it's a completely different product, completely new product. So that is that.
So that's the end of my list.
So I, now that we've kind of.
[00:53:30] Speaker B: Gone through the list, are there a couple like high level points for any of these roles where you'd want to compare and say this is what's going to lean you towards hiring a person? This is what's going to maybe lean towards hiring some consultants more temporary?
[00:53:45] Speaker A: Yeah. Yeah. Okay. All right. High level stuff. Okay. So one of them is that you, so every project to be successful that I've ever found. So even if, let's just say you're going to say, okay, good. We don't have, we just don't have the continuous budget and we can't get headcount to hire a lot of these in house because I've seen that you need to have at least a couple of people who really own the whole thing and own the relationship with vendors and really understand the site and how it's put together. These people have to be semi technical and because that sort of thing is required otherwise, because I've seen this too, where somebody says, all right, you're going to run this thing, right? And then they just say over to you, and then you don't, you don't have, you say, oh, what about this, what about your roadmap? What about this thing broke? Is this important? You don't, you don't have anybody who's really kind of holding that down and it's a reliable interface point to get everything done. So you have to have, you have to have, ideally people who are, who are holding that down. So that whole product and the whole product owner role has to be really sufficiently held for the size of the project.
Ideally. Also you have at least one person, even if you're hiring out most of your other stuff, at least one person who's an AM architect on your staff. Or is it, or is an Am lead on your staff and at least one person who is good at doing am design work on your staff because doing that sort of thing with sows, with outside companies all the time can just lead to stacked up user stores. Or somebody says, hey, I want this thing. I really always wanted the tab to have a offset color and a drop shadow. Can we just do that? And then if you're like, again, sorry, we have to wait until such and such a company has signed their new Sow, you're like, that's just a poor internal experience. Nobody likes that. So to have a couple of those people on site on staff who can do that sort of thing, and then you can plug in solution, architects, architects, more developers and so forth for big renovations where you're going to go and do either a big upgrade, a big migration, something like that, and then have those guys roll up, ideally again with teaching people how to fish instead of fishing for them as much as possible. Because again, these Am developers are very expensive.
They're tough to keep on staff because once you train up an AM architect and you started them off as a developer and now they're an architect, they're going to realize that they can get an architect's salary and then suddenly they're not looking for a company anymore. So that is, it's tough to keep a whole crew on staff doing that. There's a couple places that I've seen that have done that successfully and I'm just kind of like, you know, well, I mean, wow. Because it's very difficult. It's very difficult to keep that whole staff together on a site like that.
[00:57:07] Speaker B: Very expensive as well, I imagine.
[00:57:10] Speaker A: It's expensive. It's expensive. You have to have, yeah, you have to have, you have to have a whole that understands how much running an AM site costs and already have that budget. And they don't say, okay, good. So a couple guys. Okay, here we go, folks. You know, what's the running rate? Seventy five k. And you find out that some of these people are, you know, three or four times that and you're like, how much does WordPress cost? Right. And, yeah, and unfortunately, too, and I guess that's the, that's the other thing. Is that, is that one thing that anybody who's done this on a big experience platform, whether you're talking about AEM or something composable, like, like your strappy base site, there is, is, it's still, you still have the same number of problems to solve no matter what tool you're using. And, you know, whether you're using a basic tool that you hardly paid anything for and now you have to pay lots more people to try to glue it together or whether the tool is more capable, you're still paying people to integrate it. You just have to appropriately set your budget there.
Well, good. And unfortunately, I don't know that I totally answered the question as to, you know, things that need to be on staff and things to be in house, but, and I guess, like, like your architect depends.
Yeah, yeah, yeah. It does depend.
[00:58:44] Speaker B: Luckily, there's companies like ours or our companies you can come ask us and say, hey, we're staffing up for a big project. Who do we need? And we're the guys who can help you out with that problem.
[00:58:58] Speaker A: Yep, indeed, indeed.
Thanks for having this chat with me. I really hope this is useful, and I hope, I mean, if I have one recruiter that listens to this and is able to be more effective hiring, then that's great. And. But, yeah, we'll.
Maybe we should do our next one just centered around, all around the composable cms, because it'd be interesting to see how many of these roles switch and change when you're outside of Adobe World.
All right, great.
[00:59:34] Speaker B: Good.
[00:59:34] Speaker A: Well, then, thanks for listening and catch you next time.
[00:59:37] Speaker B: Thanks, dad.
[00:59:38] Speaker A: Thanks, guys.
