Experience Makers Spotlight - Prepare for Growth & Continued Efficiencies

Thank you, thank you, and welcome everyone. I hope you’re getting a lot of useful information out of the skills exchange this year. I have a lot to cover in 10 minutes, so let’s jump right into it. To get started on the conversation around staffing your Workfront platform appropriately, I think it’s important to take a look back at one of the areas that we still need to have conversations around in the business world. This is still a topic of conversation for me with other system admins, not just Workfront. The digital landscape has changed a lot over the last 25-ish years. It wasn’t that long ago that we saw software come into organizations via the IT team. They were responsible for the configuration, the implementation, and the ongoing user support of all of the software within an organization. But what we’ve seen in the last 20-ish years were movements like crowdsourcing, low-code, software platforms, and WYSIWYG software, just to mention a few, come into the market. Combine that with the explosion of software and applications that have come into the market with the last 20 years, and companies started shifting the responsibility of administering platforms from the IT teams to the teams that are actually using the software. And I don’t blame them. I would have been overwhelmed with that tidal wave of software as well. What happens, though, is this shift opened up roles within teams for people who are not hired for IT positions to actually be supporting the system platforms. And that’s what we’re seeing more and more in companies. And what I wanted to talk about here, the point of this slide, is that in my industry, which is marketing, just as an example, I don’t think I’ve ever seen a job posting for a graphic designer and Workfront system admin. But we are seeing that. I was actually one of those people years ago in a different organization. I was hired as a marketing copywriter, and I’m an early adopter, with the exception of the iPhone iOS updates.

But we’re not here for that. So when I was hired and they brought in the Workfront platform, I was really excited about it. And thankfully, I had a manager who saw that and asked if I wanted to take on the role of the system admin for Workfront. And I said, absolutely. So I shifted into that role, but I was still copywriting. And it didn’t take long before we started realizing that we didn’t have a prioritization conversation. And we needed to identify which of my roles was my priority, a system with 300 people in it who use it to facilitate work, getting through the organization and out the door, or copywriting. And thankfully, Workfront took priority. So my point in this look back is, if you have somebody like this in your organization who’s wearing a couple hats and you haven’t had that conversation, go have it in the next 10 minutes. I’m kidding. Wait at least 20 minutes. Trinity Bryant and Tim Brooks have some great content after me. But seriously, have it soon. It will be the foundation for what you’re going to build on for how you staff your platform.

