---
title: 'Building a Team for Automation Success - TriNet | Imagine 2022'
source: 'https://youtube.com/watch?v=jOhjHvs7NpU'
video_id: 'jOhjHvs7NpU'
date: 2026-08-24
duration_sec: 2640
channel: 'Automation Anywhere'
---

# Building a Team for Automation Success - TriNet | Imagine 2022

> Source: [Building a Team for Automation Success - TriNet | Imagine 2022](https://youtube.com/watch?v=jOhjHvs7NpU)

## Summary

In this session from the Imagine 2022 conference, Eric Kern, a Solution Architect at TriNet, discusses how his organization transformed its RPA (Robotic Process Automation) team to achieve greater efficiency and scalability. The conversation focuses on the shift from a centralized CoE model to an Agile operating model, detailing the new roles, processes, and lessons learned along the way.

### Key Points

- **TriNet's RPA Journey** [04:36] — TriNet has been using RPA for four years, automating over 120 processes with about 30 use cases in the pipeline. They operate mainly out of a centralized CoE model but support a few citizen developers.
- **Move to Engineering Ownership** [05:32] — The RPA program recently moved into engineering ownership, kicking off a transformation to run RPA as a proper software factory model with predictable outputs, measured by adherence to an Agile framework.
- **Catalyst for Restructuring** [07:09] — Eric's experience at another company with a large enterprise RPA rollout using Agile inspired the change. Upon returning to TriNet, he saw inefficiencies from a single CoE team with dual analyst/developer roles, prompting a need for specialization.
- **Three Key Lessons** [08:23] — 1) Refine roles to allow specialization (three roles doing one thing well instead of one role doing three). 2) Invest in building the team through upskilling and hiring. 3) Optimize process requirements and intake to ensure clear, concise requirements that don't change scope.
- **New Agile Roles** [10:13] — Created roles of Product Owner (works with business, builds requirements, finalizes business case, creates user stories) and Scrum Master (coaches team, facilitates ceremonies, removes roadblocks).
- **Sprint Planning and Cycles** [11:42] — Sprint planning involves the dev team, scrum master, product owner, and solution architect. Sprints are typically two to two-and-a-half weeks, with the team picking up user stories they can complete.
- **Demos and Expectation Setting** [13:29] — In well-functioning Agile teams, demos are done along the way (e.g., every 20-50% completion) to keep business stakeholders informed and avoid surprises, making expectation setting crucial.
- **Communication and Ceremonies** [14:54] — Daily stand-ups (15-30 minutes) cover what was done yesterday, today, and blockers. Other ceremonies include sprint planning, backlog prioritization, and sprint retrospectives for continuous improvement.
- **Future Roadmap** [17:04] — Goals include achieving a steady state with new roles, increasing business-wide awareness through roadshows, and expanding citizen development by learning from successful champions.
- **Profile of Citizen Developer Champions** [19:27] — Successful citizen developers had prior technical skills (e.g., database design, writing queries), management support, and a problem-solving mindset. They saw RPA as an open box to solve challenges.
- **First Hires for New Team** [22:10] — Recommend starting with a master developer who has built and productionized bots to drive standards and best practices, followed by a solution architect for design and CI/CD pipeline planning.
- **Epic Ownership** [26:23] — Plan to have a single developer own an epic, with senior developers potentially handling multiple epics. This ensures context and accountability, though it may limit cross-training.
- **Technical Feasibility** [33:32] — To address technical feasibility, TriNet vets processes to ensure RPA is the right tool, and the solution architect role drives bot design best practices, handing off design requirements to developers.
- **Maintenance and Handover** [42:38] — For production support, enhance process documentation and create run books. Conduct knowledge transfer sessions where developers hand over to support, ensuring they know how to handle exceptions and escalate issues.

### Conclusion

TriNet's transformation to an Agile operating model for its RPA team emphasizes specialization, clear roles, and continuous improvement. By investing in team building, standardizing processes, and fostering citizen development, they aim to scale automation effectively and deliver predictable value.

