James Hou is a developer and architect with 10 years of experience in the ecosystem. He focuses on solving complex problems in highly custom enterprise orgs and is currently a Senior Salesforce Consultant working at Google.
In this episode, James talked about how to break down a problem with the concept of XY problem from three different angles — daily tasks that affect your end-users, daily tasks that affect your own workflow, and problems that affect entire teams.
Sponsor
Proton Text is a complete SMS texting solution built for the Lightning Platform, and by one of our previous guests Pat McClellan.
Links
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] Hi, our sponsor today is Proton Text, a complete SMS texting solution built for the Lightning platform by one of our previous guests, Pat McLehame. Here is reason number four that admins and users love this app. It's seamless. Whether you're blasting to ten thousand leads, or responding with a automated text, or having a one-to-one conversation with one person, the customer experience should be seamless. The Proton Blaster component lets you blast to thousands, and then configure automated responses and forwarding to queues and users for personalized follow-up. And all of this is as easy as creating a calendar appointment. It's not magic. It's just good design. Learn more at protontext dot com. Hey everybody, this is Xi Xiao. This is yet a new episode of Salesforce Way podcast. Today I'm sitting with another new guest with me. His name is James Hou. Hello, James. Hey, how's it going? Pretty good, pretty good. How are you doing there? I'm pretty good. It's eight twenty in the morning, and I'm very awake, so that's good. Yeah, it's end of the day for me here in Finland.
[01:30] So, James, would you like to quickly introduce yourself? Sure. So my name is James, and I am currently an architect and developer at Google Play Gift Cards. So we deal with the supply chain and forecasting and production of those gift cards you see in those brick and mortar stores as you go through the checkout lane. And I've been here at this role for about three and a half years or so. I'm a vendor, so I'm actually contracting with my own company to Google. So I'm not an FTE, but I've actually built out a lot of the infrastructure on the business operations team to kind of make this stuff happen. Hmm. So you are closely working with David as well, David Liu. Yeah, exactly. So David's my manager, and we together basically are like two architects and two developers. And I'm mostly the execution, hands-on one, and so he deals with a lot of the. Road mapping, and he's more involved with the stakeholders on the business side. And when things come to about like eighty percent ready, I'm pulled in to figure out like the actual technical execution. And I've authored probably ninety five percent of the code on on this particular stack. I see, I see. So today you are here to joining us to talk about how to tackle problems, which is quite interesting because we just mentioned it's generic
[03:01] and everybody has its own way to tackle problem, right? But you want to share this, so you must have some unique experience you want to share with everybody. Absolutely, I think at a high level, the. Way to break down a problem is interesting in and of itself, and it can apply to many different levels of developers, admins, even just people in the ecosystem.
[03:30] I think just generally tackling problems is an interesting thing for me, and that's kind of why I've pushed my career like so far, and why I think it's so interesting. Is just I like solving problems, and they're not even sometimes day to day problems like you would experience as a developer or even an architect. So, what I mean by day-to-day problems are things like, okay, I have some work items today. I need to deliver some features, or my end users are having a problem. Like, how do I solve for that with like a specific Salesforce automation? There are like higher level problems, like, okay, my workflow is bad. How do I fix this thing? Like, I don't like what I'm doing and the things I'm writing. It feels like. It's repeated, and like I solved this already, like two week, two weeks ago, two months ago. How do I stop doing that? And there's other problems like, okay, the overall group's ability to deliver is not ideal. There's some friction in the software development life cycle or SDLC. How do I fix that? Like friction. How do I go about like tackling these high level problems where it involves many, many people? It involves like buy-in. It involves like influence. How do I go about like solving the problem of quote unquote fixing your SDLC? Like how do you break that problem down? And I've done that like two times in my career already. So it's been an interesting problem for I think most groups to encounter and then not really understanding
[05:01] no knowing where to start. And so my intention behind this chat today, this breaking down a problem thing, is to apply it at multiple levels. One level is around your day to day work. Another level is around like your personal workflow and like your personal like what you want to do in front of your computer. And another level would be like across your group, across your team. How do you go about solving problems that affect like many people? So that's more like a technical lead or lead developer level task, right? You write libraries for the whole team to solve some certain concrete problems. Okay. Yep. Sounds good. Sounds good. But one interesting question is: How did you summarize this into like a methodology? Did you read some books, or do you just go according to your experience? It's a great question. I don't know if there's any. Summary, but methodology. I think at a high level, it's it's kind of what we engineers do, which is we we like. Categorizing and chunking things down into like smaller problems, so we take a big problem, and then we see it's composed of. A, B, and C, and then we start thinking about okay, if you build A, build B,
[06:31] and build C, it'll equal the solve of the problem. And sometimes it's hard to see like what A, B, and C are, and sometimes you don't even know that maybe you have to build A and B together, and then you can like add C. So one of the techniques I've used—it's not quite like a methodology—but one of the techniques I've used is to apply what's called the X Y problem, which is when you're deep in solution mode or when you're trying to like deliver something. Sometimes you focus too much on the how, and you don't focus enough on the what. So, for example. The XY problem is typically applied in customer support scenarios where a caller comes in and they're complaining about like their bill. They're complaining about like their internet not working, but the real problem was like something else unrelated to the bill, something else unrelated to the internet. They're just not happy with the service, perhaps. So that's the XY problem you apply in a customer service scenario, and what you really figure out is. What's being happened in the current situation is not the root cause. So it would be really useful for you to take yourself out of the conversation and just think, what's the actual root cause of this? And one thing that we developers experience daily is someone comes to ask for some kind of ask. Hey, I want a new field on this
[08:01] custom like object. Hey, I want like this when I click this button, I want to be able to like see a thing. So, when it comes across your desk, your first gut instinct as an engineer and as a developer is to okay, how do I solve this problem? Like, if they want to click a button, let me let me do this or let me do that. But if you take a step back and you apply the X Y problem to situations like that, why do they need to click the button? Why do they need need like a new field? And then you start going about the typical like discovery of those requirements, which is okay. Something they needed to do was like two modules up ahead, and they actually don't need this button if you fix it up there. And so that's a classical example of like applying the X Y problem, which is trying to figure out what you're actually solving for, and. When you apply that concept, what am I actually solving for here? You can take that to very interesting levels around. Okay, I'm rewriting code here. Like I really don't like what I'm doing. What am I actually solving for here? And then think about how to solve for that, because if you solve for that. You solve for almost all the scenarios you can think about if you were to encounter it again. For me, is even if I sometimes go to Stack Overflow to ask questions, like the technical questions, people tend to give comments like, "Why do you need this?" Because it doesn't go natural for those people when they see your question. Maybe
[09:32] it's just weird, and I didn't even notice it was weird, and then say, "Why do you need this?" I was then thinking back. Really? Why do I need that? Why? What's the reason? Yeah, yeah. It's um, it's a pretty powerful tool, and I'm guilty of it as well. Where like. If I get too far into solution mode, I can't remember the original problem I'm trying to solve for. But what has helped me in the past is. Just understanding that the X Y problem is an actual concept, and there's a noun for it, and there's a wiki page and all kinds of stuff. If you remember this in your meetings, as you tackle problems, as you break them down, there are indeed components where it's like A B and C, but you have to understand that when you break it down, what are the reasons you're breaking it down for? And to your point, like, let's say you want to deliver a specific feature, and you get into that point where, okay, I'm solving for this, I'm solving for that. This doesn't work, so let me solve for this. Sometimes, as you go down that rabbit hole of compounding solves, like three or four hours in, you may forget. Okay, the reason I'm doing this is because they don't want to be, they don't want to like click twice or click three times. Maybe a different way to solve it. Would just to be automate that thing so they don't they don't have to click at all. So, my point here is, yes, whatever you're building is would work. Whatever problem
[11:02] you've already like chunked down and you've tackled might work, but maybe take a step back. Maybe try to understand the root cause. Maybe there's a different way to solve for it. Hmm. I remember I had the interview a long while ago with a person who just asked me, "When you encounter issues that you just cannot solve, what do you do?" I said I may just take a long break. I go out for a walk. That would take me out from this solution mode in your mind, and then you start to think back. Why do I need this? Otherwise, as you mentioned, you're really drilled into this this rabbit hole, and then you're lost there. And I think even there's one thing in programming world called pair programming. I think that also helps a bit, right? When you are doing the hands-on stuff, the other person is like a navigator at at your side to help you to to navigate through the problems. Yeah, absolutely. I think what I like to call that is a sanity check. And definitely, there are times when like my peers definitely help sanity check. Like, am I thinking about this the right way? Like, what what do you think? It's always good to have different people help you break down a problem because they might have a different lens on it, and it might guide your lens in a different direction that you never thought of. But yeah, I think in general, breaking down a problem
[12:32] is more than just applying an engineer's perspective to it. It's also also trying to understand the end user or the stakeholder perspective from it, and marrying those two disciplines. Because I am sure the most people listening to this podcast they're either admins, architects, or developers, and so they're used to kind of the. How do I fix this? How do I deliver this? And my intention for this topic is to kind of add another layer to it, which is. Okay, but how do you fix this within the eyes of the stakeholder? Like, can you can you really be put yourself in their shoes, understand where they're coming from, and then start from basically sitting in front of their computer? And one of the things that I like to apply when I break down a problem is there's kind of. Two ways to approach a problem from the beginning to the end, or from the end to the beginning, and sometimes when we get into like a solution mode, we think about it from the end to the beginning, which is okay. I want the For example, the new field thing. I want a new field, and then so you immediately think about like, okay, the end result is new field, and then you start executing on that. If you tackle a problem from the beginning, you you talk about like, okay, why do you need a new field? Is there something happening like in my data where I need to collect a new field?
[14:03] What modules feed into this section where I need a new field? Should I just fix those? And and you start thinking about from the user's perspective. Why did they need this new field? And you start looking at their workflow. You start looking into their personas as a user. Me as a user, when I sit down in front of my computer, I open up like this module, and I do a bunch of workflow in this module, and then I switch to a different app, and then I do my work in that app. Oh, and that app doesn't have this data. Like I, I need a new piece of data here. Well, if you sat down and talked to them, and you applied the X Y problem, you would see that the actual problems stem from module one. Like, if you just automate some kind of field there, you can just automatically collect that in module two. I kind of understand it as when we have a problem, we should look at it from different aspects, from different angles. Instead of just as our intuitively as engineers, as you mentioned from the end, and then go back and break it down. So there are layer above and the layer down. So we usually most of time engineers focusing on how to break the problems down into sub problems, but we kind of ignore the upper level, which is usually architect or business architect. They tend to have a better understanding. Absolutely. There's um, there's two roles
[15:33] really that really tackle this problem, and it might just be that in my career I've been multi hat almost the entire career, so I've I've been cross disciplined, so I get influenced by those roles. One of those is, as you said, the architect, and the other one is actually business systems analyst or like a business analyst, and that role typically engages with the end users and figuring out the the like why are they why do they need this. But a lot of times in this ecosystem, especially because of the fact it's a business ecosystem, the admins and developers are are much closer to like the end user and business user than other ecosystems where like it's like pure engineering and it's like network uptime. So that there's definitely, I think, a need for admins, developers to have this skill set where they rise above the engineering problem and think about it in terms of, okay, if I was a user. What's my actual problem? How do I break that piece down? Because one of the things I've learned applying this methodology to basically all my solution writing is I save myself a like double triple work if I just make sure that. Whatever workout intakeing actually makes sense. Okay, I see. I see. So you mentioned the different scenarios. You talked about the day to day work, yeah, and then how to solve DevOps process
[17:04] efficiency, something like that. Oh yeah, yeah. We can just dive that into that a little bit. So for what we've talked about, those apply to like your day to day tasks, things that you want to execute on and stuff like that. One of the things that that I found in in my experience is that there's actually something. That you can solve for, that's more related to to your specific workflow around how you interact with your computer, how you interact with like the things you're building, and. As it's it's more applicable to developers, but it's starting to get into that realm where it's applicable to admins as well, and in different ways. And what I want to talk about here is building reusable libraries or building reusable components, and those are things that I I do pretty frequently. And at first, I didn't even understand why I was doing it. Like it just felt natural. Yeah, I want to make stuff once. I don't want to have to do it again. But then the more I thought about it. There's a reason why I even came up with that problem, and the way to solve for that, the way to make reusable components, is to apply the XY problem to yourself as a developer, or apply the XY problem to people who aren't end users, but rather who are the people who are building the solution, and so. I'm
[18:34] sure you've written like a couple libraries in the past where they're like reusable utilities, or you kind of put them into a place where it operates on like an S object level, where you don't have specific things. It kind of you can kind of drop in, call it, and then you can use it anywhere. Now, why did you do that? You know, why did you come up with a reusable utility? The obvious answer is, hey, I don't want to do this again. But then, if you apply that to your solution building, what am I making over and over again? What do I want to make better for myself? And I actually have an open source repo where, like, a lot of those patterns come into that repo, which is. As I was exploring through Aura, as I was exploring through LWC, I noticed a couple things that I just kept repeating over and over. One of those things was like component communication, calling component A from component B, having like messaging going back and forth, and then sharing data between those two. I kept rewriting that, and the root cause of that was basically like there wasn't a good enough tool out of the box from Salesforce to help me deal with that. So I am going to just go build that. I am going to solve my own problem and just write like a messaging API that's really easy to use, that's really like flexible, and that can solve for all my use cases as I build out these solutions for
[20:04] my end users. And so that's kind of where I started. There was. When I sit down in front of my computer, the root cause is like I really hate typing this over and over, and I really hate just copying pasting this thing over and over because it's kind of useless. So how do I go about solving that? And then I think about my own user experience. So if I was a user, like an end user, on one of your apps, their user experience is I'm going to navigate around the menu and click a button. Your user experience as a developer is how many keystrokes do I type to like call this API? How many like letters do I have to type to like make this thing work? And so you think about that. And then, for me, what I do is I draft out an API or some kind of thing that I want to type out. It doesn't even work at all. Like, there's nothing behind this implementation. This is just my user experience as a developer. I want to be able to type these letters, and given these parameters, and I want it to give me this. I want it to do like X, Y, and Z. So I think about like. How do I want to call it? How do I want to use it? And then I go about solving. Okay, if I wanted to use it like this in step A. I have to do step B, C, D, E, F, G, to make that work, and so you start building your own tools in a way that you are your own user. And so another example was, you know what,
[21:35] related lists and list views in Salesforce are like really not ideal from a developer perspective because there's not like an easy way to like make tables. Basically, I as a developer, I just want to put a SOQL string into like a thing and have a table come out, and so. That's what I actually made was, okay. If I give this component a SOQL string, it needs to do like okay. It needs to grab the data for me. It needs to check the field level accessibility. It needs to check permissions. Also, it needs to come up with like the column definitions to like paint the columns onto the table. Oh man, that's so many like steps. But then you start from your own user experience, which is I just want to be able to like give this thing a SOQL string, and then just like magic happens and throw a data table back at me. And if you've used Lightning Data Table in LWC or even Aura components, you know that like making tables is not very straightforward. There's a bunch of stuff you have to like feed it to make it work. I didn't want to do any of that. I just wanted to make it easy, and that's why I went about solving that problem for myself. And that's kind of like the genesis of solving problems for solving like other problems or solving like you know admin or developer problems, so that you can better solve like end user problems. Sometimes I think a lazy developer.
[23:05] Tends to be good developer, because we don't want to have this extra keystroke. We always want to abstract the stuff. If things has repeated three times, then you start to thinking about to encapsulate and and make a library out of that. And recently, I also had a chat with another guests. It's related to what we just discussed here. Is when we write unit tests. Especially when we do TDD, that test driven development, if you find writing tests painful, it means your production code is not well structured. So once you you you feel your own pain. Maybe you will start to rethink about the structure of production code. If you didn't write a good test or didn't write test at all, then you never feel this pain, and you will never think from the end user point of view or the other developers who are reading your code or using your API. So yeah, yeah, yeah, yeah. And so, as you kind of encounter different APIs in the ecosystem and like different things that other other developers have built, some things will be easier than others because. They might have naturally applied the XY problem, but when they think about like how do people want to use this API, like what's the developer user experience, how easy is this thing to use, that comes off in like the APIs they make, that comes
[24:35] off in the components they make, that comes off in like kind of their overall workflow. That's that's cool. I think that's how a developer grows into a senior developer. That's just how engineers figure out and how to abstract the stuff, how to recognize the world in the more higher level dimensions, I guess. Yeah, absolutely. There's actually one more level of like problem solving that you can apply to for your overall teams. The way I like to think about it is, we've talked about the end user experience, the one where like you solve problems for your users. We've talked about how do you solve like your own problems with relation to workflow, the modules you build, and kind of your own friction as you develop these solutions. And the last one I want to talk about is actually cross team or multiple people paying, and this is typically known as the software development lifecycle or SDLC, and whether or not you have like a formal one, you definitely have one in some shape or another. There's definitely a way you hear about a feature, even if it's through word of mouth. There's definitely a way you figure out like what the requirements are, even if you're just talking about it over lunch. More more formalized processes are like business requirements documents, and more formalized intake processes are like Jira or collecting into like a spreadsheet.
[26:06] And every single team has some form of this SDLC. And the way I like to think about it is. Within a team's ability to deliver, there are big components such as the intake process. So that's the first one. The second one would be the discovery or the BRD making process. The second one. The third one is the one we're most familiar with, which is the actual delivery cycle, and this can be done in one of a few different ways. You can do agile, you can do sprints, like in agile, or you can do waterfall, which is like big bang, months of build, or you can do this hybrid, which is like an agile fall. You have like a limited scope, but you execute that scope within sprints. And following the delivery sprint, there's usually a Follow up like a UAT and QA, and beyond that is the final sprint. Sorry, the final module, which is about post launch user feedback collection or post launch like bug fixing. And so, there's like these five big areas which are all ripe for applying the XY problem to, and I think the DevOps cycle itself usually starts from the delivery cycle and onwards. So things about like pushing code or making sure your metadata from Salesforce orgs are checked into like a Git repo, those are typically the development lifecycle.
[27:36] And there are some DevOps teams which extend to even collecting feedback or like collecting analytics on the user side around what features are being used, but those are usually all post delivery.
[27:49] There's a good opportunity to apply the X Y problem to the first two modules. So then, how do you go about applying this problem solving? How to breaking down a problem into the intake module? First, you have to think about like what are the problems you have in your intake module? Is it painful for users to submit bugs? Is it painful for your user business stakeholders to look at like what's currently in the backlog? Is there a giant roadmap? How do they organize all that stuff? Making your intake process better just basically makes the friction a little bit less around how do you get work items into your queue. And the better you make this process, and also the more transparent you make this process, the better the collaboration is within that part of your process, and the better it's seen as a delivery team. That hey, this team knows what they're doing. They have a giant backlog. It's organized. It's actually pretty straightforward to kind of get work in there. Prioritization may be kind of hard because there's so many things, but at least like it's all in one place. So. You apply this X Y problem, which is the root cause of having a high friction intake process, is because maybe there's not a central collection funnel, maybe there's too many voices, there's too many people trying to like funnel things into your backlog. Maybe you need product owners, and so you kind of apply like what's the root cause to your intake module, and then you can go about solving for
[29:19] that. Going to the next module, this BRD requirements gathering, kind of the discovery phase. There's Usually, one discipline that kind of handles this, but a lot of the times there's not an opportunity for many Salesforce orgs to hire someone of that specific role, and that role is called a business analyst or BSA, and so. Sometimes we, as admins, developers, and even architects, have to take that hat under ourselves. And we have to apply like the BSA knowledge, BSA tools to help massage those backlog items, massage those intake items into a good BRD. And some of the friction that can arise from here and the root cause of any like people that are involved in this process, the pain points there are: hey, maybe like it's really hard. To deal with the discovery process or BRD process, because there's too many cooks in the kitchen. Maybe you need product owners. Maybe you need like a better BRD cycle, a better BRD phase. But this discovery and requirements area is one area where you can apply the XY problem to and break down like what exactly is going wrong in there, and specifically who's the end user that's receiving this problem? Like, are they being kept in the loop when there's changes to the requirements? Are they being kept in the loop when there's updates to mocks? Are they involved in the
[30:49] creation of these mocks? Are they involved in the creation of these
[30:56] Areas of opportunity where you can put yourself in the place of the actual end user of reading these documents and seeing what their pain is like. Hmm. To me, as a developer role, usually in the project, I get the chance to touch the downstream phases, which is the delivery part. You can talk about the DevOps, those technical terms. But on the first, the two phases you mentioned, the intake part and the requirement collecting part. Most of time, I'm out of reach on those stuff. They are collected for us, and then we started to prepare further down. Definitely, if we get the chance to be more involved in those two phases, then we're more tightly bounded with the customers. Well, we know more clearly what they wanted in the original phase. Absolutely, and there's actually a trick to this, which is. If you figure out with your stakeholders how to be involved with that process more, you will likely naturally be seen as a lead in in in future road map items. Because the more involved in upstream you are, the more guidance you can give to the teams that are trying to come up with these problems. And naturally, kind of your your role starts to grow out of a developer more into like a lead situation, even to like a technical lead, because that is kind of the domain
[32:26] of a tech lead or even like a business systems analyst. But if you're interested in that area, definitely involve yourself more upstream because it can have an impact on the branch which you take for your career. Thanks a lot, James. So before let you go, how can we reach you? How does the listeners find you? Yeah. So I actually don't have any Twitter or I don't have a huge social media presence, but I am on LinkedIn. You can connect with me there. And I'm actually a moderator on a Salesforce Discord channel, and I'm actually hanging out there almost all the time. I ask problems on there. It's Like a live chat, and then I help people solve their problems. We review like code and stuff. So definitely feel free to connect with me there. I'll send you the link for those later, and my user handle. Yes, I'll put all the information in our show notes. Thanks, James. It's really nice talking to you. Yeah, likewise.
[33:27] Hi, I'm constantly looking for good guests. If you have any guest recommendation, please reach me out. I'll make sure they are joining to the show to share their knowledge. Otherwise, thanks for listening to the show. I'll see you next Thursday.
