Interview: The seven deadly sins of cloud transformation with Andreas Söderberg, Riada - Now part of Eficode

Andreas (00:05): In larger enterprises, the thing with not approaching cloud mindset and being open to change, it's going to pull some risks internally that business units will work around you as an IT department and start looking at other solutions to actually solve their business problems. So in the end, it will work against you and not with you to be stagnant in your approach to the cloud transformation. Lauri (00:33): Hi, I'm Lauri and you're listening to the DevOps Sauna podcast from Eficode. All services go to the cloud. It's often a respectable target on its own. But many things can go wrong on the way there and not all of those are due to everyday circumstances. We decided to more deeply explore those times when we can't just blame the universe. We call them the seven deadly sins of cloud transformation. In this discussion, we review these factors in the context of Atlassian Cloud transformation. My conversation partner is Andreas Södergerg, Certified SAFe 4 Agilist and Atlassian Solution Architect. Andreas recently became an Eficodean as part of the acquisition of Riada. Let's enjoy the conversation. Lauri (01:17): This goes back something like 1,700 years. I went back and I tried to get to the bottom of the theme, like where is it coming from, and it seems to come from some ascetic monks in the third century in Egypt. We have these seven sins. So let me first just read them out loud what they are so people get the context. So, first one is pride. The second one is greed, wrath, envy, lust, gluttony, and sloth. We're going to go through them one by one. And I'm going to first sort of read out loud the hypothesis that we believe inside a given company undergoing Atlassian cloud transformation, and then we'll discuss about it, but we don't leave people hanging. We don't just talk about these sins, but we talk about how to go around it and how to get better at that. Andreas (02:16): Yeah, very excited. Lauri (02:17): And the first one, what we started was pride. Andreas, we tried to think with you, how is pride coming across in the cloud transformation? And we concluded that it's the behavior of not asking for help. And if we think, how is this situation or what is the extemporary situation that could happen is that the company or somebody in the company have been asked to investigate the possibility of moving to Atlassian Cloud and they are excited and eager and of course they feel they are related to the company and they are full of pride to get on this mission with their limited knowledge of the environment. Lauri (03:01): I think this is also the place where there's a very old expression called Dunning-Kruger effect, which is that people who don't know that much tend to overestimate how much they know. And then people who know a lot, they tend to underestimate what they know. So basically the question is, you have a big feet ahead of you, how hard could it be? And that's a situation where this pride, it can come across. Let me stop there and ask, how do you see this pride showing up in the customer situations? Andreas (03:37): As I've been around for a while now, I've seen a lot of people dropping into different deliveries from time to time. I've seen that one of the personalities that could go in there is usually someone that has a lot of like hobby knowledge on the platform. They are really eager to get started with something and they are part of the Atlassian community. And as we know, the Atlassian community is very strong. There's a lot of champions in there that really like the products and they believe that they can do a lot of stuff and they do a lot of good as well. But I do think that one of the shortcomings there is that they might believe that they know everything. So when they get started, they have this mindset that I can implement pretty much anything that I've set my mind on. This could lead to a lot of dangerous situations that it's not only about the configuration as such. It's also about implementing the right methodology, getting the right set up in the platform and also following the guidelines of these methodologies. And I think there is, it's one of the things that you might fall short. Even though you know the platform and you know how to configure it, you might not really know exactly how to get your mind around the methods, so to say. Lauri (04:51): Yeah, something that I decided to explore myself as a hobby was to do the Atlassian server and data center certification, the ACP-100. I then learned that there's also a certification for cloud. Like how much transferable skills are there if you know the data center or server very well and then you go onto the cloud transformation. Where are these pitfalls where not asking for help becomes a problem and what should you watch out if you feel that you are a veteran in the Atlassian stack? Andreas (05:31): That's actually a very good question because I've been doing the ACP-20, I think. That's the Atlassian Cloud one. I've been working with the server versions previously, so I know kind of the differences here. A normal situation would be that you believe that it's a one-to-one transformation pretty much. You're just moving your stuff into the cloud. But given the actual setup and how it's built in the Atlassian cloud environments, you're bound to have some things there that are not matching with what you're expected to. So the normal situation here would be that you're starting to move things up there and you realize that the whole AV structure, like how things are set up with the users, is completely different from how it is on server. And this might cost you a lot of headaches and problems. Andreas (06:20): Also how you run the sites. You can run multi-sites underneath one organization, for instance. This is also something that it takes a lot of knowledge to get your head around them and to realize that what is the best setup for our company, because you might have like a ITSM solution where you only want maybe a JIRA service management, and then you want Confluence for instance to be able to run this service desk set up with a knowledge base. That might be something that you want to keep separate from maybe the DevOps organization where you actually develop things and use the continuous integration. But it could also be so that these need to be very close together and they need to be able to collaborate. In that case, it would be better to maybe run this on the same site. So there are a lot of things to consider here and it's not a one-to-one situation here. So you need to be aware of that before you start moving your stuff into the Atlassian Cloud environment. Lauri (07:17): Right. So long story short, we don't know what we don't know. And if that's the case, then things look easy until they are not. And we might think that they are easy because we just don't know enough of it. Interesting that there are so many things to consider about what you said there. And this is a nice bridge to our second sin, which is then greed. And as we were thinking that through, we concluded that in the case of Atlassian Cloud transformation, it means trying to do too much. Let's look at the hypothesis that the company has. Like they are feeling, so to say, the wind in the sail, things are running smoothly. They see increased demand from the organization to move further into the Atlassian toolset. Lauri (08:03): And these people who are doing the transformation, they become recognized as people in the know of the Atlassian stack and that it starts to go to your head, so to say, which is now the greed that, okay, the configuration skills and the charismatic personality can deceive. But then the greed comes in the way that you think that, okay, I know how to do it and I have done that, so I can try to eat the elephant in two big pieces. What do you think about this sin, trying to do too much? Andreas (08:41): I think that this could be good or it could be bad. It all depends on who is the driver in this situation. I would say if you have the proper amount of knowledge, it might be a good thing to be pushing towards getting as much as possible into the Atlassian ecosystem. But if you don't really know about the limitations about the platform, then you're bound to have problems sooner or later. So I would say maybe the main thing here is to be hands-on with the implementation, but to maybe hire someone to help you out if you're not 100% comfortable with the setup and exactly how to configure it. Andreas (09:17): So, a good thing to take away from this is probably that you should know your limitations and you should not be afraid to ask for help if you're coming to a situation where you're not comfortable anymore. Then you should probably get someone in there to help you out. Otherwise, you're bound to end up with a big technical debt sooner or later. I guess there's also suits into the other sin of pride in a good way, because this is also related to pride with greed combined to do this, I would say. Lauri (09:49): When you have looked at successful transformations and you think, because there are two ways to look at this. One is trying to do too much in absolute terms. And then one is trying to do too much yourself. They are not the same thing. When you think about successful transformations, can you give some yardstick or some good practices around what areas people should focus on themselves versus then asking for help so that they get more done in the same time or that they would really focus on their own strengths and let somebody else handle the ones that they probably don't have time for, or they just don't happen to be so good at that. Andreas (10:28): Of course. I am actually working with, there's one customer that has a very good setup where they are the application owners, of course. So they are in the driver's seat in terms of managing the change here and applying the Atlassian tool sets in the organization. And what they do is that they have taken a step back from the actual implementation itself, but what they are doing is they are still with us when we are implementing the solution with the different teams. So they are listening in, they're weighing in on different aspects of how they would like to implement this solution into the organization. Andreas (11:04): They rely on us as a good partner, but they also feel like they have full control over the situation. So we are not the drivers here. We are executing based on their needs, but they get to have an opinion in all situations. We go to them for ballparking, so to say, trying to find a good solution for them. Then we implement based on their command pretty much. And I think this is a good setup because it gives them the range that they need to be able to be on top of things. But we are also implementing the best practice solution for the organization, which also leads to better stickiness. The teams are feeling very good in the tools and you get to a very good situation later up the road, so to say. Lauri (11:50): Yeah, would you say that it is best when the customer has the lead, and then whoever joins to help them is basically then part of the team? The customer would always hold the reigns of the project scope and project schedule, so to say. Andreas (12:04): Yeah. Lauri (12:04): Yeah. It makes sense. Andreas (12:06): That would be the perfect way, I think. Lauri (12:07): Yeah. I remember one expression from our earlier podcasts. I think it was our CTO, Marko, who said that oftentimes we believe that things are hard to do, but we manage to do them quickly. Whereas it is often completely opposite that the things are actually not that hard. Like when you sit down and figure them out, they're not that hard. They just take a long time. And the beauty is to face those problems with the adequate respect and the adequate skillset, and then reserve enough time with that, which goes very much along the lines of what you are saying, which then takes us to the third one, because I'm thinking that if you try to do too much and it's not going where you want, you might fall victim of the third sin, which is wrath. We thought about that and we felt that it comes through when you're trying to force the chains. Lauri (13:04): And here the hypothesis is that the company and the people there have converted to believing that this cloud transformation is a good thing and they have seen with their own eyes what a cloud first strategy can give them. But they are also painfully aware of the cost of ownership. As said, as a wet blanket over the budget every year. And now the belief is that the Atlassian Cloud is a perfect fit and people want to have it sooner rather than later. But now, because there's a clock ticking and every day you are not getting to where you want, you're spending money on something you don't want to spend. So you are growing impatient. And then when you start to force the chains, then that's when wrath steps in. What do you think about this? Andreas (13:59): I think this is probably a spot-on scenario for many companies, I think. You're feeling the peer pressure from your peers. They want you to do something and they want you to act on this and they want you to remove a lot of the cost of ownership that you have today, maybe. And they are also aiming towards maybe being more of a cloud-first strategy from what they're doing today. And as you embark on this, you might feel like you're forced to push people into the solution instead of helping them into it. I think that that's actually a big difference. I mean, forcing people into it would be that you're just migrating everything from a current solution or a current setup into the Atlassian tool-sets. You're not really accommodating the teams, what they need, you're just pushing them in there and they are forced to work with your very stiff and non-agile workflows. Andreas (14:51): That would probably lead to people being bitter in the end and then they would start looking for other solutions and they will start bypassing you because they don't feel like you're supporting them, right?. So I think the best take of working with this situation is to start change management instead, and use that approach to get to a point where people actually feel like you're accommodating their needs, setting up a good structure that actually helps them in the long run. That will also create some stickiness and they would create a movement internally that people are starting to work in this way and you are just giving them the tool-set to do it. So in the end, I think that the best solution here is to just help them on board and try to be hands-on with them, try to listen to their needs. And that's the way to really champion this product within your organization. Lauri (15:44): Are there some things that potentially can cause headache when you... I mean, irrespective of adopting a change management approach where you build pull not push and then sort of letting people grow into the solution with you. Either way, what are the headaches that you should be aware of that might be ahead of, irrespective of your approach? Andreas (16:10): This is also a good question because it actually fills a topic that is very, very active right now, which is application mismatch, for instance. When you're working with a server version of JIRA, and you're looking to step into the cloud version, you're bound to have some things there that are not one-to-one as we talked about before. So it could be that when you're forcing a ITSM solution into the Atlassian Cloud environment, you're not maybe thinking about all the aspects that you might lose when you're doing that. The first thing would be like, are you really looking into the stuff that will be lost when you move in there in terms of functionality. Andreas (16:50): Also like is really one-size-fits-all a good approach here. I don't think so because all teams are different. Even though you might be working for a consistent way of working within a company, you need to be aware that all teams are different. There are different engineers in every development cycle. There are always people, and people need to have different solutions set up to accommodate their needs. And I mean, you need to also think about the aspect of a group of people that probably have different experiences from working with these tools and they have different preferences. I mean, given six people may be in a development team, that gives you a lot of opinions on how to work. And then it's easier to work with these six developers and try to get it right instead of trying to work with the whole company and get it right. So try to do it that way instead, and I think it's going to be a better solution for all in the end. Lauri (17:48): Yeah. I remember from some other IP software domains that in those cases when they have gone from on-premise solution to the cloud solution. It has been more of refactoring the business process. And maybe not even refactoring, but bringing it up to date; because if you have been in one way of working for five or 10 years, the world has moved on and maybe something that used to be modern five or ten years ago in terms of business process is no longer the best you can have. Lauri (18:24): And it could be that this wrath and forcing the chains can take a different meaning, which is that if you are a business owner, you are trying to force your new solution to do the same old business process that you had before, but instead you should think it open-minded. Okay, how much the world has moved on during which I have not moved on? And then how much refactoring of the business process I should be doing to really take advantage of this opportunity? I mean, genuine question, how much is this relevant in cloud transformation with Atlassian tools? Or is this just another example from some other domain that it doesn't apply to Atlassian case? Andreas (19:08): I think it's very accurate what you're saying. I think this is a normal scenario and, yeah, I would fully agree with your previous sentence. Lauri (19:17): So if you are currently committing this sin, which is basically do a push approach or not adopting change management, or just trying to force the chains, what's the best way to approach that differently? Andreas (19:30): Yeah. If you're already into it, I think that you would need to take a step back pretty soon and start looking at this situation from a more holistic view. Maybe start asking yourself what things are working and what is not working. You might see that some teams are rebelling a bit. You might see that they are looking into maybe other tools because they feel like your tool is too narrow for them, for instance. I would say maybe like start interviewing the teams that are screaming loudest because of your actions and try to start to accommodate their needs and see if you are able to create a more balanced approach to the Atlassian tool-set. Andreas (20:07): I mean, given that everything is well here, you would probably end up in a situation where you see that a lot of more teams are going to be wanting to migrate to the Atlassian tool set if they are working somewhere else. It could also be that you realize that teams are feeling that the tools are a better solution for them, and they would be more productive and you would see that stickiness of the tool would be very close by if they change their mindsets towards it. Lauri (20:38): Yeah. So find advocates and then work with them and sort of try to accelerate the natural speed of things that are happening, instead of trying to fight back the resistance. Lauri (20:53): It's Lauri again. Atlassian recently announced changes to simplify their server and data center offerings. We invited Holly Tompkins, Enterprise Cloud leader from Atlassian, to unpack these changes. Holly is accompanied by Artem Chatlikov from Eficode. You can find a link to the recording of this webinar in the show notes. Okay. Let's continue. Lauri (21:17): So that takes us to then the next one, envy. I think we struggled a little bit when we were trying to find an example here, like okay, what's the good place there. But I think it's something to do with holding onto your own conceptions or holding onto your own data even. So if you are not one of those people that were described earlier, but you rather are skeptic of the whole cloud-first movement and believe that the internet is not secure enough unless you are in complete control, and then the security ops team praise you for that belief. Lauri (21:54): And I think we can find some examples where it is true that you don't want to put your data to the internet. But yeah, some of these people have the feeling that their key chain has keys to all of the locks and they have been the go-to person for as long as they remember and from this safe haven, and they are looking towards the cloud products in envy, so to say. Like nothing is bigger than your own premise belief, not even the welfare of your company. How do you approach this sin? Andreas (22:27): Yeah, I think like this is a hard nut to crack because it's usually a personal preference and it's also something that lies within the company's culture. I think this is something that requires a fresh set of eyes. I mean, someone that comes in from a cloud-first strategy approach and that can shed some light on this. I would say also that it's a bit of a thing of the past to be looking at a situation like this. I think many companies are more progressive than this. But I also realize that some companies are bound to restrictions and regulations and can't really make the journey to a cloud solution, or they believe that they can't do it because they don't really... I don't think they are quite sure of how to take the proper discussion around this internally. Andreas (23:15): I do think that this is a spot on discussion and what I see from my understanding the clients that I've been struggling with on this topic are usually bigger enterprises, organizations with a lot of people and a lot of data and maybe data classifications as well. Or maybe the lack of data classification, which means that you really don't know what type of data you should put in a cloud solution, so to say. Lauri (23:41): So this is a combination of preconceptions of people and, yes, maybe the only way to change them is to bring more points of use. Are there some pieces of information, like if we believe that when you know more, then you will change your opinion. Are there some pieces of information that you would advise people to take a look at simply to get more informed on this matter? Andreas (24:04): Yeah. I think one way to do this would be to maybe read up on the actual solution itself. And then what does it actually do in terms of security? Then I would go to atlassian.com/trust and read up on this because they have a lot of certifications on their products. There is actually a lot of stuff that you can do within the Atlassian platform, the Atlassian Cloud platform, today that might accommodate the need of data regulation, so to say. One of them would be data residency, which previous has been available only for the enterprise solution, but quite recently Atlassian announced that they are going to put this feature out to all of the product plans, which means that then premium and standard are going to be included in this. This pretty much means that you will get a graphical interface where you would be able to select from a dropdown list where in the world you want your data to be located with the Atlassian products. Andreas (25:01): And of course this corresponds to the AWS solution which Atlassian Cloud is based on. So where you have AVS hosting locations, you will be able to select from this list. And I think this would actually change the situation for a lot of like Swedish companies or Nordic companies which are a bit bound to regulation, as we know very well here. I mean, if that doesn't do it for you, of course you can use some kind of hosting service. Eficode can probably provide something in terms of getting a JIRA server or data center solutions set up in a cloud solution for you, but it will still be considered as on-prem since you would be holding the data. It would still be something that you would own, so to say, and you would not be relying on Atlassian all the time, which you will be doing in the Atlassian Cloud solution. Andreas (25:54): Yeah. So more like a managed service, that, okay, it's not the Atlassian's Cloud solution, but it's a traditional product solution, but it would look for a customer as if it was a cloud. Andreas (26:09): Exactly. Lauri (26:10): What about then the internal discussion? Like, okay, this is one way to look at it is really go deep on the capabilities of the product and try to understand more. You also mentioned the regulations or that some companies just cannot do that because... I mean, I can understand that the insurance and financial sector might be one of those, but how to stimulate the internal conversation to at least start to go in the right direction here? Andreas (26:36): Yeah. So I think what a lot of companies are missing out on is that they have no real strategy around their data classification. So I think a big step towards forming your cloud transformation is to start looking into data classification. Like what type of data do I have currently in the company? And start defining them. Like what is a secret piece of data and where can this be stored? Try to keep this as clear as possible within the organization. It should be advocated all the time. When someone new steps in, it should be crystal clear like this piece of data is a part of this classification, which means that I can't put it in this product because it's not secure enough. Getting that type of mindset into an organization would give you a lot of movement into Atlassian Cloud and any type of cloud product, for that matter, because you would know what type of data this application will be able to contain. Andreas (27:33): And I think that many of the companies that I've been talking to that have this specific problem right now, they don't have a clear idea of the data classification, or they just have not put a data classification on this product that's in the cloud. A good piece of advice here would be to maybe nail on a strategy on that, like what type of data are we able to have on the platform. And don't be afraid to put your foot down and tell people that this type of information is not something that you should store in here and you should not use it within the Atlassian ecosystem. And that would give you a lot of movement towards the Atlassian product and people would be more aware of what information they put in there. So you're bound to have a better solution and not to be questioned by the SecOps team, for instance, that are a bit afraid of what this solution might bring in the long run, so to say. Lauri (28:28): Yeah. In the behavioral economics or psychology in general, there's an expression of status quo bias which pretty much means that people have a preference of doing nothing over the current situation. What are the long-term consequences if people don't take action moving off on-premise solutions? Andreas (28:52): This is also a good question because it might be a bit unclear like where this is going to be within one or two years, or ten years ahead if we're not doing anything at the moment. And I think like the simple reality is that sustained reliance on premise hosting will challenge the business to be agile and responsive, which will be struggling to keep the lights on pretty much. What we mean is pretty much that in the end, it will be really hard to keep the agile and responsive mindset in an organization where you live as if it's the stone-age. So you need to be positioning yourself and your company in a seat where you actually take charge and where you try to be the leader of the change instead of being there in the background doing your thing as you've always been doing it, not taking any risks, not taking any chances, which you should do, but you should also know about the risks and what those are and how much these weigh in the long run. Andreas (29:50): I think in larger enterprises, the thing with not approaching cloud mindset and being open to change, it's going to pull some risks internally that business units will work around you as an IT department and start looking at other solutions to build there to actually solve their business problems. So in the end, it will work against you and not with you too to be stagnant in your approach to the cloud transformation, not to mention that it will be more and more expensive each year that pass by and you'll probably be left without R&D because the products that are on-prem today will probably not be as advanced as the ones that you will have in the cloud, so to say. Lauri (30:33): Yeah, in the product business, there's an expression that companies should cannibalize their own products before some of their competitors cannibalize their products, and it may be as much true with the IT departments, that IT departments who are responsible for services should always strive for better ways of delivering those services. And so to say cannibalize their own services before somebody else does it for them, but that eventually that is going to happen. Either you put so much IT policy around that R&D teams cannot go around it and then they will stagnate, or that you don't put those IT policies in place and then they can go around you, or you adapt and you try to find the best solution day in and day out, which brings us to our next one. Lauri (31:23): And this is almost, you could imagine that this could be a continuation to the previous one, which is lust; and in other words, letting things happen on its own, just lay on your laurels. But we have a slightly different hypothesis here for last, i.e., letting it happen on its own. So imagine that you are an appointed application manager and responsible for the products and the products have been around for a long time. Teams have come and gone pretty naturally, but the Atlassian environment has stayed and grown into a scrapyard. Some of the more progressive teams have already launched separate cloud sites. So pretty much what we've discussed already, which is running on a monthly subscription. Lauri (32:05): Now, from the application managers perspective, they are paying for it, but they are not part of it. They continue to be in too much love with their own product. And they mistakenly trust that the change is best handled at its own pace, as opposed to actually embracing the change and letting it happen rather based on what you do instead of irrespective of what you do. What do you think about this? Andreas (32:34): Yeah, I think like as you pointed out, this pretty much suits into the last topic in a very good way. I do think the best approach for an IT department is to be in front of these efforts since IT bears the responsibility to ensure that the technologies are integrated and managed securely. This is like the opposite of what lust is doing to you. When you're not in the driver's seat, you're just letting stuff happen. And I've seen a lot of situations where companies are actually doing exactly the same. They have an on-prem solution or they have not really enforced what they want, which means that the teams have started to bypass them and they've set up their own Atlassian Cloud environments, adding a credit card in there and expensing it every month without your knowledge. Andreas (33:22): And you're sitting there believing that your solution is probably the one that people are working with, but you can't be sure because you have no subtraction, you know that maybe users are not requesting access anymore in the way that they previously did. So to really ensure that you are in the driver's seat, you should try to maybe ask people around the office like what would be the best possible scenario, is it to move to the Atlassian Cloud environment? And naturally you would get some kind of response from that, even if it's, okay, we might want to stay on-prem. If that's going to be the thing that happens in the long run, you might as well just try to take control of the situation and then try to be the one who's driving the change instead of standing there beside and looking at people while they do it. Lauri (34:08): How normal is it that this happens? You said that you have seen it happening, but is it common or is it uncommon? Andreas (34:13): I think it's very common because Atlassian Cloud is such an easy thing to set up. I mean, that's one of the things, if you compare Atlassian cloud to maybe ServiceNow Enterprise Service Management, you know that setting up an Atlassian cloud solution is something that you do within five minutes, and that's no joke there. I mean, it's super easy to set up an Atlassian Cloud environment and to get started, which also means that you have a 7-day trial at first, and then you can prolong this trial if you want to, which means that there's a lot of teams that start poking into this and they don't need to inform their manager we need to get this set up, they can just do it and they can start working with it. And that also gives you kind of a loophole for people to start using. Andreas (34:59): What you will see, probably, if you're on an on-prem solution today, you might see that some teams have already taken this step and started working with a cloud solution like Atlassian Cloud, JIRA for instance, without your knowledge. So I think this is a very common scenario and what you're bound to do when you start taking control over the situation is that you will start to consolidate these sites and try to manage them into one single site, merge them together. This might be something that causes us a lot of headaches and it might be something that you should do it together with someone that has knowledge, a good knowledge, about the platform and how to do it in the best way. Lauri (35:37): Yeah. I have not done it for Atlassian Cloud, but I can completely believe what you say about getting it up and running quickly, because JIRA, our server, was as simple as downloading a Docker container and getting a 30-day trial license and you were up and running in no time. And I believe that is harder to do than Atlassian Cloud set up. So I'm taking your word for it there. We have two remaining. The second to the last is gluttony. I think if we go to a dining place to have a good buffet, I think we all know what gluttony means. But in the case of Atlassian cloud transformation or cloud transformation in general, what we felt it means is accepting scope creep. Lauri (36:23): So if you are a proud manager and owner of the Atlassian tool set and you have launched a task force to focus on migrating to the Atlassian Cloud and improving your strategy with the products, you maybe have done already what you already advised is hire people to lead the work and help you. You are making the progress. The budget has been breached, which always happen, and the task list has seemingly grown rapidly, but you still feel that you are sort of on top of it. And the team is telling you that they are almost done as they pile more work into the backlog. So this is where the manager of the tool set feels the gluttony, that they are making good progress and they accept the scope to just keep up and they'll let things continue and they sort of wait and see where they lead them. What about this one? Andreas (37:21): Yeah. I think this is also a very normal situation. You're buying a concept pretty much. You're not really specifying work in the status that you might be doing because you might have some limited knowledge about like maybe you want to set up an ITSM solution, or you want to get DevOps into it. You want to have a good setup, but you don't really know exactly how to do it, which means that you're relying 100% on a consultancy firm, or you are relying on your staff to get this set up. But given that you are not really comfortable in the driver's seat, you might be ending up with a much larger solution than what you asked for from the get go, not to mention that Atlassian Cloud has a lot of applications in their system, which means that you can pretty much add functionality into the products by installing these third party add-ons. Andreas (38:17): I mean, these cost money and it's going to be something that comes back to you in a negative way if you're starting to accept that these solutions need this type of add-on. You need to think bigger than that. You need to be on top of that when you have these discussions with the team, so to say. In the end, I would say that maybe the best solution here is to maybe not purchase a solution or a methodology, so to say. You should be purchasing specific work at a specific timeframe and you should keep the consultancy firm or the people that you're working with to that timeline to make sure that they deliver what you agreed upon from the get-go. Lauri (38:56): Yeah. And the good thing is once you get the first project done, the second project is always going to be easier because there's some, let's say, initial effort that needs to happen before you get it up and running. But once you have the basics in place, like administration facility or authentication or login, or like all of that, you probably don't have to spend as much time with them as opposed to specific areas regarding their functionality in JIRA service management, or maybe extending from JIRA core to JIRA software, or whatever expansion that is going to be. But I think it's a good advice. We've come to the last one, and interestingly enough, this is the name of the seventh deadly sin but it's also the name of an animal. And if I think about it, it's so descriptive why that animal is called that. Andreas (39:50): Definitely. Lauri (39:52): The sloth, which is this three fingered sloth, the animal that moves around almost like in slow motion in the real world, which we think it's, you're just not taking action. Imagine that you wake up in the morning, you come to the office, you get to the water cooler, maybe you get your coffee, you read the announcement of, well, we have seen the decommissioning of the traditional server and self-managed products. And then you're thinking, okay, we are on server, what should we do? These thoughts are sort of getting to your attention and you should be taking action by now but okay, what should I do? I should take more time, think about it. And it's like, there are so many reasons why you wouldn't do that. But this is what we said, the sin of sloth allows us to push the thought away and go to the next email and forget about it once you get another signal saying that you're probably already too late. What do you say to this? Andreas (40:56): Yeah. I think this might be like the situation that many companies were in during the afternoon when they got this message. Some companies had already invested in the server products and they thought that this is a good idea because now we can be on on-prem, if you want to, and we can grow and expand the solution. And to their fears, this happened. Atlassian announced that they were going to decommission the server products. And I think many companies got disappointed of course, and they felt like, okay, what are we going to do now? Is there anything that we can do here? Is there any solution that we can set up. Given that data center is a lot more investment there in terms of money, you are bound to start thinking about that as well as like, is there a technical solution that might be replacing this in a good way? Andreas (41:47): So you'll probably be in a situation where you need to choose, either I go to Atlassian Cloud or I will go to Atlassian Data Center and I will continue on-prem by using the Data Center solution. But I think many companies are in that situation and I would say the best advice there would be to start planning and look into what is the best course of action here. Are we ready to move into Atlassian Cloud and like is the products that we have today, I mean, given all the applications like our third party app vendors, are they translatable as well as the products in the cloud solution from Atlassian, and start looking into this and try to map the situation. Andreas (42:31): And if you can't do it yourself, I would totally recommend that you bring in some expertise here to help you out because it's not only like it migrates and then it's done. You need to be aware of that. Maybe like 70 or 80% of the work of immigration to Atlassian Cloud would be the planning and getting the planning in place to actually be able to make the move. So, yeah, there's a lot of stuff that needs to be done there before you can actually make that happen, so to say. Lauri (42:59): And this points back very conveniently to the gluttony acceptance scope script, and actually not the sin but what you advised there. And your advice was to buy a specific outcome according to their specific schedule. What I am listening to you now is: planning gave me an outcome. It's like I want to buy a plan and that can perfectly be an outcome. It's like, okay, let's get somebody in who have done this, let's start with more than the number of times we have done it because we haven't done it once, as a customer, but there can be somebody who have done it 10 times like you, and then they can engage in an effort that basically delivers your plan. Lauri (43:42): And that plan, again, going back to everything else we had discussed, it takes this aspect into account that you are not forcing the change. Like you are not trying to, as we say in Finnish, push with a rope, but you're trying to get people along you. You take specific considerations regarding the data location. You scope it in such a way that you are not trying to do too much. So it all boils down to piecing the puzzles in small enough sets, then you can start doing it. Like, okay, let's do plan first. Then let's do the easy parts then. And then let's sort of get to the more and more complicated scenarios and projects then one by one, something like that. Andreas (44:30): Definitely. And I think the thing that maybe a consultancy firm as Eficode can bring to the table here is that we have the playbook on how to do this and we know the fall pits and we also know which things work and which don't and things that you need to consider that could work out this scope creep that we talked about previously. And given that, we have this information, you are bound to have a more cost-effective solution than trying to do it yourself. And also you will have something in place within the timeframe that is reasonable instead of having someone else do it internally as a thing that they're doing in their free time pretty much. So yeah, I would say that the best solution here would be to maybe hire someone to do the work, because it's not as easy as it might sound like when you're thinking about it. Lauri (45:20): Yeah. And it will probably take longer than you expect it as an entire project. I mean, you can slice it down and do the small things fast, but then to get to the other side, it's more important to start running them than try to think about the finish line. Andreas (45:35): Yeah. I think one of the most important aspects here is the applications, the third party applications that are currently not a one-to-one situation. Not all of them, at least. So it means that moving in there, you might end up with a bottleneck where you have some functionality in the old solution that you're working with frequently, and that solution is not transferable to the Atlassian Cloud solution, which will leave you hanging out of a very uncomfortable situation if you're starting to move there without having found these things when you're doing the discovery in the planning phase, so to say. Lauri (46:11): Yeah. Which takes us quite immediately back to the first sin, pride, not asking for help. Andreas (46:17): Exactly. Lauri (46:17): What we say is, ask for help. Andreas (46:20): Yeah, definitely. Lauri (46:22): Yeah. With that, we have come to the end and I very much thank you, Andreas, for joining. This was a very, very interesting conversation. Andreas (46:28): Thank you. Yeah. Good subject. Lauri (46:31): Where can people find you? Do you hang out on LinkedIn or Twitter or what is your typical defacto social network where you hang out. Andreas (46:39): I hang out on LinkedIn, so I can be found there. I am working with Eficode right now, so I can be found there as well. If you're interested in knowing more, we can jump on a session and then talk about it and see where you guys are at and, yeah, the best course of action to come. Lauri (46:54): Awesome. Thank you very much. Andreas (46:56): Thank you. Lauri (46:57):