## Transcript

live We Do okay really excited for this session I see some some great friendly faces uh people have been working a lot with over the past year and a lot of new faces um
I don't know about you guys this is my first in-person event in over two years if it is your first in-person event since February of 2020 raise your hand okay
okay yep all right so this morning we shared a lot of innovation right now we're breaking it down like here's the how-to and the people leading these efforts and what they're doing
um I'm so excited to welcome Eric Kern to this chat thank you Eric and I also have to click the slides which means I need to turn and look a team for Success right because that is super critical to leveraging any of the
technology driving your transformation so without further Ado we're going to um we're going to do some introductions Eric your role um why don't we do a quick intro on your
there sure how's that audio is okay I think so are you good on audio okay all right sure so I work at China
um I do solution architecture there for RPA um my background in RPA is I start off as a developer in 2016 and the past few
stuff and so in the spirit of transformation um I'm excited to talk more about transformation across an automation team
okay let's get to know a little bit more about the real Eric okay I'm gonna put you on the spot okay um bagels or Donuts
um bagels or Donuts the bagels Bagels okay okay we got some more Bagel people in here all right um one cup of coffee or Java all morning long
go with coffee the for one cup of coffee one cup of coffee and one oh yeah straight straight black coffee The Latte I do straight black I'll do a
I I kind of overload caffeine sometimes I'll do cold brew okay espresso power it up yeah all right I myself had a triple shot this morning um okay uh time travel
time travel or stay at home time travel time travel okay Beach or Mountains for vacation uh mountains okay right on all right we know a little bit about the real Eric
right um but all of you have you know big jobs driving technology transformation Eric you have agreed to spend some time talking about how you and TriNet have built a team for Success so thank you
very much I'm gonna click ahead I have to turn my head but I also have to ground us all in the technology we're talking about right you heard ADI Mahir a bunch of my colleagues talk about the automation success platform
we released 10 new Innovations this morning give us your feedback folks uh both on how you're building your teams for Success when we get to the Q a and afterwards we really want to know the
Technology Innovation that's most exciting for you to ask you of of everything that you heard of the keynote this morning what particular piece of innovation are you like I can't wait to get my team's hands
that's probably your toughest question yet interesting but also the embedded automation I know I have a a full
laundry list of different items I'm going to bring back to my team when I get back okay let's hear it for embedded automation all right so
um we talked this morning in the keynote some folks are just starting their Journeys some are in seller acceleration I know some folks in the room are often hyperscale whereas TriNet on their Journey just take us through it a little
sure so I think we're probably somewhere in between RPA China has been around for four years and over that course of time we've automated over 120 processes we'll typically have around 30 use cases in
the pipeline that we're managing and our automations have spanned across a number of the different business units in the company just to name a few in the company just to name a few apparel tax HR engineering Finance is
another big one and at this point we're operating mainly and at this point we're operating mainly out of a centralized Coe operating model however we do support a couple of Citizen developers across the business
and we have plans to expand that down the road and just another interesting interesting thing about our program is how it business so it wasn't until pretty recently just
a few months ago that it moved into engineering ownership and so that's kind of kicked off this pretty exciting transformation one where our main operating goal has become to run rps's proper software factory model
one that has predictable outputs where our core metric to gauge that we're on the right track there is going to be whether or not we're running outside of this agile framework okay so your automation started in the
business moved to engineering and I'm sure that has also been a catalyst for looking at the team structure um was there a moment a catalyzing
moment when you and TriNet or you personally realized like you know what we need we need to restructure for for acceleration oh yeah for sure so um like I said I've been in China four
years but there was a year Gap in in 2021 I went to work for a couple different organizations and I had the opportunity to work in uh in a company where they had a large Enterprise roll out of RPA
and everyone was working within a proper agile setup um so when I came back to China in March of this year um I had I had seen how agile Works within
the RPA space and that was definitely something that my management was especially interested in as well and just to give you some context and a background of what our program had had ran initially before a team transformed
ran initially before a team transformed is we had a single Coe team with a single platform owner and a bunch of these dual automation analysts developer roles so I think it might be kind of common across some of the different RPA
implementations where you have this dual role this person will get the business bot and then they'll support it once it's in production and that worked well when our program was young but when I left the company when I came
back in March I saw that some of the the symptoms had kind of grown into being inefficiencies that were clear across the team clear across the team no worries no worries and so there was
developers because of those time constraints I had mentioned with on and that kind of aligned with the catalyzing moment it's like okay we gotta make a
change here we need to transform the team and um Place some value on refining the roles across the team to create opportunities for folks to specialize standardize and optimize in various
roles rather than having a single role asking someone to be great at three things we could have three roles asking them to be great at a single thing the second thing that we learned through this experience was to put value in
investing and building the team and for us this meant that we would try and for us this meant that we would try to bring in everyone and upskill who was already within the train within the team within TriNet but also meant that we had
to reach out and bring in other skills and experiences for people and bring them into the China team and then the third thing that we learned is to optimize process requirements and intake so the idea to build a clear and
concise requirements that don't change in scope I can imagine if you're expanding the team and moving people into specialization and scale you have to standardize right I have a feeling that
with um so you're making this pivot to Agile right so I'm I'm an agile fan girl from way back was part of a team to completely transition an engineering organization
gosh 15 years ago it's no small undertaking right I have a question for the group who else has an agile methodology in their organization some folks okay all right so you have a little bit of time under your belt right
so for the folks who haven't yet made that transition what oh sorry click the slides um what's this structure particularly the roles and the responsibility you've taken someone who did three jobs you've
had them specialize into one you've added some roles what what are the highlights of the structure now sure so you you mentioned all the um through that kind of shaped this future state
some of the roles that are specifically inherited to Agile and that we created for this new structure are the the product owner and the scrum master so product owner and the scrum master so these two folks are oh here
delivery team and everything in the operating model in the sdlc workflow begins with the product owner behind it this person will work directly with the business to build the requirements they work on process intake and at the end of
a kind of an output of what they do is they finalize the business case and then the product owner will create the user stories and add it to the Sprint backlog scrum Master comes to the picture so this person they're kind of like the
agile go-to's me and the team they can provide coaching to other team members developers who come from a business background it might not necessarily know
agile that well our scrum master has wrecked and this is us right we have a couple developers who fit that mold a scrum master has recommended training along the way so so getting back to the to the roles
here the scrum Master after the stories are in the backlog then this person will facilitate all the remaining agile ceremonies and meanings in the next the Sprint planning meeting so in this meeting that's the the first
involved in and in here we'll have the dev team scrum Master product owner our plasma motor and our solution architect and and going through this call they'll
and and going through this call they'll pick up the user stories to take into their Sprints which are typically two or two and a half week Cycles um and um our Dev Devon QA will agree to
pick up whatever they think they can finish and complete within that Sprint so I'll I'll just make another comment here about agile and you know all this here about agile and you know all this but the the core idea with agile is to
take something big and break it up into smaller pieces and that's what allows us smaller pieces and that's what allows us to take on separate user stores which could represent separate functions of a of a more broad
business case and allows our Dev team to kind of iterate and chunk through and work through portions of that story of that business case but be able to show real progress while working through
no I I have to go off slide for a moment because you touched on something that I've heard from so many of all of you around expectations on delivery particularly for different lines of business and different stakeholders who
have let's say a sliding scale of understanding about complexity of automation use cases and how long things take so are you at the stage where you're showing partial demos 30 demos 60 okay
it's a hundred percent done with your business stakeholders or does it help with expectation setting do you have to do extra work because of this model got you so a lot of what we're discussing today
excuse me is is part of our future State we're actually wrapping up our migration we do that we're going to go fully tilt and kind of move into this agile operating model but to your point I have seen
but to your point I have seen um in in well functioning agile teams um in in well functioning agile teams where they'll do demos along the way so I've seen it work to where they'll do demos for every 20 50
um if it makes any sense for grouping different functionalities of an epic together to do the demonstration then oftentimes the way the business is going to be informed there's going to be no
surprises and uh that's it that expectation setting is just really really important so yeah that's why agile can be so effective um if folks want a really deep dive on
picture he's shared it with you he's open to the kimono one of the best examples of community giving back so thank you for that um so I'm gonna I'm Gonna Leave It Up For a Moment people can get their their
shots and then um talk about communication though in in this model have you seen it work how do you want it to work you want it to work right so how I wanted to work is kind of
how I've seen it work and and that's we're gonna try to stick as closely to the agile ceremonies as we can so that's going to include the daily stand-ups typically like 15 or 30 minutes at the beginning of the day
where the the dev team and scrum Master will be there the product owner and they'll go through what they did yesterday what they did today what blockers and the scrum Master's responsibility partly is to help clear
any roadblocks so for that constant communication is key other meanings that we will do is the the Sprint planning Sprint backlog prioritization Sprint retrospective so I haven't touched on this one yet but this meeting is crucial
it's done at the end of Sprints and it's basically like a lessons learned it's like what do we do well what didn't we do well how can we improve and an effective scrum Master is going to take action items based on whatever was
discussed so just making continuous Improvement so just making continuous Improvement again I'm a big agile fan girl but um that ability to look back at a delivery and see what you've learned
talk about it as a team I think probably resonates with a lot of folks and it's when it comes to automation because there's always another use case in the pipeline right that you want to tackle um I think I have one more question
before we open it up to oh yeah so you're bringing this best practice team resourcing model right um you brought it in as a response to a catalyst in the business and the growth of the program moving from the business
by the way that it started in the customer experience customer experience okay um what's ahead but if you're sitting here in this chair a year from now talking to folks what what what's on the
roadmap that that you'll be really excited to have delivered cool well I'll go with the the first one which isn't so exciting but it's just to achieve a steady state with all of our new roles and responsibilities don't
underestimate the steady state right it's important necessary right but the second thing that we want to do is to increase business-wide awareness of the program so we'll be doing Road shows and just kind of marketing some of RPA wins
and really demonstrate what kind of value they can get from RPA is it's kind of a Hot Topic it's a expand citizen development
so a little bit of background is is we thought we would do a complete hybrid operating model in the beginning days we try to do trainings every year and have like as many or even more citizen
developers as centralized folks but they didn't really stick through through the trainings the first couple years today we have just a couple who are actively creating bots but their their roles have shifted from
the first or second year that I've met them now they're kind of like automation champions for their department so they they do 100 build Bots build automations so our goal for expanding citizen development is to learn from them figure
out why they were successful and if there's anything that we can do to Market to the business to help uncover the next batch of effective long-term citizen developers and we'll kind of pitch that to them and
so stability marketing and citizen development these are very very common trajectories for a lot of people in this room and it's interesting that we're wrapping this part on citizen development
um because that is also very common we'd heard from so many of your peers out um I always like describe citizen development growth in terms of like the Yelp model because you know yelp's business model is based on like millions
and millions and millions of consumers but only one percent of Yelp subscribers actually post reviews and 10 comment in the other 90 consume and that one 1090
also is very similar with citizen developers you start out with a big pool you get people who do create and contribute and then you get the one percent who it really sticks right um can you share with us is there any
common profile between these couple of folks who really became your champions yeah yeah absolutely um secret nerds are they well no the first thing is a shout out to
automation anywhere they they both said that like RPA saved their careers but uh they did not pay him to say that yes not I did not but I didn't notice between the two of them they both had some kind of
technical skills prior to going to RPA so between the two of them they had some experience with the database design with writing queries to to pull data and that kind of jump started their uh interest in RPA
because they wanted to automate what they were doing but they also saw they would directly do it but I think why it really stuck with them too and there's like a common linkage between the two the two guys is that
their management we're really passionate about it they they wanted them to do the training and these two individuals too they they just have the right mindset like this problem-solving mindset where if they saw a challenge they saw RPA as
this open box to to solve it so technical aptitude management support so technical aptitude management support and the mindset curious mind great um well you've really taken TriNet on a
journey automation is growing it moved from customer experience to engineering you came back to TriNet and brought the agile model right you're taking folks on a journey now um I Really Wanna I wanna make sure we
q a I know that there's folks who have questions for you shoot all right all can see your name is it Daryl Daniel Daniel you are ask her number one
Daniel Daniel you are ask her number one go for it
I'm going to start with this project going to start with this project Consultants but that's a time limit and Ours for this analyst Solutions architect the
master developer you know I mean like water Step One Step Zero it's a great question okay Subs area about the product step
okay Subs area about the product step 0.1 I would do I would be someone who's built a number of bots and put them in production because they can kind of help Drive standards and best practices
around development around design and maybe even provide you some framework for example so once you get that then you can drive
the standards for all the remaining Bots solution architect I'm not sure if you're working with anyone in your in your it org who's like with the architecture mindset I'm sure you are
if you're not then then maybe getting some uh some support there just to make sure that and maybe it's not even so much a big concern now with the cloud implementation it takes a lot of that um planning out of the picture but
to get them involved to to kind of talk about like how you want to implement like the CI CD pipeline in your organization to get you off to to some good momentum sounds like a master developer our
official recommendation which folks is on the Pathfinder destination site that you may have heard about is uh right out of the gate as a developer and a and I'm sure folks here also probably have their own experiences Adam I see
have their own experiences Adam I see you nodding your head um more quiet he's here more questions yes sir
discussion a couple weeks back I was curious about it too and I think our plan is to definitely include them into the scrum calls at least initially we'll see how it goes if we have to adjust it and the reason for that is we're trying
to enforce a single centralized process intake for all of our Pas so we don't want to open up our platform as a shared platform for for the business without us
vetting all the use cases together we want to make sure that whatever we're automating our quality use cases where um we're okay giving up licenses or or server utilization so I think we we probably would include
them into the scrum calls more questions Carolina
um one of the things that um I'm always because I've worked in other places from one of the things that I've noticing noticing we aspire to be self-organized team so
we get the backlog for three months we do Sprints every two weeks but we plan for three months for quarter so so very difficult sometimes blind that time ahead um but then how it works is like we get
the backlog and we try to break down the pdds in like a Digest digest stories has is the project is the bot and then you have multiple kind of subtasks to the makeup done but in the in the in the
with the goal of trying to be self-organized we are we are with the challenge so like context switching we're like okay now I'll take this story within somebody like another developer should be able to take on the next one
really happen like you have to provide context and all of that so do you allocate one developer to one Epic or to one let's say development solution or
at like that agile that anyone can come and take on the stories and build up a it's a nice question [Laughter] so I've seen it work in the in the past where like to your point you would have
one Epic and then underneath it could be individual stories for like different individual stories for like different requirements or functions from the PDD but from that I think what we're going to try to do is to have a single
developer for an epic and then if if y'all have more experienced developers maybe that means like a lead or more senior developer who's kind of tied to that epic and then could maybe more like a developer agnostically have other
people work on other functionalities as long as you have that one person on it then somewhere like another developer comes from Gravity that person is not
able to just oh yeah medically kind of just work on it without automation
yeah yeah okay we've got a few different models here thank you for sharing that that's awesome I hope everyone heard and maybe I should pass the mic um okay I think we have
do we have time for a few more questions yeah okay you ask your question share your name and where you're from
getting kind of the stuff in the Hop that's been nice clean related pass this mic to to this gentleman right here but uh for us we're we're kind of anticipating that being a big challenge
as well because it's kind of like a natural pull off of agiles is the whole identity access management topic so we're trying to kind of just compile a list of all the systems me's and try to have some sort
of regular Cadence maybe it's uh bi-monthly but but just understanding bi-monthly but but just understanding who to go to for what type of access kind of cheat sheet or like an application inventory where you have
that information available but I don't know do you have anything else to add to first of all we have to wrap up the conversation but nope we can go
I'm gonna do I'm also going to pass the mic okay so you were asking about how to make your Sprints clean and deliverable per right okay Carolina and share your name uh Caroline locker Nike um
we had the same issue and this is something that we um being able to when you move your um your Solutions or your potential solutions to development to actually
enable or Empower your developers to sit down and develop that's a big big issue like it always gets stuck and then you never ended up delivering what you are a Target to so the way how I'm thinking we will be hopefully solutioning for that
and that's something I did in my previous company is that responsibilities for the whole life cycle of the project so agile doesn't only start with like development but before especially with our type of
products because you have like the highly predictable so you're agile when happens pre-development that's where you create what's the best solution for you pretty much have to deliver the bot that you create in your PDD or your
just like I'm gonna give you half of a bot right so uh you gotta do the agile a little bit pre-development and that's when you go and Define like for example to cover for those cases I knew I'm gonna deliver a solution in um in sap
gonna deliver a solution in um in sap I'll get the BBI the Bas to work on any access for developers any any data that needs to be in the kind of sound and all of that so when we pass things into development they ready they ready
to sit down they got their IDs they got the environment set up and that's all the environment set up and that's all ready for them to actually developed well all right yes sir
hey this is Chandra so I have seen in this slide RPA slide RPS Coe slide where it's talking about business feasibility okay so but what about technical feasibility we have run into some issues where business feasibility comes out
pretty good 8 by 10 rating okay but when we went to technical feasibility because product it's three by ten so what happens is if
you take that one developer taking the Epic and you know building the bot they build out of 15 Steps 10 steps they spend two sprints or one Sprint and finally they couldn't get uh worked around on how to uh you know automate a
around on how to uh you know automate a particular step and then we have to put that on a hold and move on to the next step so any any recommendations on doing the technical feasibility wherein the life cycle or what are the best
practices in accomplishing that oh nice so uh the question by the way is the conversation but what about technical feasibility uh so for us as part of our automation team RPA is just a single vertical and
there's other applications across our our director level team so prior to us even taking on any of those RPA processes we have to vet and make sure that we're using the right tool to create that solution so I think with
that initial vetting of the business case or the process and making sure that we're applying RPA to The Right Use cases would to your point kind of vet out some of the of the process that might not be good
of the process that might not be good candidates for RPA but to the technical design or feasibility that you're talking about too we created one of our new roles was the solution architecture role and and this person is going to
kind of help with driving the the bot design best practices and they'll hand off the design requirement to the developers we'll just execute on on building that so we're hoping with those two those two actions to to try to catch
some of the the technical feasibility you're talking about but I am clearly hearing that this is a great topic for a future user group meeting so follow that away um Mark Rodriguez
one thing we also do is whenever we have our Solutions architect and there's challenges we will run a proof of concept specific to testing that portion of the step before we ever accept the full solution so we can probably
properly size a user story and make sure that there is a that we can actually overcome that roadblock so that we that happens quite a bit in our processes I'm working our digital transformation group so we run through probably 150 different
so we run through probably 150 different Bots a year just solely doing spot and we're really trying to get to and I'll ask a question here how do you take those spot Solutions and understand the end-to-end Automation and really where
you can see some real Time Savings of value as opposed to just spot Solutions wow did we put you on the hot seat Kristen do you want to take this one
question is like that whole end-to-end process right and beyond beyond the simple bot and the simple ones tactical solution right and I think everyone wants to get better at that for sure
um do you have a specific like example you want to flush it you can just give a try to do this and yeah so that's uh yeah that's a great yeah so that's uh yeah that's a great example so again we have a simple intake
form someone makes a request and we have a number of product owners or business analysts that will take a request but they don't often ask the you know five why's or they don't get the beginning and the ending piece so what happens is
somebody has is doing one portion of a bot Automation and then you know someone else has developed maybe in three Sprints three prior Sprints a similar piece or something that is further Downstream so just wanting to help how
do we educate our team members to fully see that end-to-end automation are there there different business requirement documents that you're going through and uh just starting that conversation we've tried to implement business partners on
our side where we have people who have uh you know are associated with the practice area so they're in and expected to learn more about the processes to learn more about the processes is it you know Fortress IQ and their
task mining I don't know just open discussion really okay will share a couple of highlights of what we've heard most common and what we um I don't want to put Eric on the spot for this one this is what spark
describing is expectation setting with the business so that you get the thought process all the way through not just can you automate this but why what is the business impact what is the value it drives we typically recommend looking at
three things and you you basically have to educate you have to Road show this with your business partners is what is the degree of complexity what is the degree of risk and what is the degree of value and those are three areas where it
just takes constant education and examples if you get your poster child of like this person thought the process all the way through they asked the right questions and not that you want to shame anyone but here's one that didn't work
out so well because we didn't ask the right questions or we didn't answer the right questions and you keep wash rinse repeat wash rinse repeat and the more poster children you get the more people in your organization understand oh this
is what it's like to think the process all the way through heard a bunch from you but I see two people behind you who are also waiting so um this is such a great discussion you guys
you guys um in the black dress but before that we have some thoughts about the last three questions that we
have discussed Eric and I this is Eric as well Eric and I are from Genworth Financial uh we have been um like we have our RPA program is four years old just like yours um like our Eric and I were trained we
have developed like I lead the team so we have done it done a lot of it we still have a long way to go but just a few thoughts technical feasibility and uh the like a more educational end-to-end process and how to integrate
smaller parts into it wow I can share what we have done what we have seen working for us and what our intent is in the next um like six months uh one year the next um like six months uh one year to to do one um like we are a part of
our centralized like we are the Coe mainly technical people we have our model is different we have a lot of people in the organization whom we have trained Business technical one thing we do at the beginning and we like we we
did the Train the trainer and we are both certified trainers at Genworth we know how like what is important to Genworth how our organization works so one thing that we include as a part of our training class is a mix of Technical
and business folks technical people need to know how to ask business questions business uh business people need to know how to what a loop means for example so just just to do that so basically we trained everybody to basically ask the
questions what to consider where is this data coming from where is it going what happens before what happens after what team um like you know is sending you end goal um all of this we actually educate them
to ask those questions in addition that is the training part second step we are working on a pro on a on a process like people are coming back from the pandemic so it's just picking up as to having a live is on from our team the Coe working
with the business area specifically where we do the technical feasibility at the beginning so this is what your process is these are the applications this is what the flow looks like in our experience this is successful this is
not and our team is constantly updated on the new features that are with automation anywhere we are engaged with the communities to see what others have done so like at genwork we are the first step to answer those questions uh and
the third step that we are trying to do Eric like what do you like Eric helps uh a bit Works one-on-one on specific parts and applications so if somebody's stuck we are here what do I do now so I just I'm just generally a solution architect
as well and I just leave myself kind of open in certain ways to allow people to come to me and say this page just isn't working and for them to feel not like they're not alone especially for citizen developers that somebody else is willing
to help just in troubleshooting has helped a lot of people join the team that probably would have felt stuck and given up a long time ago
[Music] my question would be in this new dealing with maintenance because you were talking about moving away from you
know people staying on one uh bot and moving away from it do they need to train the maintainer or is that a separate role nice so we're covering that in our
post-deployment production support and there's some some steps that we have to to do in order for our support teams to be able to own that facilitation channel the first thing is to really enhance all
the process documentation and to create a run book for all the processes so for our production support to have that in their in their back pocket kind of have process but more importantly what do they do if something breaks how do they
interpret technical business exceptions what actions do they need to take who like which developer do they need to reach out to and escalate if it's a true reach out to and escalate if it's a true defect or a bug fix needed
completely removed from the process but there should be that knowledge transfer that that takes place where they do the Handover to support so a mix of levels okay folks our time is up
um Eric thank you so much for sharing where you are in your journey and wow great conversation and questions from this group so um really excited for the rest of today and tomorrow thank you everyone