Workday Podcast: DevTalk: Sun Life Enables Digital Resiliency

Chris Bledsoe: Sun Life is a leading asset management and insurance organization dedicated to making care and benefits easier. That's why I'm excited to have an innovative engineer from a truly innovative company on the Workday podcast today. Eric Chung, director of HR Systems at Sun Life, is going to share his best practices building business value with Workday Extend. I'm your host, Chris Bledsoe. Thanks for joining me today, Eric. I've been looking forward to this call for weeks.

Eric Chung: Thanks for having me. I've been looking forward to this as well.

Bledsoe: That's fantastic. Yeah, the last time I saw Eric, we were actually at Rising in Florida and we had a really great time. He's a phenomenal speaker. For those of you who don't know Eric, you should definitely look him up. He's got a lot of great, interesting things that he's done over time, and I think you would really enjoy being with him. But I'd like to ask you, if that's okay, a few questions to try to dig a little bit deeper into your experience using Workday Extend and trying to explain how our customers and our partners would learn and understand this better. So the first thing I want to ask you is, can you tell us a little about your technical background like what kind of experience you've had prior to your role today?

Chung: Right, so I actually started out of university as a consultant working on custom development on the Microsoft Stack. Eventually, that kind of moved me over to Dynamics CRM. And it was just right around when that product was becoming [inaudible]. And so I've worked with a lot of different industries and learning about all the problems that they face, solving it with Dynamic CRM. So from that, one of the things that we did was HR. And we used it actually-- like with CRM, we're using more of an XRM, so it's not just customer relationship management. It's anything relationship management. And that's kind of how I got started looking at technologies as platforms. And that's exactly kind of what Extend is, right? We can go ahead and build anything that we want, have relationship models associated with it, and to have it deliver on functions. And so I think that kind of experience helped a lot to kind of frame the way that I look at Extend and how we use Extend at Sun Life.

Bledsoe: Well, that's fantastic. So one thing that's really unique and special, I think, about Sun Life is that you guys have built a lot of Workday Extend apps all over the map, all kinds of different things. I know you've talked extensively about those solutions that you've built and stuff. But I want to understand, so what is the business value you've seen so far from these apps that you guys have built?

Chung: Well, I mean, a lot of our apps that we do is focused on employee experience. It's about removing friction away from the tasks that would otherwise be cumbersome. So if it's a paper form, we're turning that digital and we use Extend to do that. If it even was digital, there are certain limitations and things that we can't do. We'd actually switch it over to Extend so that we could do more of it. In the end, it's really all about just removing friction. And then we just keep iterating on it and learning what we need to do.

Bledsoe: Well, that's really great. So one of the things that when I talk with developers on Workday Extend is they ask how did development teams work together, right, specifically within HR. So how do you decide to prioritize where your investments are for your time and your resources? How do you kind of figure that out when you're making decisions around that?

Chung: One thing to note is that there's really only two of us at Sun Life. And so it's very important to kind of figure out and to make sure that we're using our time wisely. One of the things I kind of at the very beginning set out with the team was, "Hey, whatever we do, I don't want it to just be one time's output." I don't want it-- we don't want it to just be able to just be thrown on any project and just work for eight hours a day and then just, that's the end of it. The things that we build has to generate more value in the longer term. And so that's kind of how I prioritize all the stuff that we do, is that, do I see additional value in the work that we're building? And to another part to the question, is how do we work with an HR-- we actually do a really good partnership with configurators as well. So it's not just all development. That's one of the-- I think, the key differentiators for us is that we bring the developers and the configurators together to go ahead and build these experiences. It's really important because first, there's only two of us, so we can't do everything in code. So we do offload the things that we know are going to change over time into configuration, and then we tap into that so that we can kind of minimize our support for the Extend parts of it and try to kind of offload that into configuration.

Bledsoe: Well, that's really interesting. So as a developer, you also work with the configurators of the system themselves. So I'd like to dig a little bit deeper into that and understand. So when you're, let's say, looking to build an application - the business comes with you with a app idea that they'd like to have you generate and build out - how do you determine what can be done by development versus what can be done with configuration? Or how do you-- or maybe you as a developer understand what the configurators could do? I'm kind of curious on how that dynamic works out.

Chung: It helps that I have a really great developer/configurator on my team, Sam. And she's very good at understanding how Workday works. I actually don't have the deep Workday kind of configuration experience. But I do know systems, and I do know platforms, I do know how to code. And so between myself, Sam, and Theresa before her as well, we would all get together to say, "Okay, well, here's the experience that we want to build, and then, let's [inaudible] up what makes sense and where should things go both from a technical perspective and also from a kind of functional perspective." And so when we build the code, it's actually more about putting the pages out there and then having some of that kind of workflow stubbed in. And then we use the verification side to kind of chain them all together to build that whole experience. And reporting, as well, was another big thing that we've put all this data into Extend, how do we get that information out? That's when we kind of tap on that reporting expertise for my team to build a lot of the reports that are actually not sitting within Extend, but outside of that.

