Join us as we take an insightful journey with Salesforce Architect, Mike Topalovich, who uncovers his unique career path, starting from his early introduction to coding as a young child, and leading up to his current role in the Salesforce ecosystem. As he recalls his days writing script language programs, working with HTML, CSS, and JavaScript, and using Siebel systems, you’ll gain a better understanding of how technology can be used to simplify and enhance people’s lives.
In our conversation, Mike also discusses the convergence of AI and architectural design. As we tackle the concept of ‘move fast, break stuff’, we consider its relevance and limitations. We also delve into how AI is transforming the design process and the potential for feedback loops to foster positive human-machine interactions. Mike also shares his perspective on the importance of UX design in creating positive user experiences. This is an episode brimming with lessons, insights, and stories that are bound to resonate with developers, architects, and technology enthusiasts alike.
Show Highlights:
- Mike’s emphasis on user experience and technology’s potential to simplify lives, illustrated by his stint with Siebel Systems.
- The intersection of AI and architectural design, and its implications in terms of innovation, risk management, and enhanced design processes.
- The potential threats of AI and quantum computing in the hands of state actors.
- Mike’s thoughts on UX design principles, psychological safety, political safety, and their application in creating secure and efficient systems.
Links:
- LinkedIn account: https://linkedin.com/in/topalovich
Episode Transcript
Mike Topalovich:
Well, yeah, we should be super excited. We should be like, “Hey, this is awesome,” but the hype cycle for… After ChatGPT, GPT-35 got people’s attention, and then GPT-4 was like, “What just happened to us?” For me, it just opened up just whole new ways of thinking about things.
Josh Birk:
That is Mike Topalovich, Salesforce architect. I’m Josh Birk, your host of the Salesforce Developer Podcast. Here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Mike about a wide range of topics, especially, however, the role of architects in the Salesforce ecosystem. But we are going to kick right back off to, as we often do, with his early years.
Mike Topalovich:
I don’t know if I always wanted to get into it but I just got into it. I was five, six years old, I remember there was Christmas morning at grandma and grandpa’s house, and I got a computer. I got a Commodore VIC-20.
Josh Birk:
Ooh, nice.
Mike Topalovich:
Had 20 kilobytes of RAM at the time, not 20 megabytes, not 20 gigabytes, 20 kilobytes. My uncle Eric was a tow truck driver and decided one day that he had higher aspirations in life, so he would go to school at night to learn how to essentially write BASIC. I don’t know what he learned on, but it was TI-BASIC or whatever, but he taught me TI-99 BASIC. So that was my first programming language. If you think of Trailhead and how people are going back and learning tech skills later in life, this was the model for that.
He went back and learned how to code, taught me how to code at a very early age. By the second grade, I was writing Math Blaster! programs for my second grade class, so computers found me. They’ve always been a part of what I do, but in terms of actually wanting to do stuff with computers, I’ve always been more interested in what you can do with computers, like, “How do we use these things to make our lives better?” So that aspect of the technology, to me, has always been fascinating, but computers are the tool, they’re the means to the end.
Josh Birk:
Right. Fun fact, I almost didn’t get into computing because when I first started, quote, unquote, “programming”, all I wanted to do was put in the maze game that they had. Remember, I think it was Computer World or something like that. It was like, put this code into your compiler and boom-
Mike Topalovich:
Oh, yeah.
Josh Birk:
… you have a fun little game. It’s like, I didn’t even know what a syntax error meant at the time.
Mike Topalovich:
Right.
Josh Birk:
… but I got a lot of them and was so annoyed by the experience that by the time I went back to Logo, I think, was my first college programming language, I was like, “I don’t know if I want to do this.” Now, it’s-
Mike Topalovich:
I learned the same way. For me, it was Family Computing, was the magazine, and it was early ’80s. But it was like general BASIC, so it was supposed to work on Apple BASIC, Commodore BASIC, whatever, but it was the same thing. I would get into it, I would write 100 lines of BASIC code, 20, go to 10, and at the end, it wouldn’t work. You go to run your program, it wouldn’t work. I would have no idea what was going on, so it was the same thing. I was memorizing syntax without understanding what was going on.
But through just doing that and reverse engineering computer programs, really, really early computer programs, I got into the minds of the people who wrote those programs and just figured out, “Okay, well, this is what they intended this language,” or, “This is what this is supposed to be used for,” I figured out the best ways to use it, apply that. Even back then, that’s how I learned to code, was, “Why did the programmer do this? Oh, because they want you to input something. They’re going to process that input and it’s going to provide an output somewhere else.” It was just breaking things down into process and then figuring out how to apply some level of automation to that.
Josh Birk:
Yeah. Yeah. Well, to keep on this thread, it’s like my failures, I think most of that was on a Commodore 64, but I learned how to type. I got really good at typing because eventually, I’ve realized that was my problem, was I kept putting things in manually that was incorrect.
Mike Topalovich:
Sitting there pecking with your two index fingers?
Josh Birk:
Exactly. So later in, I think it was, God, it was either junior high or high school, it all blends at this point, so on that note, one of the best things that I think any teacher has ever told me, so we’re in a computer lab class, and it’s all Apple IIs and the old green screens and stuff like that, and he said, “Now I just want you to remember there’s nothing you can do that’s going to harm these computers. So if you get done with an exercise and you want to go take it apart and put it back together again, there’s nothing you can do that’s going to harm these computers.”
It gave me this sense of freedom, like, “Okay, once I did the homework, I don’t have to do the homework anymore. If I want to see what happens, if I do a go-to line 4 million times in a row…” I don’t think I did that, ’cause who wants to see that? But anyway, it was comforting to know that even though I could make mistakes, I could do no harm kind of thing. I think that was when I was like, “Okay, code can be playful. You can go in and break it, take it back apart again, put it back together again, and then see what happens.”
Mike Topalovich:
Well, and when you break it is when you learn stuff, when you have the unintended consequences, when you have an exception like we have today. When an exception is raised that you didn’t expect, you learn something about the behavior of your code. Back then it was just something, it spit out some compiler code and you had to figure out what that meant, but it taught you something, right? That’s how we learned because just in the Salesforce space, I think a lot of developers who are getting into the space struggle with the initial use case, like, “Okay, I know I want to learn how to write code. I’ve gone through all the Trailhead modules, I’ve done the examples. I’ve found some stuff online, but I need to write some real code. Where do I find a real use case?” Without that real use case, where do you start? So just having the use case, having something to start with, for me, running into bugs was a way to really dig deep into stuff.
It’s interesting now at almost 50, I’ve got a few years before I hit that milestone, but the way I think of things now versus the way I thought of things way back in the day when I was writing code, it was the same way our brains worked going through… I went through the public school system. It was all about memorization. You memorize how to do stuff. So I memorized syntax and I memorized… it was like how GPT works now. I was a transformer just trying to figure out what came next, and eventually, I figured it out on some level, but there was no meaning to it. So now going back and learning the meaning behind these structures and how to apply them this again, it’s when you are starting out, you need those use cases to point you in different directions. You don’t really want to try to go down a specific direction when you have no idea what any path leads to, but finding that use case, finding that driver, just something pukes on you, cool, let’s go in and fix it and tear it apart.
That’s like you’re describing, you can’t break it, so tear it apart. Let’s reassemble it, learn how this stuff works. Then over time, you just figure out, “Wow, human beings really all think in similar ways.” So the way that this computer that I ripped apart in school because I was allowed to do so and reassemble it, it actually conceptually works the same way a computer program does. It’s got these different components, these different modules, how do they all come together? You start to develop this really modular thinking, and you start to learn how to break down these different structures of how humans apply thinking. This is where you start to get into architectural thinking.
This is when I sit down to design a system, when I sit down to design an application, really all architecture is, all design is assembling pieces. So when you ripped apart the computer, you saw it had a CPU, you saw it had… I’m trying to think of the computing architecture back then like an ’80, ’86 processor or whatever you were ripping apart at the time. It had different components that came together on a motherboard to serve specific purposes. Now we’re in a digital world where we’re talking about stuff where it’s like, “I don’t know if this is real or tangible or if it’s just a digital concept,” but we’re still reassembling things in that way. So breaking things apart, tearing things down and rebuilding, great way to learn. You just have to have that starting point.
Josh Birk:
This is totally adjacent, but I just love the visualization that if you popped open a Commodore 64, I think I did at one point, and my reaction was, “What’s all this empty space? What’s this motherboard doing that doesn’t…” Then I think about putting together my niece’s MacBook Pro where you have to dig through four layers of hardware just to flush out the hard drive and put it back together.
Mike Topalovich:
Well, it was like when you used to be able to maintain your own car, right? Because-
Josh Birk:
Right. Right.
Mike Topalovich:
… you can pop the hood and you knew where everything was. Now with modern cars, you don’t want to do that because probably it’ll void your warranty, number one. But number two, I just wouldn’t know where to find anything. See a computer’s like that, Commodore was like, there’s a bunch of ribbons in there. It’s like, “What are these stupid ribbons doing?”
Josh Birk:
Exactly.
Mike Topalovich:
You follow them back to these pins that are soldered onto the motherboard. It’s like, “What does all this stuff do?” Again, I didn’t really learn unless I had a reason to learn, so I would dumpster dive for old computers and modems. That’s how I got online was I would dumpster dive for 1200 baud modems, and I learned how to use serial line internet protocols slip so that I can get on the internet in the early days.
Josh Birk:
Oh, yeah.
Mike Topalovich:
This is all fascinating to me. Now today, looking back on that and how primitive those technologies were, but how cool they seemed and how advanced they seem at the time, where we are right now as a society and then just as a technologist, what comes next? This is just an insane period of time. What do we get to do next? Just from these primitive beginnings to where we are now, we’ve just come so far, done so much cool stuff. What do we do next?
Josh Birk:
Yeah. Did you ever run a BBS?
Mike Topalovich:
I did. I did run a BBS. Oh, man. So yeah, Commodore 64 BBSs, I’ll give some shout-outs. Jester’s Court was a big one because back then, I got busted because I would go on BSSs super late at night so that my mom wouldn’t pick up the phone and hear the modem buzzing sound. But I got busted because I didn’t realize there was A band, B band, C band and D band calls. This was Ameritech back then-
Josh Birk:
What?
Mike Topalovich:
… which through-
Josh Birk:
Really?
Mike Topalovich:
… probably 30 acquisitions is now part of AT&T. All of a sudden, my mom brings me this two-inch thick phone bill and all these-
Josh Birk:
Oh, God.
Mike Topalovich:
… BBSs that I had been calling in Wheaton, Illinois that I didn’t realize was so far from Carey, Illinois. I was like, “Oh, man, these are expensive calls.” So yeah, I got busted. So I then had to really focus on A band BBSs, so I found a couple of those. Then I volunteered to be the, what was it? The CIS op? And-
Josh Birk:
CIS op.
Mike Topalovich:
Yeah.
Josh Birk:
Yeah. Yeah.
Mike Topalovich:
So I was the CIS op of Jester’s Court and a couple other BBSs, and then I actually got connected with a guy who was running a BBS. This was a more mature BBS, this is not like a Commodore 64. We were in the IBM days now pre-internet, and this dude ran a really cool BBS called Cloud City online. Again, just because I like working on this stuff, I volunteered to be CIS op and got really involved in it. This was right around the time the commercial internet was becoming a thing, and we actually turned that BBS into what you would call an ISP now. It was like 12, 2400 baud modems or 45k modems, whatever it was at the time.
Josh Birk:
Right.
Mike Topalovich:
All we were doing was routing people to the public internet. Funny story, this guy actually had the domain name cloud.com, which imagine today would be worth bazillions of dollars. It looks like it just expired, and somebody else picked it up, but-
Josh Birk:
Oh, my God, that’s too much.
Mike Topalovich:
… BBS to internet transition was just a huge, huge, huge moment in my life, and everything after that point was all internet all the time.
Josh Birk:
Well, to me, I think that was the first time I had to… Being a BBS user is one thing. It’s a series of menus. You go in, there’s a series of menus, but being a CIS op and actually hosting a BBS, you actually need to understand, going back through those, figuring out the modular parts, you have to understand how it works or you’re not going to get it up and running. Yeah.
Mike Topalovich:
Then even within that, you got to figure out what people want to use, like, do they want to use the discussion boards? So some BSS people were active on the discussion boards, and that was the niche, the MO of that particular BBS, some of them were about downloads. We were downloading pirated Commodore 64 software all the time. That was what we used it for-
Josh Birk:
I know.
Mike Topalovich:
… but then eventually, IBM software, or DOS, right? Like DOS programs-
Josh Birk:
Mm-hmm.
Mike Topalovich:
But that’s what the BBSs were there for. That’s what we used them for. So as a CIS op, yeah, you had to learn how all these different components work, but you also had to understand just what people wanted to do with all this stuff, ’cause I remember on one BBS, I tried to resuscitate the message boards and people just didn’t use them. All of a sudden, they got flooded with all these feeds from all these different BBSs that they didn’t want to see, and they yelled at me as the head CIS op. That was my first experience with bad user experience-
Josh Birk:
Bad user, right.
Mike Topalovich:
I’ve been cognizant of UX since that point forward.
Josh Birk:
Nice. Well, so I think you’ve been describing it, but because you started out more purely in development, how have you gone from a developer to just more formally an architect?
Mike Topalovich:
The long and winding road, as Sir Paul McCartney would say. If you look at my career, and I had to look at my career when I was putting together my resume last year, and what I found was, number one, you can’t stick 30 years on a two-page resume, I’m sorry, what anybody tells me, it’s just not possible.
Josh Birk:
Right.
Mike Topalovich:
But I was looking at all the different stuff that I’ve done and trying to break it down into, again, modules, components, because that’s what I do. What I found interesting about my career was I bounced around and did a bunch of different stuff in a bunch of different technical domains just because I wanted to master it. I wanted to learn it.
Josh Birk:
Gotcha.
Mike Topalovich:
So I started out writing basically script language programs, BASIC didn’t really go beyond that. I got into HTML writing webpages, CSS when it came out, JavaScript. So my first real IT job was building webpages. It was one of the first commercial websites for this bank in the north shore of Chicago here. So I did write code, but again, I was always trying to find new ways of doing things, new ways of applying what I do. So at that point, I was bored with just writing web content. I was bored with all the stuff I’d done before, which is more network connectivity.
So in that aspect, I had been a network architect for some period. I started out with token ring networks before we even had ethernet. I did that. Now networking, it’s a commodity, right? On the wider scale of things, it’s not where I wanted to be. So then I moved more into servers. I went from Novell to Windows, and I learned Windows NT. It’s like, “Okay, I kind of like this Windows stuff,” so I got into NT. I got into messaging, so I became a messaging architect. Really, the architect piece of all this was just designing the system and maintaining the system, not…
Josh Birk:
Got it.
Mike Topalovich:
I didn’t do a lot of builds. I either had people who did the builds for me or it was part of my purview. But as I grew in my career, I found myself just building more and more complex systems until I finally got to Siebel Systems in late ’90s, early 2000s, which the early precursor to what became Salesforce, because all of our executives ended up at Salesforce at some point. But we get to that point, and I’ve realized I’ve worked on networking, I’ve worked on infrastructure. I’ve looked out into the data center to see, “Hey, look at all these machines with their green and blue blinking lights. This is awesome.” I wanted to do more and more and more and more. So I started to get closer and closer to the application architect level where it’s taking enterprise applications, it’s taking software, it’s taking custom code and now going out and releasing that into the enterprise, running your business on that type of software.
So Siebel afforded me that opportunity to move into the enterprise, move into enterprise applications. I managed a portion of the internal implementation of Siebel. I managed a portion of PeopleSoft. I had my hands in a lot of different places, and I started to see all these different connections between the infrastructure piece, between the networking piece, between the server piece and now applications and programming languages. So it just set me off in a bunch of different directions. But what ended up happening was at Siebel in the early 2000s, I just reached a point where I became bored with technology, or at least I became bored with answering questions, sounding like an IT guy. So when a business would come and say, “Hey, we’re looking for a system that’ll do A, B, and C for us,” the default response was something like, “Well, how many servers do you need?”
We were not speaking the same language, and that frustrated me to no end because I just wanted to take what they needed and build something, again, my technology to make their lives easier. That’s where I pivoted more into business process design and business architecture because I had been influenced by a number of authors. I’d gone to see a number of seminars in the early 2000s that were focused on business process reengineering and getting involved in that concept. I was able to take the technical skills and now apply them to the business process and business workflow side of things, understand how businesses work conceptually, break that down into the individual components just like I would a computer program or a computer system, and it started to make sense. All this stuff started to make sense at a very high holistic level across an enterprise. I started using the term enterprise architect probably 15 years ago before I even got into the Salesforce space, because that’s what I saw. It was the marriage of business and technology to create that alignment.
Josh Birk:
Yeah. So speaking of, how did you first get introduced to Salesforce?
Mike Topalovich:
So Salesforce, if you’re familiar, there was this show on HBO back in the day called The Sopranos. Not many people have heard of it.
Josh Birk:
It’s a tiny indie gig, I think. Yeah.
Mike Topalovich:
Actually, Little Steven is here in Chicago this week at Wrigley Field, part of the E Street Band, but I digress. But Little Steven had that role. He was Tony’s right hand, the consigliere. If I butchered that, I apologize. But he said, “I try to get out and they pull me back in.” He was quoting a movie, “I try to get out, they pull me back in.” something about that line just stuck with me because with CRM, I had done CRM for so long at Siebel that just didn’t want to do CRM anymore. I go on these three, five-year cycles, I’m like, “I just don’t want to do CRM anymore.” So I tried to get out, and then again, I tried to get out and I got pulled back in. How I got pulled back in was I was sucked into this idea of this early concept of platform as a service.
This was the early days of the cloud where it’s like, hey, I could build little modules of business logic and then assemble them into applications that small, mid-size enterprises can use to automate pretty mundane tasks like payroll processing or just accounts payable, accounts receivable, just the BASIC bones of a business that had been neglected from the perspective of having a space in the cloud. This is before we had Workday and apps like that. To bridge that gap, I started working with a number of platforms, Coghead being one of them. Coghead was this beautiful declarative platform that had programmatic capabilities and you could build these bespoke applications. I got back into not necessarily programming, but building stuff through Coghead. Then through Coghead, that’s where I got reintroduced to a bunch of people from my past, somebody from Siebel who wanted to build a marketing application. We explored Coghead as an option for that. We explored building a Java application on a Tomcat server.
Josh Birk:
Yes.
Mike Topalovich:
There was nothing out there-
Josh Birk:
Oh, my gosh.
Mike Topalovich:
… that could do what we wanted to do. This is truly, we had an idea and we had no way to implement it. So my friend who I worked with at Siebel then went to work for Salesforce, and it was one of those pulling me back into the space things. I got involved with the Force.com platform. I started doing implementations, migrations from early CRMs, and then I was there at the right time. They introduced workflow rules, approval processes, all the things we take for granted now, those were all new things at one point. Then in 2000, whatever it was, 7-ish, the Apex language comes out and then Visualforce comes out after that. For me, from an intellectual perspective, just the ability, I was just like a kid in a sandbox. Just the Force.com platform, coupled with Apex, which I think is the most beautiful programming language in the world, as much as I don’t get to use it anymore, it just really tied a lot of concepts together that I had struggled with to build these composed bespoke applications, and the Force.com platform brought it all together.
So there was an event, again, pre-COVID, like I can’t keep years straight, but late 2000s, there was an event at Moscone Center, Tour De Force, and it was like the coming out party for the Force.com platform. From that point on, I was hooked. So fast-forward, I’ve been doing this now 16, 17 years, and that early evolution of the platform was just, that was so fun to be a part of. Just rate of growth, just the rapid rise of Salesforce as a company was an absolute blast. Then later on, as I got less and less involved in the hands-on part of things, I got recruited by Don Robbins, who everyone knows. If you know anything about Salesforce, Don has probably tried to recruit you to teach. Don recruited me to teach, successfully recruited me after years of trying, and towards the end of my tenure with Salesforce, I was doing a lot of teaching.
I was doing a lot of content writing. I was doing a lot of certification work, writing certification questions, grading the advanced developer certification exam when it was still a week-long code project. So it’s been this long fun ride, and I think it’s been a fascinating ride because I’ve gotten to watch a lot of cycles come and go over the years. But now here we are at this brand new intersection of just everything we know from just the perspective of human history and human society, all this stuff doesn’t matter now because we have AI. I think you know something about AI. I think I may have seen a session you did at Forcelandia back in July. Where does AI take us now? CRM, great, Cloud, great, here’s AI, what comes next?
Josh Birk:
I have to say your feedback, you came up to me after the keynote, one of my favorite reviews of anything I’ve ever spoke, you’re like, “Wow, I was really excited about AI until you got to the dark stuff.” Which we all are. Which we all are.
Mike Topalovich:
It was a quick [inaudible]
Josh Birk:
We should be to a certain extent, right?
Mike Topalovich:
Well, yeah. We should be super excited. We should be like, “Hey, this is awesome,” but the hype cycle for… After ChatGPT, GPT-35 got people’s attention, and then GT-4 was like, “What just happened to us?” For me, it just opened up just whole new ways of thinking about things like created new pathways in my brain to finding and processing information. But yeah, the dark stuff, we have to think about that stuff, and we’ve always ignored it in the past. The move fast break stuff concept, it just doesn’t work anymore. Especially now that I’ve spent as much time as I have in the enterprise, which does not move as fast as a company like a Meta or Twitter/X/ whatever Elon decides to change the name to next week, the enterprise doesn’t move that fast. So when I was in my early 20s and I was a punk, not that I’m not still a punk, but when I was in my early 20s, I just wanted to move fast. I wanted to break stuff.
I didn’t understand why we had structure. I didn’t understand why authority mattered. Now that I’m getting closer to my 50s and I’ve seen these cycles, it’s like, yeah, no, we need to pump the brakes on this because there’s the dark stuff you talked about, right? If we make wrong choices now, it’s going to have long-term implications on our future as a species. But then there’s the other side of it, which is, it’s been fascinating watching the co-opting of this technology occur so quickly where all of a sudden, everybody pivoted from being a Web3 crypto expert to an AI expert overnight.
Josh Birk:
Yes.
Mike Topalovich:
“Don’t sleep on these 3000 ChatGPT prompts.” It’s like just slow down, and that’s not a safety concern like everybody’s using GPT at the super shallow level. Okay, fine, that’s not going to end society. But the other stuff where we already think at such a shallow level, we don’t think about things critically. We are very responsive to stimuli. Where does AI fit into that? How do we make sure that we’re not just having what we had in 2016 with the misinformation cycle, learning that was state actors involved in that? Now, what do state actors with AI and quantum computing, what does that threat look like?
These threats are real, and we have to think about them. But on the other hand, I want to think about AI as I want to look back at 2023 and be like, “Hey, remember when we still had cancer? Hey, remember we had massive income inequality and wealth inequality?” And not making this a political discussion, but we’ll have a world, we’ll have a much better world than we have today. Just like our world today is much better than it was 10 years ago, 20 years ago, 30 years ago, the growth that we’re about to experience, nobody can fathom this. It’s a new period of enlightenment.
Josh Birk:
No, yeah.
Mike Topalovich:
That’s what I’m focused on. That’s what I’m excited about. But yeah, we got to cover the dark stuff. You got to mitigate the risk, or at least-
Josh Birk:
Right, you got to acknowledge it. You got to acknowledge it. We might not be here on the road, so it’s not going to doom and gloom us right now, but you have to acknowledge the risk while you’re driving the car down the road. But speaking of driving the car, and feel free to give concrete examples, but when it comes to the role of an architect, how do you think AI is overlapping with that?
Mike Topalovich:
AI becomes not another component in the design, in the consideration for what you design. It becomes almost like another pillar that you have to account for as this weird combination of both consumer of your system and as your best friend that’s going to help you along the way, making your life easier as you go through your personal workflows and your organizational workflows. It’s going to be there like as are, I don’t want to use the term second brain ’cause that has a specific meaning, but it’s going to be a shadow of ourselves. So the way I’m approaching AI right now from a design perspective is when you think back to the triad of our stakeholders or what goes into an organization, an enterprise, it’s the people. It’s the processes and the technology, right? PPT, people, process, technology. Well, there’s a fourth pillar now, and it’s AI.
I think the thing that I’m personally struggling with is AI is not a net contributor per se. We’re looking at AI right now strictly in generative terms. That’s collectively, we love generative AI, and that’s what we’re focusing on, but it goes so far beyond that. So it’s like, is this blind spot going to prevent us from taking advantage of emerging technologies that maybe aren’t as sexy, but have real-world implications? So it’s this constant just where are we going to apply this? How are we going to apply it, but thinking of it in terms of, what are the capabilities of this technology? Where I see this really coming into play, the biggest application of AI that I see as an architect designing a system, I just talked about UX a few seconds ago, a few minutes ago, from a UX perspective, things change because the human beings now, their role changes in everything.
So AI comes into the picture, and human beings have a dual role to play, so they are learning. They are learning their jobs, they are learning about their customers, the relationships with their customers. They’re learning all the time, building up that knowledge inside of their own heads. In the meantime, AI is also learning. It is learning from data that’s coming in. It’s learning from other interactions with other human beings through the machine learning process. Now this intersection is that the human is going to share its knowledge with the machine. The machine is going to then refine its own knowledge and provide better knowledge back to the human. You have to find a way to incorporate that feedback loop into every, let’s say handoff point, every possible point of friction within a process or every point where a human has to apply some level of cognition, because at that point, that’s where the true value of the AI is going to come in because it becomes an extension of the human.
So there’s that aspect that you’re feeding the AI with knowledge, it’s feeding that back to you. Just in general, in enterprise architecture, we struggle with loops in general. We struggle with feedback loops. We struggle with communication loops. We struggle with loops in general. So that’s a problem we have to really tackle at the enterprise level is, how do we get the loops so that we can have positive feedback loops where there’s an interaction occurring between a human and another human, a machine and a machine or some combination of those with AI involved? Then yes, generative really the capabilities moving forward, there are going to be some jobs that are lost by that, or at least transitioned into new types of roles. But on the bigger picture side of AI now, this is where we can now start to enforce behaviors or enforce, not necessarily enforce, enforce isn’t the right word, but we can provide incentives to our users at the UX level to give them a better experience based on how their own minds work, based on how they want to interact with the system.
Now instead of having to design really rigid systems that maybe account for 40 to 60% of use cases or personas, the AI through either natural language processing or just being able to interpret human thought based on past interactions is going to be able to interpret what that human’s trying to do and then maybe dynamically generate UIs or generate analytics just by putting in the parameters. You have that chat-like conversation, and that from that perspective is going to then allow architects to focus more on layers of abstraction where we say, “Okay, use your system any way you want to use that AI any way you want to, but here is what we need for you to complete this interaction or this transaction. Here is the data we need, which is an input to another workflow or another process that then aligns to business processes, value streams, what have you.”
That becomes a different type of interaction. Again, from an architect perspective, we can now start to attack a lot of complexity at those more specific levels by abstracting to just making sure that the AI is aware of our constraints. You have to provide it with data in this format, make sure the human user gives you this data, do this type of validation. Now it just becomes, we don’t have to think about that. We don’t have to spend so much time designing and building UIs, user experience because now that’s going to handled that a certain level. So it’s just really interesting to think of things multidimensionally because you can start to see how AI is just going to take over, not take over, that’s such a doom and gloom way of looking at it, but it’s just going to become integrated with everything that we do. That excites me because again, I’m not getting younger, so this technology is what I’m going to be focusing on for the rest of my career and that gets me excited.
Josh Birk:
Yeah, no, it has nothing but a positive experience for me so far, and I still liken it when people are like, “Well, are you afraid that it’s going to start taking over developers’ roles?” I’m like, “Look, developers already cut and paste a lot of code. I can cut and paste code from Stack Overflow. I can cut and paste code from a ChatGPT prompt. There’s speed and efficiency differences here, but when it came to how did I learn things, the overall flows, not all that changed. Now, to flip that script a little bit, what kind of role do you think an architect has when it comes to designing things for humans in terms of things like a human’s work deck and a human’s stress level and the brain of the human and the mental health of the human?
Mike Topalovich:
So this is something that I’ve spent way, way, way too much time thinking about. I’ve had a lot of time, and I’m telling you-
Josh Birk:
It’s one of the benefits of nearly turning 50.
Mike Topalovich:
If you ever have the opportunity to take, let’s say six months off and just drop out of society and just think, do it. But yeah, no, not some of the things, but I started to see a very clear connection between how humans think and how they interact with systems. That’s not anything new, that’s not a novel concept, but it was with a previous employer. The way that these users interacted with the system was like nothing I had ever seen because they just didn’t have the time or the attention span to sit and look for something for more than half a second. It had to be instantaneous because that was just it. They had to go back to whatever the previous task was.
There was no concept of context switching when you had to be hyper-focused on something for a period of time during the day. So from that perspective, I viewed that as my responsibility as the architect to find a way for those users to interact with my system in a way that was meaningful to them, but also gave me what I wanted, which was their knowledge. So you had to design this, and this was a securities trading firm, so I looked at it from the perspective of a trade. When you trade something, you are trading something of value, and you are getting something of value in return. What am I giving up in value here as the architect? Well, I’m not giving anything up. Actually, what I’m going to do for you is remember that previous form that took about 10 seconds to fill out because there was eight fields on there that didn’t matter?
Josh Birk:
Uh-huh. Right.
Mike Topalovich:
Check out this shiny new one. Isn’t that awesome?
Josh Birk:
Right.
Mike Topalovich:
There’s only four fields you have to fill out. Doesn’t it look better? They’re like, “Wow, that’s actually really cool. I’m going to use that,” and then they use it. That one piece of information that you weren’t getting before that you really needed for your analytics or some downstream process, they’re inputting it now because you’ve just exchanged a positive experience for that piece of information.
Josh Birk:
Gotcha.
Mike Topalovich:
I took that to a higher level. I started thinking about the touchy-feely side of UX. Again, I’m sorry for anybody who is offended by this, but corporate employers right now, I think they’re paying lip service to the touchy-feely stuff, the human mental health, the human aspect of just work in general and that relationship. I think that relationship can be made much, much better by just understanding what it is that we want out of work, what fulfills us? I have the opportunity of spending a lot of time with people much younger than myself just based on where I live in Chicago. I live in a younger neighborhood, and I have a lot of interactions with people who are 15, 20 years younger than me all the time. Getting that perspective of just what people want out of the relationship with work versus the contract we had when we were that age where it strictly was, even though it was knowledge work, it was still like you put in your 40 hours a week and you were paid for each unit you put into it.
Now, employees want to have an impact on what they do. They want their work to mean something. I think that gets ignored or worse yet, it gets paid lip service, and that’s really, really important. Then from an emotional perspective, it’s not the employer’s responsibility to make sure that everybody feels good when they come to work. That’s every individual’s responsibility is their own mental health. But on the other side of that, we just have to understand that we’re human, and we should be well aware of that by now after and during the pandemic. But what can you do to make the in-person experience the human experience better?
People are concerned about their commutes right now. They don’t want to give up that time with their family that they’ve developed from working from home. So what is that transaction? What is that trade-off where you can help people feel good about that experience? You can help people feel good about the work they do because it’s meaningful, it’s impactful. They can see that. They have clear direction in what they do. That’s the simple stuff, that’s just what people want on the surface. That’s not even getting into psychological safety, which you say that in open company, you’ll get eye rolled, right?
Josh Birk:
Right.
Mike Topalovich:
Logical safety is a real thing. It’s an important thing, but it’s touchy-feely. Corporate America doesn’t want to really pay a lot of attention to that. If they can hire a consultant and put together a program that makes it look like they’ve checked all the boxes, then sure, they can say they’re doing that. But really, getting in tune with how human beings think, that was one of the biggest objectives I had for myself when I went on this intellectual wander was how do you tie that soft, touchy-feely stuff back to making a good positive experience for your users? That drives everything I think about from a design perspective. Now you have a contract with your users and with the owner of the system. That contract is just make this an optimal transaction. Every time I interact with the system, just make sure it doesn’t suck, right? At a minimum, make sure-
Josh Birk:
Right.
Mike Topalovich:
… it’s net positive experience.
Josh Birk:
Yeah. I remember working for a large client back in my model days, and we were doing some kind of… we weren’t even two user acceptance testing at this point, but it was a very simple interface. But one of the project managers from the other side was like, “Hey, can I sit you down and show you what they’re doing now, and then I’m going to show you what you built.” I’m like, “Okay,” and he did. Mine was three more clicks or something like that. When I say mine, I was just doing what I was told. But anyway, he was like, “Can we get this version closer to this version?” I’m like, “I think so, but is two more clicks really that big of a deal?” He’s like, “You have to realize people use this all day long.” So going back to your example, 10 fields versus four and 10 seconds versus four, however that translation is, until you put yourself into the seat of that worker and realize how much more efficient you just made their entire day, it’s hard to realize the impact you can have if you just don’t care.
Mike Topalovich:
Exactly. Well, and then to take that a step further, this is a newer concept. There’s a book that probably everybody knows about by now, but it took me a long time to read it, and it was called Thinking Fast and Slow, Daniel Kahneman, super important book. But it took me since the time it was recommended until the time I actually finished it, it took me over 10 years to finish because it was so dense. He goes into a lot of just how the human brain works from the perspective of trying to dissect that and apply it to how we make decisions. That thinking in itself was fascinating, but it led to other authors like Adam Grant. He has a lot of great books. Think Again was his latest.
He had Give and Take was a very influential book, but what these authors were doing, they were painting this picture of trying to figure out maybe not necessarily what drives us, what motivates us, but just how we think, how we act, how we respond to stimuli. Using your example, those four extra clicks or whatever it was, from an efficiency perspective, yes, they can get more work done in less time, but just think of how your brain works. Think of how four extra clicks in a repetitive process, either you’re going to apply robotic process automation to that, or the human being’s just sitting there clicking and clicking and clicking. That’s not a great experience. That’s not a great emotional experience for that user.
Josh Birk:
That’s our show. Now, before we go, I did ask after Mike’s favorite non-technical hobby and well, he says he’s going to do a little dance for us.
Mike Topalovich:
My favorite non-technical hobby, wow, your editor’s going to have to deal with about 30 seconds of tap dancing here. Actually, this sounds super strange, but I’ve actually gotten into collecting art lately and not any particular type of art. I just bought a new house, and this is the first opportunity I’ve had to actually decorate my own house in quite a while. I’ve just really enjoyed bringing back art from Puerto Rico. I live in the Puerto Rican neighborhood of Chicago, so my front room is all Puerto Rican art that I brought back from San Juan, local artists here. I like going to art fairs now. I never did that before. I like going to craft fairs. I don’t know, maybe this is what happens in your late 40s.
Josh Birk:
I want to thank Mike for the great conversation and information, and as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everybody, and we’ll talk to you next week.