So for me, the next step I usually take in that journey for identifying how to staff a platform is to determine whether to go with the system admin model or the group admin model. And it doesn’t matter if you are getting a shiny new instance, or if you’re inheriting one, or if you are just looking to grow your instance. All of these points are factors that you should consider when you’re trying to determine which model to staff your platform with. So as I think you’re all aware, Workfront is a highly customizable platform. So there are other things that you want to take into consideration when you’re trying to determine which model to use. For example, as you see here, the depth and breadth of effort needed to support the Workfront platform by a system admin can be pretty expansive depending on how customized you’ve made your platform. There’s a lot of work for the system admin to do. What I didn’t include on these slides is things like maintenance and cleanup and retooling, all very important things to keep your system running efficiently. And it’s a lot. If you look at the group admin model, you can see it’s pretty easy for them to help pick up some of that work, taking advantage of the many hands make light work model. With them enabled as group admins, they can also help support your teams in the platform. Speaking of support, end user support is another big factor that we consider when we’re talking about which model to use for our system platform. I’m not going to emphasis on big here because on the left, as you see, it’s system admins only and we refer to that here as a centralized model where everybody’s coming to one person for help and support and building and everything you need to do in the platform. And as you start to add more users to the platform, you can see that that person can pretty quickly become a bottleneck when everybody is coming to them for everything. If you go with that model, one of the things that we recommend is create a queue, an FAQ, and point people to documents where they can do self help or embrace your inner YouTuber and create some little video snippets that help train people just on the basics of how to use the platform. And of course, Adobe has excellent support videos on their site as well. On the right, I’m demonstrating the group admin model. As you see with each of those little pods, there’s a larger icon there for a person and that represents the group admin. And the point here is that if you have a group admin in place, the people on their team can come to them first. So think about in standups or water cooler questions, somebody on their team asks them a quick question, they give them a quick answer and everything’s taken care of. That opens up lines to the system admin so that if there is a question that somebody asks and the group admin doesn’t know the answer, they can quickly jump to the system admin and get the answers that they need. So I’m guessing by now, this has gone through a few people’s heads and you’re not alone. I almost always get this statement when we’re talking to leaders, then we have the throwaway work discussion. We did some research here at Thermo Fisher Scientific and because I’m limited on time, I only brought two use cases. But what these usually demonstrate to leaders when we have this conversation is that when you take a beat and you look a little bit deeper at the data, it’s pretty eye opening to see how much more time you can save as an organization by enabling the group admin model. So in this first example, Marie is a subject matter expert for her team. They have seven custom forms that they update annually and they’re very complex forms, hundreds of fields, lots of if-then statements. Fortunately, Marie documents well, so she doesn’t have to do that year over year, but she still has to document what’s changing. And then we get in a series of meetings and do scoping and then talk through the changes because the if-then’s are so complex, it’s just easier to do that than try to write it down. In total, it took Marie and I 26 hours to do that work over a period of six weeks. Shortly after that, we enabled Marie as a group admin and it took her longer to do the work, which was expected. This isn’t her full-time job and she wanted to be a little bit more thorough, so she spent a little bit more time on testing. In total though, it only took Marie 10 hours to do that work, where before when we had to collaborate on the changes, she spent 11 hours doing the work. What ended up happening is she completed it in two weeks and we saved the organization 16 hours in total. In this other use case that we studied, and bear with me, the point is at the end of this one, Joe’s team hired somebody new and when he submitted the request to have that user added to the platform, he didn’t include all the information needed. I’m assuming everybody’s system admin’s here. We need to know layout template groups, teams, time zone, all of that information to be able to give the user access to the things that they need to see in the platform. Joe and I spent some time going back and forth in the updates on the request and after five days I was able to add this new user to the platform. We enrolled Joe as a group admin later and when he hired another person on his team, he went in and did the work in 15 minutes. The point of this one, I’ll get to in a second, but I’m sure somebody’s thinking this right now. We don’t hire hundreds of people a month, so where is the time savings here? What is the benefit of Joe being the system admin? When you look at the work that Joe did, he completed it in one day, so when his new hire joined his team, she was able to get into the platform that day and start working, but when he was collaborating through a system admin, me, and we had to go back and forth to get the information needed, she sat for four days without being able to access the platform. This is always a big point that sticks with leadership. Again, Joe spent less time on it, I spent less time on it, and we got our people in the system the day that they started. Providing data like this as part of the pitch is really key and if you’re in an instance that’s mature and you can start pulling those metrics, absolutely do it. It has helped us every time with buy-in or use my slides if you don’t have access to them. Before I wrap up, I wanted to leave everyone with a few more points to consider. There may be more for your organization based on how you’re structured. This should help with the decision-making and conversations with leadership if needed. There are trade-offs to both models. A couple things I wanted to call out here is if you have 4-front Fusion and you enable the group admin model, you might want to peel back the ability for them to edit custom forms if you have automations within custom forms. Those could easily be broken unless your group admin is also a Fusion admin, then bring them in. The second point is if you enable group admins, it’s really key to establish governance around the platform. Good news is Trini Bryant’s up next and she has some really powerful information around governance. That wraps up my presentation. I’m guessing people have questions and I’m looking forward to answering them at the end. Thank you. Thank you, Kathy. I love the different models and the pros and cons of each. I imagine there was a lot of screenshots being taken in those last few minutes. I’m looking forward to joining us here in a few minutes for Q&A. But first, our next speaker is Trinity Bryant. Trinity is a marketing operations manager at Amazon Web Services or AWS. We are privileged today to have her here with us to talk about how they’re feeling their growth at AWS by creating a sense of community, which I love, but also the governance around Workfront so that they can keep increasing that usage and that participation. Take it away, Trinity. Hello, my name is Trinity Bryant. I work for AWS as a marketing operations manager and I’m here to speak to you about building a community and Workfront. Now let’s get into the presentation. So topics we’ll cover in this presentation is what defines a community, how to build your community, what are examples of the contributors, the activities and the forums that helps this community thrive, and what are the benefits when having a Workfront community. Before that, I wanted to give you a little snapshot about my experience with using Workfront. I lead the business technology and product management team and we are the platform owners for Workfront in the marketing organization. We have had Workfront since 2018 and I inherited the platform in 2020. Since then, we’ve had two Workfront instances within marketing and over 16,000 users across both instances, around 2,200 standard licenses and the rest being collaborators. And last year we were happy to launch Fusion, which helped us automate several workflow automations and we hope to launch a few integrations later this year. Primary use cases for our organization include intake management, project management, campaign management, proofing is really popular, as well as the reporting capabilities. So what makes a community? A simple definition is a community is a group of people who share a common goal or interest. So that’s the first step, understanding what the common goal is for your Workfront instance. Ours was to reduce tools and create a centralized solution for managing all of our marketing efforts. Another was to eliminate the silos across all of our global teams and get us in one solution. We wanted to enable that connectivity between tools because we know that we’re going to be using multiple marketing tools. Let’s figure out a platform that could easily connect to all of those. And lastly, we wanted to be able to define and govern best practices for our organization as our work can be unique. So once we have those goals identified, how do you build a community? That’s the hard part. The first step is to find your potential contributors. These are the folks who will be a part of your everyday community. First one is who are those ideal contributors? Who are those folks that you work with that would be great leaders throughout the team or organization? Maybe they were former naysayers who you converted and now they love Workfront. Or maybe they’re people who have used Workfront in the past. Those are some ideal contributors. Another could be to solicit group admins or team leads to help you build out this community. These are people who really understand their team’s workflows and processes and can really speak on behalf of those teams or organizations. And lastly, our super users. As you’re working within Workfront, you start to identify those super users who really just get it and enjoy it. And those can be helpful champions for the adoption of Workfront. Now that you’ve identified your contributors, what kind of mechanisms can you use to continuously engage these contributors? When you’re thinking of your potential mechanisms, take into consideration the time that you have to spend on each of these mechanisms. If you have a smaller team, you may not want as many. But if you have a larger team, you may have a lot of these mechanisms in place. So those could be reoccurring meetings, office hours, newsletters, Slack channels, email lists. Workfront Wednesdays have always been pretty cool. Ad hoc meetings or even short videos. I’ve seen a team do TikTok-style videos for some of their Workfront announcements. It’s been pretty cool. So after you’ve identified your contributors and your mechanisms, finalize your community. This is an example of our community at AWS Marketing for Workfront. We have our system administrators, group administrators, techs means, leadership team, Workfront customer team, as well as our Workfront champions, of course. This is our Workfront community. So for each of our contributors, we’ve identified activities in forums. Our first set is our system administrators. These are dedicated team members who is responsible for the platform administration. They meet weekly. Every week they meet to talk about the platform, enhancements to the platform, implementations, any troubleshooting. They have weekly conversations and meetings regarding Workfront. Our next group are our group administrators. These folks are identified within the teams. It’s usually one to three people that make up a group administrator for one org or team. They’re responsible for the team level workflows, configurations, user access, troubleshooting ideas. They’re the first level of troubleshooting. They have monthly meetings. We have monthly meetings with our group admins and talk about any features that are coming up, platform metrics of that nature. And they also have a Slack channel. We have a Slack channel for the marketing org for our Workfront admins, as well as the Amazon enterprise has one for Workfront admins as well. And this is where they can chat, share best practices, ask questions, and really collaborate as an admin community. Our next group are text me’s. Being that we’re AWS, we have some folks that are really tech savvy and can understand the behind the scenes working of our platforms. So we have a group just for them who are Workfront users who have experience using Fusion or building connections via APIs and are really interested in the integration roadmap and all of the automation when it comes to Workfront. So we have our own tech council that meets monthly to talk about all of the specific technical details regarding our Workfront instance. We also really, really like to involve our leadership team. As you may know, the best implementations take place when leadership is at the helm. So we want to make sure that we’re engaging our leadership team on a reoccurring basis. Now this could be twice a year, to be honest. However, we like to touch base when goals are being set to make sure that the executive sponsors express their goals for Workfront and that we are aligned to what those goals are for the organization. So we meet with them biannually just to align and make sure that they’re aware of the progress that’s being made with the platform and that Workfront is aligned to our organizational goals. And then our Workfront champions. As I said, these are super users who really see the benefits of using the Workfront platform. They participate in group meetings. So our group admins also have their own forums and activities, and that’s where they primarily participate. But they’re also included in the monthly newsletter that the global team sends. And last but not least, part of our community includes our Adobe Workfront customer team. This includes our customer success manager, our account executive, and our assigned support engineer. We rely on them heavily for questions, for troubleshooting, and for our governance meetings where we want to deep dive into a particular feature or upcoming feature. They have been valuable in providing us the information that we need to help our team drive adoption and understand the platform better. So the Workfront customer team is definitely part of our community. So after all has been said, what are the benefits of creating a Workfront community? Well first, it allows you to scale adoption activities. We are a small team of three, and we lean heavily on our community to help push forward adoption activities and continue to learn about Workfront and grow and really become champions of the platform. Second, community is more informed on features and capabilities. When you have a community and you have these reoccurring activities and forums, your team learns more, they understand Workfront more, and they are able to use the capabilities to the fullest. That increases adoption because they’re able to use it more fully. Users become more invested in Workfront and it limits their urge to use other platforms. As we said before, as I said in the earlier part of this presentation, we had a lot of tools that we were working in. And when you learn and you understand a platform better, it limits you from moving from platform to platform. That’s what we hope to build with this community. Once users become more invested, they won’t want to leave. Resistant users have a widespread contact list for more information. As you may know, resistant users don’t always want to hear from you because you are the platform owner of Workfront, of course. So when you have a community, you can give them other contacts, other teams, best practices, and examples of others so that they can also see how Workfront could be beneficial to them. And lastly, return on investment. The more you engage your community, the more you engage your users, the more you’re getting a return on your investment. People are actually using the platform and they’re able to see beyond just how they’re using it today. They’re able to scale and strategize of how can we use Workfront to build a better workflow. Well, I hope you enjoyed the presentation. I really enjoyed speaking with you and I look forward to your questions at the end. Thank you.