Bledsoe: Yeah, that actually is really interesting too because, if I understand you correctly, your true north is really the experience itself. And then based upon that experience that helps you to decide what type of work could be done via configuration versus what could be done via purely development and building it out. Is that correct?

Chung: Yep, that's actually one of the key things I think that we do too is we kind of categorize and classify our apps right at the beginning. So when the business comes to us with a problem, they go, "Okay, well, is this an app that we're just digitizing an existing process, or is it something that needs to be more scalable and is actually just entirely new?" In each of the two different type of things that we do has different kind of requirements associated with it on both the technical and the configuration side as well. And so I would say it's definitely bespoke and we kind of move that lever [laughter] each time there is a different use case. The good thing about that is as we do that, we're actually learning a lot more about the system too and it allows us to build more applications and also kind of over time get better at understanding exactly where that line is to say, "Okay, well, this fits better with configuration stuff." And then having that tie into the development that we do in Extend or vice versa, or the other way around.

Bledsoe: That's really cool. One of the things, too, that I hear a lot from developers is they're trying to explain to the business the value, right, and here's what the value is. So one of the things I'd be interested in is how do you share back to the business around that? How are you measuring its impact and how it worked within users as well as for the overall company as well?

Chung: There's a couple things that makes my answer very specific to Sun Life. There's only two of us, so in some ways, we don't want to share-- we don't want to shout it at the rooftops to say, "Yeah, we got this Extend thing. We can do everything." That's probably not a good way to go about it, so we're trying to be very measured and very specific when we do message this back to the business. And one of the things that we do is that we do work very closely with the business when we're building this. It's actually one of the criterias that we need to build applications is that we need to make sure that our stakeholders are engaged with us every step of the way. And they see it in the end result, and that end result is sometimes or oftentimes seamless to the end users. But when we start working with new business people and we say, "Okay, well, hey, look at what we built over here." They go, "Oh, wait, that was done in Extend? That's amazing." So that's kind of how we share our value. We build seamless experiences that actually really help our users save time, remove friction, and we don't want them to be frustrated with the process that we're trying to build.

Bledsoe: Right, so it sounds like the three things that you've mentioned there, especially right now, was that, right, you want to make sure that it makes them faster, right? So they can build it faster that it meets their needs better, as well as fits within the timing of what they want to build out. One of the things I wanted to ask you is that, we have a lot of customers who are new to the platform, which is very exciting. And a lot of times, they do come in with ideas of what they'd like to build. But if you had advice, right-- so if you roll back the way-back machine, so to speak, and when you first started getting involved and engaged in building applications, what advice would you like to have given yourself or to other customers that would help make this a better situation, a better transition, a better development of the apps and what you want to build out?

Chung: So I think the way that we did it was actually pretty good, and that's really to kind of start small with a process that you fully understand. Don't try to redo huge functionality that's already serviced by Workday. It's actually more about getting to know the system and how it works. I think that's probably the first key thing. In terms of the projects that you pick, you want to pick small ones that are not critical, that are, I guess, medium complexity. Because it involves some relationships or involves business relationships with the objects to each other. Start small there. Learn how the system works. Learn how the flow of the page and the development work so that that you can get into the process of understanding your development lifecycle, and then you can start tackling the more complex or more critical cases. Business requirements are key, to start off with, so understanding where the business comes from and talking them through it, showing them, and building out kind of what they're asking for. I mean, in some cases, when we have these business requirements sessions, we have a prototype in mind already, so that's another, I guess, good thing to have is mockup a prototype so that it helps the business understand more about what you can build. I think business is really good at kind of understanding what functionalities are and good at imagining how their kind of perfect system's going to be. And if you get into that conversation, you can actually start steering it so that you'll get to a good product that fits their needs, and it's actually reasonable to develop as well.

Bledsoe: Well, that's really good advice too because we see that a lot as well, that people want to start off with the classic crawl, walk, run approach, right? And then also, like you said, understanding your own development cycle. I think that makes a huge amount of sense in what people should be thinking about. Now, I do know that you guys get multiple requests for apps, probably far more than the two of you could conceivably build if you worked 24 hours a day. But I wanted to know, what is your decision process? How do you decide which apps you want to build and which ones you're not going to build?

Chung: Yeah, so we just recently came up with this actually right before Rising and we actually put it in our presentation in Rising, and that was two acronyms, right? We have SPACE and then SLF. SPACE is the main one that I think is useful for everybody. It's size of impact, which is just a very simple equation of benefits over cost. We have proximity to user and data. So whether or not-- we don't necessarily want to put everything into Workday, although it'd be great. But [laughter] if the users are there already and they're dealing with HR data, that's a perfect place for it, using Extend. A is alignment to roadmaps, which is about not just your roadmap, but also Workday's roadmap as well. So you don't want to build something that you know is coming down the pipe. An example would be the vaccine management piece. I know you guys came up with a Extend application for vaccine management, but we waited until the final module came out. We can get into that later if you want to. C is complexity and criticality. And then that's a ratio, right? As you are on your development journey, you want to start out with something that's simple and not critical. As you get better, you can make them more complex and less critical. And you might be able to kind of play around with that ratio to say, "Okay, well, I'm going to make it simpler but it can deal with more critical things," as you kind of get more mature in your use of the tool. And then the E, final one, is engagement of stakeholders. Like I said before, it's really important to be able to talk with your stakeholders almost every day as you're building and developing. And to basically shave the edges off of an app or of an idea that they want to build, so that it is buildable and it's usable.

