 Thank you for joining us for Symantec from early adoption to the latest Drupal innovations. Symantec was one of the first Fortune 500 companies to adopt Drupal a little over 10 years ago, and today they continue to innovate with Drupal 8, and that's what we're going to be talking to you about today. My name is Michael Myers. I started the first venture-backed Drupal-based startup company, launched the first Top 100 website to run Drupal, and the managing director of Tag1 Consulting. Few organizations have done more for Drupal in the Drupal community than Tag1. On staff, we have Drupal 6, Drupal 7, and two Drupal 8 maintainers. We support and maintain over a dozen core subsystems, including views, themes, big pipe, and cache, as well as many others. We maintain Drupal.org on behalf of the community, and so in addition to our full stack development for our own clients, given the depth and breadth of our Drupal expertise, we often partner with hosting companies and platform providers like Pantheon and Contegix, as well as other agencies like BKJ Digital, where we provide specialty services like architecture, security consulting, gatekeeping audits, performance tuning, and DevOps, and so we're going to talk about some of that today. I'm joined on stage today. Please welcome, join me in welcoming Amy Johnson. Amy is a senior leader who spent over 20 years in the high-tech industry managing cross-functional projects that address both customers' needs and yield financial results. She started her career at Hewlett Packard, where she worked in the printing business and helped create a legacy of world-class products, including her analysis on their entry to the 3D printing market. Amy is the senior marketing manager at Semandic, where she's responsible for worldwide marketing programs, including the online community development for cybersecurity programs and solutions. Amy is certified in agile methodologies, and she applies agile to business, as well as her work with the third-party vendors and partners that work with Semandic and the projects that we do together, and she's the business owner for all the websites that we're going to be talking about with you here today. Joining Amy and I is Kevin Millicam. Kevin has building communities for over 20 years, the first community that he built online was called Devel's Solutions for GroupWise Community, and the first CMS that he used was FileMaker, which predated FileMaker Pro and puts things into context, I hope. When Kevin discovered Drupal 4x, he never looked back, and he's built many applications and communities on Drupal over the last 15 years. Kevin is the co-founder of BKJ Digital. It's a full-service web application development company that helps you with everything from designing your application and the strategy through the build, through support and maintenance, covering the entire lifecycle of your application. Their clients include Veritas, Bluecoat, Dell, and Semandic, and they've been working with Semandic for over a decade now, and I think that speaks volumes to the quality and level of service they support. It's a very rare occurrence, I think, for an organization to work with, someone like that for 10 years, so that's pretty amazing stuff. Before we begin, I wanted to give you a quick overview of what we're going to be talking about today. In brief, Kevin and Amy are going to talk about the history, why we chose Drupal, and I want to point out that that's still relevant to what we're doing today and why Semandic still continues to choose Drupal when they do analyses for their website, and that's really what we're going to focus a lot of our talk on today, which is our ambitious digital experiences. What are the challenges that we face, and how are we solving those problems through technology with Drupal and the Drupal platform? But being successful with any organization, but particularly in a Fortune 500 organization, goes well beyond technology, and Amy is going to talk to us about how you get buying and support in an organization, how you work from everyone, from your executive team through to your external third-party vendors to gain consensus and drive success with your products. And so with that, oh, and lastly, we're going to open it up to some Q&A to the audience, we should have some time for that as well. So with that, please welcome me and joining Kevin, who's going to give us some of the backstory. Thanks, Michael. So a little bit of the history of how we all got involved in this system. Ten years ago, we had to build a community for a company called Altiras, a small company called our community, the juice, which was kind of the fun hip way to do it, and everybody went to the juice when they wanted product information or support, and actually had quite a following. When we got rid of the juice, there were a lot of unhappy users, but Altiras was acquired by Semantic ten years ago, and Altiras saw some of the beauty in having a community, or Semantic saw the beauty, and they wanted what Altiras had. So they talked to us about doing a community. Kind of like the juice, but they were corporate, so they didn't want it to be called the juice. And we talked to them quite a bit. We quite honestly didn't think we were going to get the contract because they had, you know, 17,000 employees, and half of them seemed to be IT people with web expertise. But like a lot of organizations in the world, big organizations, let me go back one here, a lot of big organizations in the IT world, their IT department was very busy. I mean they had two years of backup, two years of projects that they needed to work on. So Semantic decided to hire our firm to temporarily put up a website, a community. That community would stay up for 90 days, and when they talked to us about it, they wanted it up in 90 days, and they wanted us to manage it for six months. And then they said at the end of the six months, we'll kind of morph it into our IT people, we'll hand it off, you guys can go do something else. And we were thrilled, and we took it as an opportunity to kind of get to know the IT people, and to build relationships within Semantic. And you can kind of see our evolution here with the bottom left-hand corner was Drupal 5, that Altura site that we built, the juice. And the upper right-hand corner is Semantic Connect, is what their community ended up being called. Connect now has 500, 600,000 users, and about 600,000 posts. So it's a very active community. It has a number of content types, articles, downloads. There's an area where users can suggest features from new products. There's a videos area, and quite popular, and forums, of course, that's where they get a lot of their support. There's also a rewards program built into that. So as users come and answer other users' questions, they get reward points and keep some coming back that they can cash in for Amazon certificates, so on and so forth. Anyway, as the story goes, here we are in 2018, and that six-month probationary period is fast, and we're still working with Semantic as one of our very favorite clients. So I guess the moral of that story is we kind of got in because we were the right agency at the right time, in the right place at the right time, and we stayed with Semantic because we worked very hard to build relationships. We worked hard to augment and accelerate what the internal IT people are doing and to really work with them and help them rather than fight against them. So as I thought about our ambitious digital experiences, I thought, what could we portray to you folks? I don't want to go through a list of things that we've done, but maybe a few things that you might be able to take home and go, I might be able to use that. That's kind of a cool idea. Maybe we could use that in our own systems. So we're going to kind of flip through a few of these. We're going to start with Amy, and she's going to talk about the blogging platform that we built for Semantic. Thanks, Kevin. Hi, everybody. So Kevin alluded to, we just recently brought up a new blogging platform at Semantic. It is our corporate blog platform, and of course, the back end is Drupal A. We had a blogging capability on our connect platform, but it wasn't what is needed in today's world of kind of what we call the blogosphere. So if you go out, and I don't know if many of you follow certain authors or certain bloggers, you get things fed to you. You notice that they're very visually appealing. They're easy to read. They look nice. They get information to you in a very easy way. We needed that at Semantic. And so we took a look at what Drupal 8 could offer, and it was a much easier experience, both from the back end where we're publishing and then also from a user and from a partner experience. So you can see a little bit of what it looks like, and it gives us the ability. We have licensing with Getty, so we're able to pull our imaging off of there, to be able to deliver very beautiful high res imagery, and it's all the system will take. So in the world of putting things in the blog that you have to do, that you force editors to do, high res is one of those. So they can't just throw in any type of image. It has to be within a certain type and a certain size. It also gives us the ability to build custom paragraph bundles, offering very simplified ways to be able to build out your blogs. And so as an editor is going in and they have, let's say, rich text, but then they want to add a video, and then maybe an inline image as well, it gives you just a very simple way to be able to go in and do those things. It also has the Angular UI renders, which, you know, renders bundles with complex markup across multiple devices and platforms. And then, of course, the ease of the content entry. You can see on this slide, again, it gives you an idea of what it was before and after. On Drupal 6, what we used to call it is we had content blobs with a B. So you just throw in a bunch of text. It was a big blob of text. There wasn't a real way to differentiate your headers for SEO. You couldn't tag things in the way that you needed to. And, of course, you can see the imagery was nowhere near where it is now. Drupal 8 allows us, you know, highly customized content strategy with also read the image support. It also allows us to easily embed the videos, the file attachments and other rich media that we need in order to stay current and sometimes ahead of what needs to be happening out in the blog world at this point. What's happened within Symantec, then, is as we rolled out this blog platform, and this was only in November that we rolled it out. So, literally, you know, we're within, like, 130 days. We just finished our year end. And it's one of the things that we'll review at our all hands meeting next week of, you know, what are the metrics been like? What does it look like? Well, what happened was that oftentimes when people introduce brand new platforms, you'll see a little bit of a dip. People are getting used to it. They don't know how to find it as well. Maybe that they aren't as accustomed to going to it. We didn't see that at all. In fact, our subscription rate continued to grow. Our views, our traffic continued to grow up into the right, which told us we had made the right choice. And the ability to continually innovate that blog platform also then said yes, we're making the right choice. The other thing that it's done for Symantec is that it's allowed us to take a look at it and say, well, okay, we have a blog platform, but what else? There are other things now that we're beginning to build on Drupal 8 for other parts of the organization. Some of those are what we would call expert articles. So this is within the marketing organization where they need to be able to put out specific types of information on our products, on our solutions, and they want very key types of information going out in a way that they can control it from an editorial process. We also have part of our PR piece in here where people are able to send out the actual product releases in a very scripted way that can go out in a very easy way, but to the masses in an easy editorial fashion as well. AEM still has a role at Symantec, but we're finding many business opportunities to leverage Drupal in addition to that. And so within Symantec it's not either or, it's and. We use both of those things. All right, and then we'll talk about exactly what I talked about. How do you coexist with those other content management platforms that we have within Symantec? So one of the first challenges that we were faced with was Symantec's a big company with big budget. That's not a challenge to them. They grab the AEM is a big part of their ecosystem and Drupal is not. And so we had to learn how to coexist with AEM. And so again, I talked about how our goal, our mantra is to augment and accelerate, to do whatever we can to help out those other developers at Symantec to whether it's AEM developers or anyone else in IT. One of the things that we do is we actually push out RSS feeds from Drupal that is then picked up by AEM. So there's certain parts in AEM that have Drupal content. It's kind of a RSS syndication model, but they have, for example, blog posts. They like to feature the headlines of the blog posts and their AEM pages. And we actually syndicate those out of Drupal and into AEM. But here's some of the challenges we have. We did have to recognize that AEM is the anchor tenant in our mall, if you will. AEM is the key. And we're working with them and around them and for them in some cases. The experience had to be transparent to the user. So that bottom line, the user comes to this company site. They cannot stumble across the fact that we're using one content management system for one part of the site and another content management system for another part of the site. We believe that our team is one of Drupal's strengths. And again, because of our mantra, our team, we aren't always going, go Drupal, go Drupal, go Drupal. It's, sure, work with us. We're happy to help you. And the tool we happen to know is Drupal. And again, the user, the user is always first. The way that we did that is, I'm not a developer. I'm a little bit technical, so I understand a lot of the stuff these guys do. But this may not seem very magical to you folks, but to me, it's magic. I mean, we, the developers set up the content delivery network, which in this case is Akamai. Semantic uses Akamai. And then we have the various CMSs behind that. We have Drupal 8, Drupal 6, and AEM. And as a user makes a request to Semantic, they request a page. Their request hits the CDN, and then the CDN is smart enough. We've taught it to do the redirection to take that request and ask the right CMS. So if someone goes to www.semantic.com, they're seeing AEM. These are all public sites, by the way, if you want to go to them. If you want to go to Amy's slash blogs, for example, slash connect is Drupal 6, and slash blogs is Drupal 8. But if you go to these sites, you'll notice that you have no idea. The user has no idea. And we've worked very hard to make the branding consistent, the headers and the footers consistent, so that everyone in the corporation is happy. And some of these content management systems have their strengths. Our strength is we can stand up a Drupal site quickly, 30, 60 days, and that's unheard of sometimes in these Fortune 500 companies. And so we solve a lot of problems for these folks. Problems that the IT department is happy to have us have our help with. So another one of these challenges that we have is how to publish instant updates, how to constantly publish information to the website. And Michael's going to speak to that. Awesome. Thanks, Kevin. So I think this is something that most organizations want to achieve. You want to be able to publish instant updates to your website, whether that's existing content, maybe you want to test a new image, you want to fix a typo, get a new title up there, change the content of a story, or if you want to publish a new story, you want to get something out there quickly to your users, someone on your content team. And you might be wondering, why would it be a challenge to publish new content or update content on your website and have any performance impact or problem? So I was going to explain real quick how a page is actually built and why this is a challenge, especially when you're operating at scale for a really large, high traffic website. So this is an example of the semantic blog site. It's a portion of the page. It's actually served out of Drupal 8. And the way that a web server works is that it takes a lot of computational overhead to generate this page. So what it does is it caches components of this page in memory, locally on that server, using something like Redis. So basically, you know, your menuing system, you know, different components rather than recompute them each time it generates the page, it stashes pieces of this in memory, that way the second time it has to generate it, it doesn't have to do as much calculations or processing, and therefore your page comes up faster. But that's not fast enough. So you typically use something like a reverse proxy server. In this case, we use varnish and you can stash components of that page or even entire pages. Let's say you're serving large amounts of traffic to anonymous users, there isn't much customization. You can basically serve an entire flat page out of it, which is very performant. And this just offloads your web server. So rather than your traffic coming to your web server, it now hits this varnish layer further speeding up the content delivery. And this is then further buffered by another layer. We use both Akamai and Fastly for this site here. And what this does is it just gets it closer physically to your end user. So there's less latency, it just distributes out into the cloud to the edge, so that there's a server physically closest to me as an end user. And therefore, I get the content very quickly. And so if you think about this as a user that requests the web page, you're going through many different servers, many different layers, many different infrastructures and providers. And this content is all stored on these individual servers. So when you want to make an update to your pages, you have to deal with flushing the content at each of these levels. And typically your caching content, maybe for as long as 15 minutes or indefinitely, if it's an image, I think it's ever going to change. And so this actually presents a problem for people historically. And what you do is you go in, you have a developer go in and you clear the cache, you flush your CDN or you go into the backend in Drupal. But there's a huge performance impact in clearing cache at that kind of high level. There's going to be a lot of churn in your system. And so with the advent of cache tags in Drupal 8, what you can do is you can very granularly control your caching architecture and mechanism. And so if you look at the page here on the right, any one of these components or groups of components can be cached independently and in their entirety. So whether you're serving traffic to anonymous users, which is a lot easier or even logged in users in this case, you can actually cache serious components of this page. If your footer never updates, you never have to regenerate that for any type of user. And so at every level through the system, you gain a huge performance change. And then the exciting thing about this is it's all built into the system. So what you want to do as an enterprise organization or really any organization is you want to empower the people on your team, particularly the non-technical people that are content creators with the ability to own and manage and run these systems. And so it's really a seamless experience. You go in, you edit your title, you publish a new image, you put up a new story, and the system takes care of all of the heavy lifting in the background. It'll clear the appropriate caches, it'll propagate things through each of the different layers, it'll get it out to the end user. Absolutely no performance impact because you can literally just change individual pages, components of your page. Thanks Michael. And to further follow up on that is so nice to be working with these guys and being able to publish new content. I mean we do releases like five times a day sometimes, sometimes more than that. I number them and it's really cool to be able to use this continuous integration system, be able to push those releases out. So another one of our challenges is to migrate these 10 years of technical depth that we had. I told you we started with Drupal 6, guess what? We're still running Drupal 6 for part of our site. And for 10 years we've been adding modules and each new vice president that's come on board has had their own different vision of what the site may be like. So we've added features for that vice president and we've added a few features for this vice president until we've got a little bit of technical depth. So how do you move forward with that? How do you jump to Drupal 8? And one way to do it would be to shut everything down, take six months and migrate the site and then bring everything back up and the price tag on that would be crazy. But the other way, which it's kind of clever, I think. My team came up with this, I take no credit for it. They want to straddle Drupal 6 and Drupal 8. So when I was growing up in Western Utah, we used to climb over barbed wire fences and you had to be really careful and you had to keep the barbed wire held down or else you get in trouble. And I kind of feel like we're straddling the barbed wire fence now. But the way that we're doing that is we have, there are Drupal 6 instance up and running. The first thing we had to do is we had to decouple that. So we had to be able to talk to Drupal 6 from our API. So we set up a decoupled front end that talks to Drupal 6 via API. That was done, worked out awesome, things are great. We did have to write a little bit of code to make that useful because Drupal 6 wasn't really good at talking to decoupled front end like Drupal 8 is. Then the second thing we had to do, bring up our Drupal 8 instance. And then we basically make API calls to both instances. And our plan is to migrate one feature at a time from Drupal 6 to Drupal 8, skipping Drupal 7. So sounds like a good plan. Seems to be working. What we're doing with Amy's team is whenever they come in and say, wow, we want to redo groups. The first question we asked is, do we want to redo that on Drupal 6? Or do we want to make the jump and redo it on Drupal 8? And usually, almost always, the answer is, let's go with Drupal 8. So we've done, let me see, I've got a list of things that we've done. We have our registration system. I think the first, the legal module, there was an issue with the legal module and we couldn't get it upgraded. It wasn't quite available on Drupal 8. So that was one of the hops we made. So legal module is running on Drupal 8. The blogs are running on Drupal 8. Part of our user registration, our user help system is on Drupal 8. So if you go to somatic.com slash connect, you'll see this, you won't see the fact that it's pulling from both Drupal 6 and Drupal 8. So that's just one of those, one of those problems that we were able to solve creatively. Hopefully you can take something home from that. Michael? Awesome. So another thing that most enterprises, particularly large enterprises, want to do is to be able to move at the speed of business. This is extremely challenging when you're working with a large number of teams, cross groups, divisions globally, you're working with a large number of partners, your partners have partners in this case. So you're dealing with a really large organization. And I think one of the reasons that you choose a platform like Drupal or open source is that there's a lot of standards. You can have people come in, they can hear these standards, it's not a proprietary system, they're somewhat familiar with the code. But the challenge with any system, including Drupal, is that it's very flexible. And so you want to enforce your way of doing things, the standards that you come up with at your organization. You also, particularly for an organization like Symantec that's known for security, you want to make sure that your architecture maintains security. And so in order to be able to move quickly, but to enforce standardization across all of your different vendors and partners, is extremely challenging. And so this is how we achieve the multiple rollouts a day that Kevin was mentioning. It's through a fully integrated continuous integration and development system. And here's an overview of our DevOps process, which facilitates that multiple releases a day. There's a local development environment. This is using Vagrant, it's a technology that allows you to replicate your entire production infrastructure on your local development machine. So here on my laptop, I have a development environment, it literally is a copy of production. And that's important because you want to make sure that the changes that you're making are not going to run into any problems later in the process when you release them. You make sure there's complete consistency throughout your entire infrastructure. The first thing that happens when I want to propose a change to the system is that a computer steps in and it suddenly checks my code. It says, are there any known security vulnerabilities in the system? Did you adhere to the Drupal formatting and style guides? And it does some quick tests to make sure that this is worth looking at. If there's anything wrong with the code, I should say the next step it does is it notifies the team says, hey, Mike's proposed a change to the system. If there's anything wrong with that code, it says, hey, everybody, that code's been sent back to Mike for a review and approval. And that's important too because you don't want resources wasting each other's time. You want to make sure that you really instill in your team the spirit of looking at their work, contributing solid code before they turn to their teammates and say, hey, I need you to take a look at this. So the first step is automation. Second test is passing on to a peer reviewer. So once the code passes through that first battery of tests, it notifies the senior member of the team. They come in and they take a look at the code. They care about things like architecture. It's the way that you approach this co-facetic with what we're trying to do as an organization in line with how we manage our sites and systems. We're going to do a much deeper security audit, take a look at that code and make sure that it's up to snuff from that standpoint as well. And then similarly, let's say that Jeremy reviewed my code and said, hey, Mike, there are some things I'd love to see you improve here. Same thing. He then notifies me through the central notification system. And that's important, too, because the rest of the team stays in the loop as to all the changes that are going on. If Jeremy makes a recommendation as to how I can improve my code, everyone from the team can learn from this. And it's not interrupt driven. All this happens in our Slack channel in the background. The only one who's notified directly is me to say, hey, I have an action item here. And then I make my changes and it goes back through the process again, first to the automated tests, and then it notifies the senior team for review, because the team is notified. Anyone can jump in and say, Jeremy is busy and he can't handle it right now. Someone else can come in, look at the change request that was made. Typically it is handled by the same person simply for efficiency purposes. And then it goes through a much larger battery of automated tests. Core itself comes a large number of tests. We have our own functional unit tests and end unit tests. And the reason that this comes later in the process is, it just takes time. If you're going to run your code through a large battery of tests, even if you're parallelizing this across a large number of servers, it takes a fair amount of time to get through this. And so we do this a little bit later on in the process. And again, should anything come up in that process, the peer reviewer is notified, and it's at their discretion as to how they want to handle it. If it's a simple change, they can simply make the change and notify the developer, or they could say, hey, you know what, I need to bounce this back to the individual who created the code, and it goes back to step one, repeats itself all the way back through the process. If it actually passes through the automated QA system, it's automatically merged into the main branch. If there's a merge conflict for any reason, again, the peer reviewer is notified and can determine how he or she wants to handle this exception. They might just resolve the, you know, manually resolve the merge conflict themselves, put it back through the automated battery of testing, in which case, you know, the merge would go through. And then it's automatically pushed out to the production environment every five minutes. Let's say you discovered a bug on the website, or something slipped through this process for some reason, you could automatically manually trigger that process instantly if you need to, you can't wait five minutes. And then the last thing, and this is really important, is that it then syncs up the code with all the individual development environments that are out there. And that means that everybody on your team is once again, working off the latest production code infrastructure and changes. And that's important because you don't want things to make it all the way through to the process to find out that there's a conflict. And so, you know, I think the key thing here is you want to automate as much as possible. You want to rely on your team as little as possible with things like automated quality assurance checks and testing. You don't want to bother people with needs for things until it's been sent to be checked by a computer and say, hey, you know what, like senior resources of which I have a few that are really expensive, you know, you only want to involve them in the process, you know, when you absolutely need them. And you want to keep your entire team in the loop, right, in a non-interruptive manner so that people can learn from each other and stay abreast of the changes. And it's through mechanisms like this that we're able to achieve a large number of rollouts where I think a lot of organizations struggle to get code out. I'm surprised to hear on a monthly or even quarterly basis, you know, I think most organizations want to move towards a model where they can release code whenever they need to. And so that's a very traditional DevOps process. I think where things get even more exciting here is how we treat infrastructure. So we basically treat infrastructure as code. If you think about configuration files for a server, it's just a bunch of text. It's essentially code. And so we manage the same infrastructure process in the same way that we do code. And this is awesome because anyone on the team now can propose a change to the infrastructure environment because they're working in these local vagrant environments that are a complete replica of production. Anyone can make a change locally in their development environment. They can test the impact of that change on the infrastructure, what it's going to be like post-release. And they can propose that to the team. And it's the same process minus some of the automated checks because other than say, you know, checking that file for syntax and formatting, we just don't have the battery of automated tests. It's a simple configuration file and air quotes there. And so mostly it's a peer reviewer. They come in and the first thing that they do is they check that on their own local vagrant configuration. They make sure that the file looks good. The change makes sense. They make communicate with the individual developer and say, hey, why are you making this change? I want to understand what's going on here. So there's some communication back and forth between the peer reviewer. If there's any challenges or problems that work it out with each other, it'll go back through the process through to the peer review. Once the peer reviewer has a good sense of what the change is going to make, they're comfortable with how that works and performs on their local environment. They'll probably take things one step further and test it on a staging environment. We don't want to introduce any problems to our production infrastructure. And so typically if it's a simple change, it doesn't need this step. You could propagate it out. But if it's anything more than a simple change, we definitely are going to look at it in a staging environment and make sure that everything's fine. And we're most likely going to do a larger battery of automated tests. We'll probably manually trigger that large battery of automated tests that we have in our code cycle as well just to make sure that this infrastructure change isn't going to have any impact on the code that's out there. Just like code, this is merged. That configuration change is merged into the main branch for configuration files. Any merged conflicts is handled by the peer reviewer. And then if the merge is successful, the Puppet Master impuppets just assists the managers and propagates these changes out through the environments. The Puppet Master will update all of the production servers as well as the staging servers with this new file. And again lastly, all the local vagrant environments are updated as well. And so once again, every developer is in sync with the production environment and you can ensure that the changes that you're working on are in sync. This process has a lot of cool benefits. One that I want to touch on real quickly is that it enables us to achieve high availability without the cost of maintaining another infrastructure in a secondary location. So a lot of organizations like Symantec and Portion 500 level want to have two geographically dispersed environments that are running simultaneously. So God forbid happens to, you know, one thing happens to any of your infrastructures and environments, you can roll over to another environment. It is really costly to have even a small footprint of your production environment up and running in more than one geographical location. We can provision new servers very quickly in the cloud. And now with this system, we can instantly configure them. So literally, you know, all we need to do is provision a handful of new servers in minutes, we can configure them. And it's not instant high availability. You know, it's not seamless switchover, but there's no cost. You know, so we can simply and cheaply, you know, have minutes of downtime for a fraction of the cost of, you know, a high availability system that's, you know, running at both times. And it's going to take you a few minutes to switch over anyway, in most cases. So not only does it empower more, you know, folks in your team to make changes, but there's also a lot of business and cost advantages to doing this as well. So talked a little bit about some of the digital challenges that we face and how we've solved them with technology. I want to hand it back to Amy, who's going to talk more about how being successful in organizations, you know, no matter how awesome your technology is, goes beyond technology to how you work together with the team and your various stakeholders. Thank you. So we thought that we wouldn't do this service without being able to talk to a little bit of the bigger picture that, you know, you always have your technology running in the background, but a lot of times your customers, your partners, they don't care. What they want to know is it works. And not only does it work, but does it look well? And do they always get in when they want to? Do they get the experience that they want? In order to do that, it's really important that you've got someone who kind of owns the experience, if you will. The slide we came up with, it reminds me kind of, you know, what we would call on a customer experience journey, right? They're circular for a reason, because the beauty of Drupal and of these types of projects is they really are never-ending, meaning that you can always be doing the iterative steps of improving things. You also have a myriad of stakeholders that you have to be able to, one, have the relationship with and always give them a seat at the table, because in order for that project to be successful, they have to be able to put their thumbprint on it. You don't necessarily have to do this always with everybody at the table at once. You know, I think a lot of people have tried to do decision-making by committee and having 50 people in a room, you can't, right? But as you're working through, you know, working with your IT team, working with your business teams, working across your product teams, everyone has a need for the product, basically, that you're bringing to them and they're going to have certain requirements that they have. Being able to allow them to give their feedback early, being able to have them be able to talk about the requirements they have, test some of those in smaller environments is key to be able to bring this up, not only in a timely manner, but then I always believe in kind of the rule of no surprises that, you know, once you actually bring it out, they aren't surprised, they're very happy, but there aren't, you know, unusual surprises or things that make them go, no, that's not really what I wanted, didn't you hear me? You know, some of the things that are key attributes as far as being able to do that is the ability to paint the big picture, but what I call an iterative steps. So you give a big goal at the end of the day, but help them get there in smaller hunks at a time. So the way we rose, for example, the blog platform is we said we were going to come up with what we call an MVP. It would be, you know, the minimum viable project product, but here were the things that we agreed to or here are the things they agreed to more importantly about what would be released. And as long as we could check those boxes off and they understood that this is what would be delivered out of the gate, then of course everyone was happy, but not only were they happy, then they said, well, what's next? What are the next things we can do? And so that way we're able to iterate over and over towards that larger vision. Also, as I alluded to earlier, you know, making the big decisions but with the smallest possible stakeholders. If you've got your advocates, and you have the people who are your stakeholders that can make the decisions, having the minimum number in the room on the phone within the email thread allows you to move these things through at a much faster rate. And the communication is important, but in this day and age, it's not always about the email. I'm sure many of you have threads of emails that start and pretty soon there's 20 people in the thread contributing to their ideas and what they think is important. Eventually you've got to have somebody who's willing to, one, either pick up the phone and get to the stakeholder who can make the decision, go to the office, whatever it is, but you've got to not communicate just via email. It will never work, and it doesn't allow you to hit those goals or to feel like those people allow them to have that thumbprint on the project that you're bringing up. And then the idea, I heard today someone mentioned about the rule of three, that being able to have advocates in your program, having three advocates who are willing to support you across an organization as large as something like Symantec, if you've got the minimum of three people that will advocate for you, pretty much you've got then a quorum that can come up out of the organization when you have issues or even as you're getting ready to raise things up and communicate that across the rest of the organization.