Thank you, Trinity. I love how you’ve thought about all of these different internal champions, but not only how you can support them, but also how you can find them. That’s always a challenge. So really, really great tips there. I also love the shout out to our amazing Workfront customer success team. I love them. They’re pretty great, aren’t they? So we will be back with you momentarily for Q&A, but in the meantime, our final experience maker spotlight is Timothy Brooks. Tim is a technical program manager and the owner of Workfront at Deloitte. He is the true definition of a Workfront expert. He has over a decade of experience as a system admin, and Tim is going to share how they have essentially productized Workfront at Deloitte. Really interesting stuff. They’re doing that in order to streamline their expansion and also find more and more efficiency. Welcome, Tim.

Hello, my name is Tim Brooks and I am the Workfront product owner at Deloitte US. I’m excited to be here to share how my team and I have prepared for growth and continue to create efficiencies and how we operate as our stakeholders have been rapidly expanding. Firstly, let me introduce myself. I’ve been a Workfront system admin for 10 years and have completed many varying types of implementations with an abundance of different stakeholders. Today I am the product owner at Deloitte US running our internal use of Workfront. I am based on the East Coast, about 45 minutes from Philadelphia with my wife, my two crazy kids and our Shiloh Shepherd. Other than work, I love anything outside, time with my family and training in jujitsu. Now onto Workfront. Here at Deloitte US, we have multiple stakeholder groups, all which operate in Workfront differently. Our stakeholders range from marketing, pursuits, our research teams and more. And we are using nearly all of Workfront’s functionality with one team or another from intake processes, waterfall, agile project management, workload balancer, calendars and more. We also leverage Workfront as our source of truth and integrate to multiple downstream tools and tech stacks used here at Deloitte. We even strive to get the most of the content supply chain as possible. So we utilize other Adobe tech stacks like AEM, Fusion, Analytics, and we plan to expand even more. In my presentation today, we will be focusing on the overarching idea of preparing for growth and the steps we took that helped us prepare for our own increased stakeholder demands. Some of the key takeaways will be around building your Workfront brand, creating what I call a product catalog to enable a rinse and repeat process for your workflows, and then launching a support model to ensure you have the right resources to help manage and maintain your growth while not leaving your current stakeholders behind. So let’s jump in. One of the first things to do to prepare for your growth is build your brand. Why the brand? Your brand should help showcase what your team stands for and create memorable image for your team, for your stakeholders. For my team, I wanted to go with something that was a little more playful, but really emphasizes what we sell. Work better, work smarter, use Workfront. The brand is going to help create standardization, which is pivotal for the success of the product catalog, which will be discussed in a few moments. Once you have your brand concept, just like a brand for any company, put it everywhere. Leverage a logo. Use that same theme and branding across your documentation, your emails, and anywhere else you can think of, like video calls. This really helps you and your team stay consistent, no matter who is representing your team or where you are in your current stakeholder journey. One quick example my team and I implemented is branded decks and documentation that we use no matter the conversations or the stakeholder we’re having them with. This helps us constantly promote what we stand for and ensures we are in sync on how we communicate with stakeholders. Once you have your brand, you are ready to move forward to the next step. The next step to prepare for growth and to truly become experts in your work you deliver is to create a product catalog. What I mean by a catalog is to understand what are the key deliverables you generate and put a large majority of your team’s effort into these different deliverables. This enables your team to spend the dedicated time needed to master your core products, further branding yourselves as experts for your stakeholders. Some good examples of deliverables to put in your product catalog would be implementations, which should be broken out by size, whether it’s the size of the stakeholder or the work you’re delivering. Trainings, whether it’s new hires, train the trainer exercises, or how you onboard new team members for your own team. One product which isn’t always as easy to productize as execution isn’t always on the Workfront team is integrations. The thing I ask my team when it comes to integrations is thinking for our stakeholders when an integration makes sense and then knowing the right people to talk to about it. The product here is proactively knowing when, where, and how it makes sense to integrate with Workfront. Another key product is enhancement rollouts. When it comes to enhancements, it is who is driving the enhancement which can help you think about how to deliver it. Is it a change that you and your team need? Is it a stakeholder request? Or maybe it is a brand new Workfront feature. Either way, these are all enhancements that should be part of your catalog as they help optimize your instance. Now, how does all this product cataloging truly help you? As mentioned earlier, when you dedicate a lot of time to create a product, you and your entire team need to learn the ins and outs, making sure you are true experts of all your products. As you create products, you are also enabling each person on your team to volunteer to be an owner of those products. This typically enables your stakeholders to trust that the person they are working with on that product is the best expert in the matter. And it also allows your team to feel a sense of ownership and potentially shaping their own growth within your team. Also, having core products should give you a pretty clear direction where to spend your time helping develop and manage your roadmap and stakeholder backlog. All these benefits are necessities when considering how to grow. Now that you have a brand and your products, you want to templatize, templatize, templatize. What this means is create templated workflows, processes, documentation, and anywhere else that you can think of to help maximize efficiencies and boost your team’s velocity. Some suggestions on where you could create templated work are PowerPoints for each of your product’s processes so you can quickly pull together needed slides for any and all meetings. A point-structured requirement building document for each aspect of your products to help your stakeholders understand the level of effort and their requirements, but also enable your team to understand the time and effort it will take to complete an ask, which helps you nail down your pipeline. Templated project workflows for your products, aka managing your work and resources in the tool that you sell, Workfront. Even templatizing how you manage and onboard your own team members helps streamline the efforts when expanding your own team. This is where it all comes together. Now that you have your brand, your products, and your templatized work, your team should start to see some of the biggest benefits. You should now have created enough templated processes and documentation to empower a rinse and repeat development per stakeholder request, meaning no matter where you are in your new or existing stakeholder journey, you should be able to pull from your product catalog and template at work to quickly jump in and run any project and create solutions for your stakeholders asks and needs quickly. Utilizing your Workfront templates, you should be able to move into any project with all of the needed steps to make it a successful one. All of the efficient product management ensures your stakeholders are getting timely communication, elevated deliverables, and are getting the best Workfront team support possible. At this point, you almost have the full recipe to support growth. There’s just one more ingredient to be truly prepared, which is making sure you have the right support by developing a support model that grows with you. Before I move on to some methods to create the support model, I do want to highlight two key benefits. The first benefit is obvious, being able to onboard more users. This may be onboarding new users with your current stakeholders or brand new stakeholders altogether, but either way, you need to be prepared to support more users who will have more of their own questions, comments, and requirements. The second benefit isn’t always as obvious, and I feel is put on the back burner a lot. Having bandwidth to be able to enhance your instance by being on top of all of the upcoming phases, enhancements, and features in Workfront and the entire Adobe Suite. If your team is always continuing to learn the new functionality within the Adobe Suite, you will remain top-notch subject matter experts. This will ensure you and your team are truly delivering the best products for your stakeholders that you possibly can. Now, let’s jump into a few ways to launch a support model. I like to break this into two categories. How can you help your stakeholders help themselves? And then how can you aim to ensure growth on your own team? To help stakeholders maintain their own usage, create a training path to launch power users and champions. This train-the-trainer atmosphere gives the power to your stakeholders to support themselves as their needs grow. Another way to enable stakeholders to support themselves is to launch a work management practice. Or in other words, create a platform for your users from different stakeholder groups to come together and learn from each other, and then take those findings back to their own team. The next piece is not always in your control, but is something to consider. And if able, it will help ensure your own team grows as your stakeholder user base grows. What we were able to develop is a cost model for all of our new stakeholders coming into Workfront. We broke this up into two pricing models. Firstly, we charge for our implementations, which many times goes to hiring a third-party vendor to boost our team in the short term to support that implementation through Go Live. And then we charge our stakeholders a recurring yearly fee based on their size. And we leverage this to hire more permanent full-time support to increase our team size, ensuring we can support all of our current and new stakeholders alike. This model absolutely needs your organization’s support. But when done right, it enables your team to grow at the same pace as your user base. As we all know, it isn’t easy to constantly feel behind in your work. No matter what you do, you want to make sure you have something planned in preparation to onboard more users and roll out more deliverables. As mentioned today, from my experience, it saves so much time in the long run to take a step back and prepare a model that sustains growth. Have a brand. Have your key products to master. Templatize your work. And one way or another, create a support model that grows with you. Thank you for joining me today. And I hope you can take some of what you heard to support your own growth as well. Cathy, Trinity, Tim, I love having all three of you with us here today. How fun is this? We’re like the Brady Bunch. We have some fantastic questions from our audience and more are coming in. Remember, if you have questions for these presenters, drop them into that Q&A area so we can make sure to read them here. Our first question is for Cathy. Cathy, is moving from a single Workfront system admin model to a group admin model, what’s the criteria for a group admin? Great question. I’ll try to keep it brief because we only have 10 minutes, but you need to make sure that you define what they’re going to have access to. And then if you’re also talking about who’s the right candidate for a group admin, one of the things that we look for are people who are early adopters and also love Workfront because you want them to be an advocate of the platform. But then also you need to make sure that that person is going to have capacity and really understanding the level of effort for what you’re going to give them access to do and then communicating that with their team to make sure that their managers are okay with them taking on that extra hour of work a month or two hours or whatever you estimate it’s going to be based on what they’re supporting. That’s helpful. It’s good to set that expectation up front. It’s also really good when you can find those folks that love it enough, they want to do it a little bit extra, but also setting those expectations. That’s wise. Trinity, this one is for you. And the question is, does Workfront for AWS employ an implementation partner or are all of the new builds and optimizations built by the techs knees? Really good question. We actually have a mixed implementation process. We primarily as an internal team do all of the configuration. We do all of the new builds and optimization internally. However, we do have teams either do the resourcing or if their scope is a little bit more complex or larger where we do either work with Workfront Professional Services or we work with the Workfront Preferred Partner to help with those new builds or any optimization requests that we have. That makes a ton of sense. Sometimes it’s just a matter of capacity where it’s like right now we’re good to go, but hey, we’re getting really busy, a busy time of year and we might need to bring on some kind of temporary or extra heroes. All right. So this one is for Tim. Tim, you were talking about creating a product catalog. So it says you mentioned that creating a product catalog could potentially shape growth within your team. Can you explain that a bit more? It’s a good question. And it’s something I love. If anyone ever talked to my team on it, we highlight this a lot where as you create those different products, you need to bring in SMEs to own those products. So as you’re thinking about an implementation project or an integration project, you want someone on your team to be able to master those, be the expert in those, be able to speak on those. So if you think about it that way, you have your SME whose day is partially revolving around that product. So as that product grows or your team grows, you end up needing to bring in more support to support that product. So if you think about it, as you have your SME, the growth is growing, you need to bring in someone else to help support it. That helps them kind of get that more managerial experience and go from being the one strictly delivering a product to more owning it and then having others help deliver it with them. It’s really important that understanding and that ownership, not just kind of a, you know, do these tasks that actually have some ownership on it. Kathy, this one’s for you. And this one is again around the group admin model. I told you there was going to be lots of questions on this one. So with the group admin model, what’s the most effective way to organize the groups? If it’s by organization, is there a recommended number of users per group to avoid burning out a group admin? That’s a great question. So I think a lot of it will depend on how your company is organized, right? So if you have a larger corporation where you have segments within it, it might make more sense to organize your group admins aligned with those segments. If you already have groups set up within the platform, then I usually just align the groups to what you have established, whether they’re over teams versus business units or, you know, different product lines within a corporation. Burnout, really good question. I think really estimating the level of effort for the people that will be doing the work and determining whether or not it’s going to become a full-time job for them. You really need to weigh that 80-20 or 50-50, what do they have capacity for, and how much does that team make changes? So in larger organizations, my experience has been that there’s shifting that happens pretty often. And with Workfront, when you start building groups and teams around the way your company is organized or aligned, and then you have a reorganization, then you have to do some reshifting of groups and teams. And really figuring out how to group people so that you don’t have to make those changes as often is key. And if you do that, in my experience, then you do have more people that roll up underneath one group admin. So finding that balance for your organization, if you reorganize often, try to keep it generic. If you don’t, then have some specific groups and teams and figure out how many hours that person is going to need to support that group or team, and then talk to their manager. If they can’t take that on capacity-wise, then look at bringing another person in to help support them. I want to make a good reminder that it’s iterative. We’ve heard this all day, that it’s not a set it and forget it thing. You’re going to try something, it might be new muscles that we’re using, and if it doesn’t work, we might make some adjustments. We might have to talk about that with our manager or with that person. The next question came in for either Kathy or Trinity. Trinity, I’m going to throw this one to you since Kathy just did such a nice job with that last question. But this is also, it’s around group admins, but also around enablement. So how do you stay aligned? This came from Alex. How do you stay aligned with the larger user base? How do you keep them informed and trained on things like new work front releases, features, configuration changes? Do you spend time as a group assessing new features in preview and prep training or what’s your process? That’s a really good question. And similar to Kathy, we also have a group admin team as well. That was one of the forums that I spoke to in my slides. When we lean heavily on those group admins to communicate any new feature releases, we have a roadmap of what our internal team is doing at a work front project level, such as work front cleanup activities, any new builds that may impact other teams. So we share that. And then we also encourage those group admins to use the preview environment during those release times to test any new feature releases that will impact their teams for the future. So we have those sessions. We go through them. And then we highlight those talked about features that we hear in our work front community that they may like, enjoy, that they may want to be aware of if it’s going to be a big impact to the team. We do call those out, but we do lean heavily in our group admins to test, validate, and then communicate to their individual groups any changes that are coming up. I like that. Kathy, did you have anything to add, or is that kind of a similar process for you? It’s super similar. The only thing that we do, and I’m sure Trinity’s group does this too, we have a monthly group admin meeting where we’re on quarterly releases right now. We haven’t switched to the monthly one, but we surface some of those changes in the group admin meeting. And we talk about what it’s going to mean for their team, whether or not it’s something that we need to surface to their managers, if it’s going to affect how their processes are run currently. We do some of that type of conversations in our group admin meetings. And if needed, then you can escalate to governance and talk about whether or not you want to enable the feature or leave it off so that you have additional time for testing and socialization. Other than that, I’d say we do all the exact same things that Trinity just talked about. The next question is one that’s very near and dear to my heart because I did a lot of work earlier this year on inheriting an instance. And so this is actually for the whole group, but Tim, I’m going to start with you. If you’re taking over a work front instance, so you’re stepping into an instance that you didn’t have a hand in creating, what is your best recommendation for overall cleanup, things like users, teams, access, et cetera? This is a tough one. This actually happened to me at Deloitte. Big number one thing is don’t start rushing into decisions. Understanding the implications of the decisions. What happens if you move one group to another, create a subgroup. Definitely build in sandbox. I would personally say, I know it’s a pain to shift it into production at times, but definitely understanding the implications and then interviewing your stakeholders. Something that I found a lot throughout processes and even prior lives in doing this is a lot of people have had their opinions that they haven’t liked about access or what they can and can’t see, but they don’t speak up about it. They don’t know who to speak to about it. So definitely pick some key stakeholders, interview them, get their insight because they’re going to be the ones who can truly help you shape that picture of what should these new teams, what should these new groups or roles look like. And to be completely honest, you do need to accept the fact that some of it was probably set up appropriately. I know taking over instances, you kind of step in and it’s like, what can I fix? What can I fix? There’s times that things are built away for a specific reason and you shouldn’t change that and that’s okay. So to me, it’s definitely taking the time to vet. I’ve been at Deloitte for two and a half years and we’re just now starting to update some of these things because of knowing the implications of making a change too fast. Work with your group admins to ensure if you have a set of group admins, working with them to ensure the communications are going out that your layouts might change, your access rights to some of your projects or portfolios might change. And just allow all of the end users to be aware that there might be that little iterative time period where they might try to access something and not have it, then how to react to that. Yeah, that’s meant for sure. Yeah, so my final little piece of that is prepare for the help desk that might come in. Be prepared to answer questions, build in that iterative approach because you are going to accidentally click something or not realize someone’s losing something they should have. I will take a moment to just plug, we actually did a checklist called the Inherited Instance Checklist earlier this year. I can’t drop the link in chat, but I know there’s some savvy folks in chat right now that can go grab that off Experience League and share it. But it is actually a checklist of if you’re stepping into an instance that you didn’t build, all the things you probably want to check, all the things you might want to reference, we’re actually launching it as a blueprint next week. So be on the lookout for that. But Tim’s point of don’t just go in and change things is just really foundational to that. All right, I have a couple more questions because we’ve just got a few minutes left and I’m going to ask this one of Kathy. Kathy, this is interesting. It gets to the heart of the group admin and kind of access rights. So what happens if you’re using shared fields and one of the group admins needs or wants to make a change to one of these fields, it seems like there might be some issues if you have many people in the forms. That is correct. And in our instance where we have fields that are shared, we’ve locked those so that only specific people can make those changes. And we have the group admins bring that to the monthly group admin meeting and then we discuss what the changes, what the implications are, what needs to be updated report wise if that needs to happen. If it’s urgent, then we have a virtual conversation. But most of the time that stuff can wait and we discuss it during those group admin meetings. That’s really wise. We see that a lot when we’ve talked about center of excellence or governance that there is this kind of central council, whatever that may look like and whatever kind of levels those are, but bringing it back and not just doing things in silos. So really fantastic. One other thing I wanted to add on to that as you start to implement Fusion or if you have other integrations that might also affect other platforms that it’s integrated with. So you have to be super careful if you’re making changes to fields that are connected to other platforms. And that gets probably more and more appropriate or you really want to check that as you grow and scale that becomes kind of more and more of a compounds. Right. All right. This one is for Trinity. Trinity, this we’re going to come back to community. There’s kind of a two part question is one. Is there a number? How many community members should I have? And two is what is the most difficult part of creating a community? You can pick one or the other or both. I can answer both. Okay. So I always want to say start small. No matter what you do, start small. There is no magic number, but start with those team leads who are actually actually interested in the work that they’re doing in Workfront. Start with two or three people in need on a regular cadence. And that will start to grow as you start to identify those folks who are leading the process improvements in workflows for their individual teams. Those folks who need to be in the room where we’re talking about new functionality and new features or optimization. Here’s how you can work better. And your community will start to grow from there. But start small. Start with what you have. And as people start to hear about the great work that you’re doing, more and more people will join your community. And the hardest thing I would say about cultivating that community, if you will, is regular attendance, making sure that the content that you’re providing is interesting and valuable for their time. If they’re going to be a part of a forum, is this worth the time that I’m dedicating to this hour or two-hour meeting? Or is this something that I didn’t know? Is this new information that’s going to make my team’s life easier? That’s always a good catch. And constantly having I like to have a roadmap. I spoke to this earlier of topics or ideas. As I hear things from the community over and over again, maybe we can bring someone in from work front and let’s talk about that specific feature and just continue to cultivate. But that’s the hardest thing is maintaining engagement. But just listen to what they need. And it usually comes out in the end. I love that I’m hearing this again kind of iterated throughout a lot of the sessions today is just being consistent, especially with your users, whether it’s your admins, your group admins, your subject matter experts, just be consistent and really listen and know that you might have to change gears and that’s okay, that it’s not really a set it and forget it. So it’s really hard to believe this, but our time is actually up. We had so many questions coming in and still more that I’m seeing there that we didn’t get to, but we have reached the end of our Q&A. Thank you to the three of you for being here and sharing all of this expertise. And I know I have mentioned it to the audience a couple of times, but this conversation does not have to end here. So we have created a follow up thread on the Workfront community on Experience League for all of our Grow Track presenters. We also have a thread for the Learn Track. So hop over there if you have any lingering questions for Trinity or Kathy or Tim that we weren’t able to answer today.