What are the human challenges developers typically face? Matt Weseloh, HR applications architect at Raytheon Technologies, shares his experiences with Workday development and the profound impact it has had on his career.
Audio also available on Apple Podcasts and Spotify.
While technology often takes center stage in application development, it’s crucial not to overlook the equally significant human side of the equation. On this episode of the Workday Podcast, Matt Weseloh, human resources applications architect at Raytheon Technologies, a multinational aerospace and defense company, sheds light on the challenges and triumphs that developers commonly encounter and highlights the impact of his experiences developing Workday applications.
Below are three key takeaways from Weseloh, edited for clarity. You can also find our other podcast episodes here.
“When it comes to our development methodology and choosing the right tools, we start by asking ourselves, ‘What’s the right solution?’ Which is usually answered by considering what’s available to us now in Workday Extend. I was recently asked that very question by another company on a similar journey as ours. They wanted to know how we assess whether a solution is right or not. The answer is that we analyze each scenario individually. We engage in conversations and understand the problem they’re trying to solve because it’s crucial to prescribe the right solution for the specific need.”
“From a development team perspective, we’re quite small in number. So, we tackle application development through a combination of collaboration and individual contributorship. In some cases, we’ll start new team members on small enhancements to existing applications. Then there are the bigger projects where we say, ‘Wow, this is a challenge, we need everyone from developers, support teams, and operational people who understand what’s going on,’ and we bring in the right folks we need from other teams.”
“For those wanting to become a Workday developer, start by grasping the basics. Understand how Workday operates. For example, when someone from the payroll team approaches us and expresses interest in Workday Extend, we explain that they need to comprehend Workday as a whole. They should understand its purpose, how we utilize it at our company, and our specific approach—not just its capabilities from a theoretical standpoint. On the integration side, we appreciate having team members who are already familiar with our integration processes. They possess knowledge of the available tools, recognize the opportunities, understand the limitations and constraints, and can readily contribute and support our efforts. That’s the advantage.”
Chris Bledsoe: When someone hears the term application development, the first thing that probably pops in their mind is technology. But there's an equally important side to application development: the human side. On this episode of the Workday podcast, we dive into the human side of technology and explore the challenges and triumphs that most developers face. Today I'm speaking with Matt Weseloh, HR application architect at Raytheon Technologies, who will be sharing his experience with Workday development, including the implementation of Workday Extend, and how those experiences have impacted his career. I'm your host, Chris Bledsoe. So let's get started and welcome Matt to the show. Thanks for joining us today, Matt. Before we dive in, can you share a bit of your background and current role?
Matt Weseloh: Sure. Yeah. I am currently an HR application architect at Raytheon Technologies. And when we say HR application, we're really talking Workday since that's our primary HR application. Totally makes sense. So yeah, that's what I'm doing now, but in terms of background, been in the biz for a while. Started out back in 1990 with Electronic Data Systems, EDS. And actually, it was really interesting getting started there because I was in the system engineer development program, and that was-- their hiring profile at the time was, "We do not want to hire programmers. We want to hire creatives," I had a music degree, "and we want to hire creatives and teach them to be programmers our way." And so it's this wonderful program that puts you at the customer site for the first six to nine months. Then you went to school, learned how to be a programmer the EDS way, and then you came back on the technical side to support that same customer. So a fabulous, fabulous start to getting into the tech industry at that time, which was significantly different landscape than today, but got to evolve through all the different things. Hey, the internet, it's a thing. And wow, and here we are. Started with Workday itself probably about nine years ago and then got into Extend back when it was initially Workday Cloud Platform right at the very beginning about seven years ago, and here we are.
Bledsoe: Oh, that's fantastic. One of the things you mentioned, which is really common - I find this from a lot of engineers and developers - musical background. So I got to know. What musical instruments do you play?
Weseloh: Keyboards. Piano was what I started, my mom teaching me at age five and ever since, but also percussion and brass. And I sing and like to record stuff, so.
Bledsoe: Well, that's fun. Well, maybe if we have time later, we can record a couple of songs together. Who knows?
Weseloh: Sure.
Bledsoe: So you've been a developer now, and you've been with us from the very beginning, which is fantastic, as a part of the Workday Cloud Platform. So what was it like to become a developer? What was it that helped you learn and grow in that experience?
Weseloh: Yeah. Becoming a developer really was that formative experience of being taught to be a programmer, taught one way and then, of course, learning over time. It was fascinating coming back, especially initially there, to serve the same people that you were on the business with, to serve them in a programming or developing capacity and seeing, "Hey, I can help you. I know the pain, and I can help you with that pain, and I understand how to do that." And I think that was really a formative kind of thing for me that I've carried forward, always trying to understand, "Okay. It's not about me. It's about you and the problem that you're trying to solve, helping you describe that problem to me because I can't help you-- just like a doctor, I can't help you if you can't describe the symptoms and what's the pain you're really feeling." And yeah. And to me, that's also the best feeling in the world when you can create something that really helps someone out. And I especially love it when you can design something that solves the problem that they didn't know they had, and then they get to that point and go, "Oh, that's not a problem. Oh, this is great. Thank you."
Bledsoe: Oh, that's so awesome. Now, as you became a Workday Extend developer, what kind of Workday background did you have, or what kind of Workday learnings and stuff that you did prior to that?
Weseloh: Yeah, so I had been getting into it originally with Workday from a-- you would call it maybe an HR systems kind of perspective where-- went to a report writer and calculated fields. Went through all the integration classworks, the possibilities there, and was doing some Studio development originally, which was a natural fit for when Workday Cloud Platform came along and cracked open the doors, as it were, to be able to look inside the building and say, "Oh, look at all that cool machinery in there. Can I play with some of that?" "Yes, you can." And there we go.
Bledsoe: Well, that's really cool too because when I talk to a lot of different developers, many like yourself come from an integrations background and understand that really well. I'm kind of curious too. So when you build out Extend apps, how many times do you actually need to pull in something like a studio integration to build it out? Or are some of your applications more like 100% Extend, or-- I'd love that to learn more about how you do that.
Weseloh: Yeah. The tools in your toolbox, you get most comfortable with the tools you've had the longest, right? And so it is a transition now to get us to let go of some of the old crutches and some of the old tools. Now, we have several-- for instance, we just built an application-- well, actually, just; two years ago, built an application, which before model components and before orchestrations were available, all we had available was to glue things together and call the web services was Workday Studio Integration. So that's what we built, and we've kind of even carried some of that forward just because the strength of some-- Studio's really good at a lot of things, and cloud logging and all of the abilities for us to build restartability, recoverability, and all of those bits into it, we're comfortable with the toolset. We know how to make it do that. It's repeatable from a support perspective. We have to think about the operation side, supporting it. Once we get that thing into production and it's not our baby anymore - it's someone else's - how are they going to support it?
Weseloh: So we're at the transition point right where orchestrations are growing up. They're becoming more and more capable of handling some of these things. Doesn't do it all yet, but it's getting there. And so we're, I would say, in that transition phase where certainly not have-- there's only a couple of cases where our fairly simple applications that we've written-- we did one for extending the contract end date of contingent workers, just making that a very simple thing, and we put orchestration on the back end of that and took care of it.
Bledsoe: That's great. So now you've built a number of different apps. Do you have any favorite apps that you built, that either you did a lot of work in and you're just really proud of the work or just had a significant impact in the business?
Weseloh: Yeah. Well, and I think the answers are they're all my favorites. No. "Which child do you like the best?" No. The answer is really different based on which ones are impacting the most users. Well, the things that we've rolled out for managers, particularly, have certainly had the most significant impact. They're the ones we've got the most feedback on. Not necessarily you wish that people would come and say, "Oh, this is incredible. It's the best thing that I've ever used," but a lot of times, what you'll get is, "Well, it wasn't so bad." So we get that kind of feedback on that, but some of the ones that have been the most fun and that we're proud of to have worked on are the things that really automate things, really take away all of the work. I talked to our security team last night because I was asked the question after a presentation yesterday. "How much did that security request, extended security request processor actually save?" And they said that it would take them three to five days to process. The SLA is three to five days to get those requests processed. And it went to, with the Extend app, once that approved button is smooshed by the security team, two minutes.
Bledsoe: Wow.
Weseloh: And all those security assignments are done. Boom. Yep, and they're right. They're right.
Bledsoe: Yeah. And that's huge. Well, actually, really interesting to think about, too. When you approach a new app project, what kind of methodology do you guys leverage to make sure that you make the right choices, the best choices, and the best designs?
Weseloh: Wow. Yeah, that's a great question because the toolset keeps involving, right? So we've got a Phillips screwdriver and a flathead screwdriver. Oh, and by the way, we've got these three others now. Oh, and here's this other thing that actually ratchets while you turn it, so this is amazing. So that question is kind of answered by, well, what's available now? What's available to us now? And then there's always this, especially with larger companies, this risk aversion thing where it's like, "Well, has it been done before?" And if the answer is no, then it's, "Well, let's think about that." And so there's part of that that enters into it. So I wish I could say, "Yeah, we go through this checklist and it's like Extend or no." No. In fact, I was asked that very question. I was talking with another company who was on the same journey as us, and they were like, "So what do you use to assess whether this is the right solution or not?" And the answer was, "We take each scenario individually and we talk and we understand what problem it is they're trying to solve," because it's really you want to prescribe the right medicine for the need, so.
Bledsoe: Yeah, that totally makes a lot of sense. It's interesting too. If you look at-- we've released a lot of technology in the last year and a half. We've released a lot of technology in the last, oh, three, four, five months, to your very point. So the stuff that we've done, what's got you excited? You're like, "Oh, that's really cool. I've got to get into there and try that out."
Weseloh: Oh, seriously. I mean, I think with every one of the KSS calls and every one of the calls that we're on, it's like, "Seriously, that's out now? Oh, that's awesome." We're excited, of course, about some of the new services, the AI/ML services that are being released, and how you can plug things in in new ways. I'm trying to think of a specific thing that, when I heard that, I was like, "Oh, that's going to be awesome." And there's just too many. I can't think of one in particular. But yeah, it's like Christmas every other week. It's great.
Bledsoe: That's fantastic. So when I talk to developers, we've recently came out with a product called App Builder. And you've been with us from the beginning, so you've known IntelliJ for years, right?
Weseloh: You mean I'm going to develop using Notepad? That's incredible.
Bledsoe: So, I assume you guys are probably still predominantly an IntelliJ shop, or have you guys had a chance to really play much with App Builder?
Weseloh: We're starting to turn the corner. Right. Yeah, and so it's funny, the whole perspective of new guy versus old guy. The old guy's been doing this for two years, and the new guys just started last month. So the new guys are like, "App Builder? Yeah, that's sweet. What do you mean IntelliJ?" And the guys who've been at it for a couple of years are like, "Yeah, no, not ready yet. No. Yeah, I got--"
Bledsoe: Well, that's actually interesting too. So you say you have a team of multiple developers building apps and stuff together, right? So when you think about how you guys divvy up the work, right, so usually, it's very common when you build an application that, every now and then, you have people that-- one person build one app. Not as common, but oftentimes, right, you do different pieces. How do you guys approach that kind of work?
Weseloh: Yeah. Well, we are actually, from a development team perspective, quite small, so it is collaboration plus individual contributorship, certainly. Usually, the lead kind of dictates the path that things are going to go down, and it's like, "You do this," and in some cases, if it's a small enough thing-- like we've got somebody who we're bringing in, training up now, and folks who are on the integration team are, of course, "Hey, can I get involved with that?" Let's ease you into it. And so it's like, "Okay, here, build this. Let's see what you come up with." So we've got that. And then there's certainly the bigger projects that are like, "Wow, this is-- yeah, this is a challenge." And the other side that's opening up, obviously, to us now; you'd think that we would have thought of this before, but you start to put these things into production, and they need support, and they need operational folks to be able to understand what's going on. Because honestly, the whole concept of supporting Extend apps is different from the way that we support our-- and other integrations and the other day-to-day activities, the way that we can figure out what's working, what's not working. And we're bringing those folks into the mix, too, so essentially saying, "Hey, on the operations team, we need somebody to be able to do initial trouble-- tier one, tier two, that kind of troubleshooting. And guess what? You can't look this up in the same way that you used to look other stuff up or to check something out or to figure it out. Did that work? Didn't it work?"
Weseloh: So what we're finding is that we're bringing in people kind of all around the hub of the wheel. So we've got the developer side, we've got the operations side, and the people are on the configuration side and in the middle. And of course, you get to dictate what configuration is possible in your Extend app by using model components to drive things parameter-wise and that, which is a pretty sweet capability that comes along with it. And so our customer is along for the ride too. We built an application recently for executive stock option choices, so they get to choose. "I want this flavor. I want this flavor. I want this flavor." It's a process that just happens once a year, but it's really important. And so we have designed the application in such a way that the team that owns that process now can say, "Okay, it's time for the next year. Here's the start date, end date. Here's the information that I want to be displayed. Here's the options." And that's all table-driven from the model components that we've put in the background. So developers, customers, operations team, configurators, we're all coming to the table, playing our different roles, playing our different parts. And it is a bit of a journey, right? We're learning that, "Oh, that's not going to work," so.
Bledsoe: So I imagine, with a company like Raytheon, you probably have a lot of people coming to you going, "Hey, can you build this? Hey, can you build this? Hey, can you build this? Oh, no, why don't you build this? This would be really great. I want you to build this." How do you decide which one to build and why?
Weseloh: Yeah. There's emails in my inbox right now. And it's success breeds success, right? Success says, "Hey, you built that. Can you do this? Can you do this?" And we do have to say no, and we do have to come back and say, "Tell me more about what problem you're trying to solve." Because this doesn't change the way that we've always operated, right? We still need to know what you're trying to do. It always happens, right? People come to us with the solution, right? "Here's what I want." No, I'm the doctor. You're the patient. Tell me your symptoms. What's going on? What's happening? What are you trying to do? We have to step it back and say, "Okay, let's talk." Because honestly, it looks like a good silver bullet, but it isn't, right?
Bledsoe: Exactly. So you've been to all the-- so you've been around from the beginning. I assume you've been to every DevCon, whether it was virtual or in person, right?
Weseloh: Right, yeah.
Bledsoe: So this year, it's a new year. It's gotten bigger. It's getting better, hopefully. What do you like about DevCon? What is it that you enjoy, and why do you want to come?
Weseloh: Well, yeah, it's a different experience, unlike any developer conference. Certainly, it's not Rising. Unlike any developer conference, maybe it's just because I've been able to get in on the early aspects of it, having been around on the journey for a while to see it grow to this, to become this, and yeah, it's just a great opportunity to share successes, failures, realities with other people who are going through the same journey. And I'm a very strong believer in, if we can pave the way for someone behind us and make their road easier somehow, let's do it. And this is a great sort of meeting of the minds that allows us to do that. And all the wonderful production that you guys are doing with the recordings, I can't tell you how many times we've referred back to last year's content and said, "Yeah, this is what we-- this is what we learned. This is what we heard." And I'm honestly sort of overwhelmed by the amount of information that I've already processed here, and I wish I could clone myself and go to all the simultaneous things that are happening because that's not possible. But thankfully, the rest of our team is virtually attending and going to be able to-- we'll be able to pull that all together in the end. So looking forward to that, and I'm sad for the little nuggets that other people are like, "Did you hear about--" "no. I was at this other session."
Bledsoe: It does the heart well to hear this good stuff. I love that. So if somebody came to you and go, "Hey, Matt, I want to become an Extend developer," what would you tell them to do? How would you suggest them to approach it?
Weseloh: Well, yeah, let's see. It depends on where they're coming from, I think, really. I would say get to know the basics. How does Workday do things? If somebody comes to us-- for instance, we got people from the payroll teams coming in, and we don't have Workday payroll. So they're coming in like, "Oh, that's shiny. I want to do that." And we're like, "Okay, you got to understand Workday, what it is, what it's doing for us, how we're using it, not just what it can do. I don't need you to go to textbook school and understand what theoretically is possible. How are we using it?" And then, once you understand that-- now, and then the integration side. That's why we love to have the folks who are already working on our integration side of things, already kind of know what tools are in the toolbox, understand the opportunities, the limitations, the constraints, and then be able to jump in and help us out. That's the thing. It's hard to tell them, especially the folks that don't have that kind of experience. You got to say, "I'm sorry." But it's the reality.
Bledsoe: Yeah. That is true, and it's interesting too. I always love to find out how developers learn because, obviously, with DevCon, and certainly, as part of our developer relations and developer program, we're constantly trying to figure out, what does the developer need next, right? So whether you're a noob developer, right - you're just learning how to do it or maybe you've been doing it for six months to a year, or you've been around like yourself and done it for years, right? So we're constantly trying to think about, "Well, what are ways, and what's content that we can provide and make them more effective?"
Weseloh: Okay. Yeah. You know what? And you just made me think of, obviously, the developer site. I mean, we have taken advantage of the fact that we can have X number of people on the developer site, and we've got a lot of read-only folks who are not-- so we've got members, not developers. And we've got them. "Please, take a look. Take a look at these reference apps that we've got on the dev site and get familiar. Just immerse yourself in this content because it really is awesome." Literally, I mean, the developer community and everything that you've built-- I have not met a single person who said, "Oh, that really wasn't very useful to me."
Bledsoe: Well, I don't know. Having been here from the very beginning myself, when I started, we had zero developers, right? And now, we're over 4,000. And so, remember what the dev site used to look like to what it is today. It's night and day. And people who are on it now are like, "You have no idea how far we came."
Weseloh: Exactly. I remember, yeah, it was early on coming to Pleasanton. I can't remember, but in a conference room with 15 other people, we were talking about version 0.1, maybe, of custom BPs. And we're like, "Can it do this?" "No." "Can it do this?" "No." "Okay."
Bledsoe: Yeah. No, I totally hear you. Now, I know we asked you this question. I'm going to ask you again. What would you like to see us do next? What would make your life better, easier, faster, or quicker?
Weseloh: Well, one of the challenges is everybody's building these really great apps - and this is a hard nut to crack; I don't know that we can crack this easily - but they're all unique to their company in some ways. There's some data structures or there's some rules or some logic or something that is unique or proprietary, and it makes it hard for us to share anything but the concept with other folks. And as developers, we love to leverage, plagiarize, whatever you want to call it, what someone else-- I mean, if somebody's already paved that road, why do you want to just hand me the asphalt? So yeah.
Bledsoe: No, absolutely. I agree with that. And it's interesting too because I know most developers-- that's why we try to create multiple content types, right, because different developers learn differently, right? Because some of the developers we've learned like instructional-led design. Not instructional-led design, but instructional-led-- they want to learn from a teacher. Some people, they just want to start reading docs. Some people, they just want to download an app and just take it apart and just figure out how it works, right? And then a lot of people, we want to make sure that they have, like you said, code snippets and stuff like that. It saves you time, right? And that's what a lot of people are looking for. So if you think about it, how did you learn? What helped you the most, or what you really appreciated using? Is it that kind of learning?
Weseloh: Yeah, great question. Yeah, I would say it's not reading loads of documentation. That's not me. I'm a visual learner. So if you can paint me a picture of something, I can get it. I'm also not fond of being told something for an hour and then said, "Okay, what did I just say?" No. So yeah, visual learning and then code. Give me some nuggets that I can just see. Let me see the guts of that thing. Oh, now, I got it. Okay.
Bledsoe: Yeah, absolutely. I've seen all types. And it's fun to be able to provide all of it because we're always trying to figure out how to do that, so. Well, one last question, and then we'll let you out of here. What are you excited about building next with Workday?
Weseloh: Yeah. We've got several apps in our pipeline that we're building, and so that's always what we're excited about building next, is solving this new thing that-- whatever it is, delighting someone with the results. Just really being able to leverage some of the new bits, the new ways to solve these problems that you have available, the pace of change has been so fast. You're coming out with so many new things, I mean, it seems ridiculous for me to say that our two-year-old applications need refactoring because there's a whole new way to do it now, but it's true. And so that's really what excites us is, "Oh, I want to be able to use that thing." Again, risk-averse. "Has someone else already done it?" "Okay, yes, they have." "Okay, good. Let's use that."
Bledsoe: Well, that's fantastic. Well, first of all, thank you very much for being on this podcast. It's been an absolute joy to talk to you.
Weseloh: My pleasure.
Bledsoe: You've been listening to the Workday podcast with our guest, Matt Weseloh. If you've enjoyed what you've heard today, be sure to follow us wherever you listen to your favorite podcast. And remember, you can find our entire catalog at workday.com/podcast. I'm your host, Chris Bledsoe, and I hope you have a great workday. Thanks again for joining us, Matt
Weseloh: Thank you.
Check out highlights from our developer conference, including new tools and platform capabilities, partnership announcements, and how Workday is using artificial intelligence (AI) and machine learning (ML) to help developers create applications that drive business growth.
Workday Rising San Francisco may be over, but you can now watch sessions, event highlights and interviews from the live broadcast all available on demand.
Watch Now
More Reading
We’re thrilled to celebrate our nonprofit customers who continue to provide critical services through their agility and dedication. Read on to learn this year’s category winners for the Workday Industry Innovation Awards.
In an era of constant change, staying ahead of the curve is crucial. In this installment of the podcast series Shift: Moving Financial Services Forward, we talk with Circle’s chief people officer about the talent management challenges shaking up the financial services industry.
Healthcare payors from across the U.S. gathered together to share best practices for implementing new technology as well as lessons learned. Read on to see the highlights and key takeaways from their discussions.