Chung: The SLF one is more about whether or not there's availability of the source. So being able to bootstrap something that has already been done before and then learning from it is super important. That leads to learning, which is L. If it's an app for us that we can learn some part of the technology, we'll jump at it, mainly because anything that we learn about and we understand how it works, we can then roll that into our site impact, because then the cost goes down and our benefits stay the same. The final one is future reusability. And I've mentioned this before about design patterns that come out of what we build, and I've recently learned a new word about composability and it's exactly that. It's kind of breaking down the little parts of it so that we can reuse them in various different ways and apply them to various different use cases, and that's how you kind of build flexibility and agility.

Bledsoe: Wow, I love those acronyms, SPACE and SLF. If I didn't know better, I'd say you're a fan of our own space program here.

Chung: [laughter] I do love space.

Bledsoe: [laughter] That's awesome. Actually, I'd like to ask you a little bit more. So you mentioned the vaccine management app that we posted up on the app catalog and stuff. And I know that we're seeing a lot more customers who are expressing an interest in downloading some of those apps and then modifying them appropriately for their own business and stuff. So it sounds like that's kind of what you did, or did you do something slightly different? I'm curious.

Chung: So with the vaccine management, we actually didn't use it just because, I think, we were waiting for the actual vaccine module to come out. Part of it is because, again, small team, so we didn't want to create something that we'll have to maintain over a long period of time when we knew that it was going to become a feature of the core product. And that's that alignment to roadmaps piece. So being able to say, "Okay, well, no. Let's hold off on deploying some Extend application to do something that--" no, it'll meet the need. And I fully understand that there are [repertory?] requirements that needed that piece quicker, and Extend is really great for that. For us, we wanted to wait until that module was available and then we can start using information from it too. That's the other part that's super interesting is that we ended up building a suite of returned office applications that actually use some of that data from the delivered module instead of going just fully custom.

Bledsoe: Wow, that makes a lot of sense. Yeah, especially accessing all that other data. That's great.

Chung: Yeah, and it's one of those things, I think, you have to think about it from a bigger picture. I think everybody who's excited about Extend wants to build everything in Extend. You just have to understand your own organization and how you're set up to figure out and come up with the best and most efficient way to deliver on those solutions, right? Whether or not it is Extend or just configuration. It's all about the toolset that you have and using it to deliver the best experience possible.

Bledsoe: And I think that's really critical because a lot of times it's easy to want to build these little one-off apps that are completely standalone from everything else that you've got out there because you can run your own data models. But it's even more powerful when you combine them with what else we've got available within Workday that actually create even greater value for your customers, your employees, and stuff like that. So another thing I'd love to ask you about - and I know I've asked you this question many times before - is what advice would you give a developer who's looking to start building apps with Workday Extend?

Chung: I would say three things. First, be curious. I mean, without a doubt, I think that's a developer mindset piece. How does this thing work? Ask yourself that. How does this thing work? How do I make it better? How do I use this piece that I've seen before in other apps or how other people have used them, and how do I use it in my use case? I think that's a key thing. Being curious is very important. Learning from the community is another great thing. I mean, you guys came up with the developer forums, which is a great resource for people to kind of go in and get information and understand how things all work. Your dev site is also very good too. It's got pretty good explanations of how all this stuff works and we use it regularly just to teach and also to use some of these features. A lot of the code that's published right now, I mean, it's super useful just to pull some of that stuff out and look at how some of these widgets are configured or how some of these widgets are communicating with each other. And you can, more or less, just take that out and use it to your use case with a little bit of customization. So get involved. Learn from others. And I think the final thing is just don't be afraid to make mistakes. Dev tenant is there for a reason and Workday does a really good job of making sure that you're not going to take down the tenant with anything that you build. And so push as much code as you want to test out and try to understand how it all works and how it works together. I think that's another key thing. The more mistakes that you make and you learn from, the better that you get over the long term.

Bledsoe: Now, that's fantastic. Those are three excellent points, right? Be curious, learn from others, and don't be afraid to make mistakes. I think you can apply that philosophy to a lot of different areas in life, not just in development. But I think that's really awesome advice. Thanks again, Eric, for joining us today. It has been a fantastically great conversation. [music] I learned a lot today, myself. We also want to thank those who are listening. If you like what you've heard, please subscribe to the Workday podcast on your favorite streaming platform. Until next time, I'm Chris Bledsoe, your host.