George Jagodzinski (00:00):

Today, we talk about the possible death of enterprise architects — no, not murder. We draw some parallels between building architects and software architects, both the good and the bad. We delve into the role of a full-stack architect, and surprise, surprise, the secret is really about the people, giving them a voice, serving as a connective tissue, and helping deliver business value through technology and experiences. Our guest today, bringing all of this wisdom, is Steve Ma, who began his career as a software engineer and went on to wear the hat of enterprise architect and chief architect at many impressive organizations, such as CVS, Walgreens, and now, Ulta Beauty. Please, welcome Steve.

(00:37):

Welcome to Evolving Industry, a no-BS podcast about business leaders who are successfully weaving technology into their company's DNA to forge a better path forward. If you're looking to actually move the ball forward rather than spinning around in a tornado of buzzwords, you're in the right place. I'm your host, George Jagodzinski.

(01:14):

Steve, thanks so much for joining me.

Stephen Ma (01:16):

Happy to be here.

George Jagodzinski (01:18):

Something that really drew me to you and what you talk about is you have this concept that you talk about full-stack architecture. I'd like to just first start with the audience and myself, what does full-stack architecture mean?

Stephen Ma (01:29):

It really is about a concept around architects bringing more value through both strategic and technical value together. At times it's confusing, right? It's a role that's been around for a while, yet I think engineers, it's very clear what they do, project managers or designers. But when it comes to architects, you've got technical, you've got platform, you've got solution, you've got domain, you've got enterprise architects, you've maybe got specific technology platform architects and cloud architects, and then, when you actually ask people, "Hey, what do architects do," or specifically, "What do enterprise architects do," it gets fuzzy. The answers are varied.

(02:08):

So the full-stack architect concept is my attempt to basically clarify and kind of focus the architects and the value they deliver. And I can get into a little bit on what that entails, but that's generally the concept.

George Jagodzinski (02:23):

Yeah, I'd love to hear it. And let's not forget about those sales solution architects, the people out there making all the promises that we all need to live up to.

Stephen Ma (02:30):

Yes. Yeah, exactly. Exactly.

George Jagodzinski (02:32):

Historically, enterprise architecture can sometimes be viewed as this top of an ivory tower. This is the perfection that we're all chasing towards. I was certainly guilty of that early in my career. I'd go into a new place and I'd want to burn it all down and build it all the quote, unquote, "perfect way." Over the years of your career, what led you down this path of being more invested in a full-stack architecture?

Stephen Ma (02:57):

I'm an engineer by training. I started as a Java developer and then got into web development. Really, it just felt natural to me, zeros and ones. When I got into architect, and I went through the journey of being a platform solution enterprise architect, there's zeros and ones, it still is a deep part of my identity. And what happens is as I kind of grew through my career, I found that as an engineer, it's very clear the value that you provide. It's quantifiable in the lines of code you write. It's quantifiable, maybe in code test coverage.

(03:35):

But when it comes to architects, the value delivered is not very quantifiable. A lot of times, it depends on the maturity of the organization, how they deploy the architects, what domain they cover. Architect is such a large umbrella.

(03:46):

So that confusion is a big problem within the industry because, especially now in the post-COVID bubble world, there's a lot of organizations are tightening up their budgets, they're being leaner. And then, quite honestly, there's layoffs too. And then, if you, in your role, the value is not clearly evident, that's a big problem.

(04:06):

So the concept of a full-stack architect is around how do you provide quantifiable value to your customers. The customers of the architects are the business, engineering, design, product, program managers and et cetera. But having architecture as a role covers that huge umbrella, and being very articulate and specific around the value you provide, that's really the concept.

(04:31):

And I think what happens now is enterprise architect, a lot of times in industry, tends to be the ivory tower. Like the ARB, you go there for a checkbox. You got a lot of engineers, in general, very frustrated with what they see this as a ceremony that doesn't really provide a lot of actual value. The full-stack architect really spans across a different type of architecture and then really be able to meet the customers of the architects where they're at, whether it's a technical deep dive discussion, whether it's the business, understand the business context and the business meetings, technical and non-technical stakeholders in IT.

George Jagodzinski (05:08):

Or even worse than ceremony is you've got someone that's closer to the front lines. They just want to build a great experience for the customer. And they have an idea of how they could build that, and they know that they can architect it and build it in a way that'll be quick and it'll respond well, but now they need to go get approval. And how much is that going to slow them down? And is it going to make them just get rid of all of their ideas and shoot down all their ideas? I know you've worked at some very complicated organizations. Do you have examples that help ground this idea of a full-stack architecture working well?

Stephen Ma (05:41):

I think one of the... And this really, I lean on this, my own personal experience transitioning from an engineer into an architect, because a lot of times from an engineering perspective, architects, especially enterprise architects, they may be perceived as very hand-wavy or high level in the clouds, or maybe they're very much around just ideal scenario, like you mentioned earlier, around like building everything from scratch. Most of the time, organizations are complex. A lot of legacy systems, they can't just start from scratch.

(06:12):

In a couple of instances in my career, I found that a lot of times, I gauge the value I bring to the organization by whether I'm able to move a particular initiative forward or maybe I can enact actual change within the organization. And most of the organization I work with, like CVS and Walgreens, tends to be fairly large retail public organizations. Large organizations like that have a lot of silos, different tech stacks, different businesses too. They got this big because a lot of times through acquisition as well and through acquiring, so now you have different types of culture as micro-cultures. You've got different types of tech stacks. You've got different types of approaches, business units that are different.

(06:57):

Part of the challenge is when a particular initiative gets engaged, especially when it's a cross-functional cross-domain initiative that touches various different pockets of the organization that requires different types of skill sets and different roles to come to the table. And the clear problem I see, I have this situation in the past, an example where the product owner basically says, "Look, I need somebody technical who understands the whole landscape of what we're trying to accomplish here. Who is it? I just need to get this done and to connect with that person. We need to design the architecture."

(07:35):

And then what happens is when they went to one person, maybe on the data side, they can explain what the data architecture is, or maybe they understand how the database or the ingestion pipeline works and et cetera.

(07:48):

But then they're like, "Well, how does this integrate to, say, our integration platform?" or something like that. Or maybe, "How do they integrate to the front end?" And they don't know. And then they have to bring in another architect or maybe another engineer. And what happens is then it becomes this exercise of this product owner don't have time, nor does he or she understand all the directory of who the people are.

(08:10):

On one hand, you can say, “Okay, well, enterprise architect in this sense can come in and kind of provide that level of effort and provide that kind of almost hand-holding.” And that's true. That's one of the values that enterprise architects do provide. But the problem in that case in the traditional enterprise architect is they're at such a high level, maybe they know categorically some of the domain and some of the key people, but once they get into these conversations around actually designing and getting a little bit into the weeds about it, they can't, in a sense, hang with the engineers as they deep dive and talk about the actual detailed design.

(08:48):

And I think the concept with full-stack architect in that particular case, because the architects I tend to hire, I kind of look for three things. I look for technical skills, and they have to be, at least some in their history, in their past, have to be deeply technical in one area or another, like hands-on coding. Somebody with the strategic and soft skills necessary to be able to collaborate with the C-suite or that have that business context conversation and business capabilities be able to bridge the gap and handhold and convince the business owners and understand their KPIs. And then the third, and I think the hardest to find, is really that passion, that ability to engage and self-motivation and drive.

George Jagodzinski (09:32):

That makes a lot of sense. And the concept of you need someone to be able to hang within those different domains is really interesting to me. It reminds me of... I always like to draw parallels between software architecture and just building architecture because, first of all, I just love architecture, and I went to school with a bunch of them, but they need to think about the experience that all the people, the humans are going to have as they flow through their structure. They're bound by the constraints of structural engineering and building code and all these things. They need to think about how both people outside and inside their structure are going to experience it as it sits within the organization.

And I feel like there's probably a difference in the world of building architecture. There's probably some architects that they could draw you a cool picture, but they're not going to be able to sit down with the site supervisor and the engineers to be able to figure out how are we actually going to make this happen.

(10:23):

And I think that that's what truly allows them to create an experience. Before, you were talking about who the enterprise architects' customers are, but ultimately I think it is the end customers of the organization, being able to enable the experience for the whole organization. Do you think then that a pure enterprise architects are... Is that going to die off and you need just people who can really hang within more levels?

Stephen Ma (10:48):

This is a great question, and quite honestly, it's somewhat of a controversial question in the space of enterprise architecture as well, in the industry. It's like, well, what's the current state of enterprise architecture? Because personally, I believe that over the past, I don't know, 15, 20 years, there's been a dramatic advancement in technology. The internet, mobile, cloud computing. We also got spikes, for example, like blockchain, but now we're in the age of AI. So that technology advancement is really progressing really quickly, and engineers have to adapt. The concept of full-stack architect, I took inspiration from a full-stack engineer. The engineers have to adapt to the changing technologies, the different types of programming languages. At one point, there's a new programming language being introduced every six months. And it's like, how do they adapt? How do they also know the front end and then also the back end and then the middle layer? That's really kind of when came up with the full-stack architect.

(11:52):

And a big part of this is also being agile, to your point. So that connection to the building architect, a building architect in general is going through that kind of waterfall model, where it's like, hey, I'm going to plan a blueprint of a building, and I'm going to build it. And that's it. We are more or less going to set out with a blueprint we set in the beginning, and we're going to build a building.

(12:12):

The way that agile has basically been introduced and really infiltrated the software development life cycle, it really demands that engineers and also architects, and all technologists be able to keep up and be able to change on the fly. It's directly related to the concept of a full-stack architect, where it's no longer that waterfall model where initially the enterprise architect put together this high-level architecture and then they hand it off maybe to the solution architect, and then maybe they hand it off and partner with engineering, and then they deploy.

(12:47):

Now we're talking about we're working in sprints. We have spikes and enablers. Things might change all the time. I mean, when you're a building architect, you can't just all of a sudden halfway through, you're like, "We're going to tear this down. Instead of a square building, we're going to build this oval building." You can't do that. You can't change on the fly like that.

(13:05):

So, the same with software. We have to constantly adapt. And the full-stack architect is really equipping that architect to have the necessary skill set to be able to help them adapt quickly as well to the changing environments of software development.

George Jagodzinski (13:24):

Evolving Industry is brought to you by Intevity. We bring order to chaos wherever people, process, and technology converge. Our culture drives our solutions, and we are solutions-obsessed. We see every challenge as an opportunity, every partner as a collaborator, and every project as a chance to share our values and commitment to excellence. Give us a shout. We'd love to hear your challenges and turn them into opportunities. Find out more at intevity.com. Now, back to the show.

(13:53):

I want to pull the thread a little bit more on this example, which is, we're both in the Boston area. They put all these incentives to turn all the empty office spaces into residential condos and apartments now. But the challenge there is then you end up with all these windowless walls in the middle of it because it was very waterfall and it's not that nimble. And I feel like some of these large, complex organizations, you worked at some of them, I feel like they may be saddled with some of that non-nimble architecture that's put in place. Do you agree with that? And then how do you evolve from that point? It's like you got so much of that tech debt and architecture debt, how the heck do you get out of it?

Stephen Ma (14:34):

That's a big part of the challenge of all technologists, but especially architects at various levels. I certainly grew up playing video games, so of course, naturally, I'm like, "Hey, it'll be nice if I can create my own video games." And then that's how I got into engineering, to want to be a developer. And then that idea and dream of I'm just going to do something fun and be creative and create my own game or create my own app, that's awesome. Except, when you're actually in the industry, very little is about creating something new. Most of the time, it's about code reviews and maintaining the existing code. And to your point, modernization. A lot of these new latest technology trends are all awesome, but then how do they actually deliver business value? And that's where it really is most of the work.

(15:20):

So modernization, whether it's digital modernization, whether it's re-platforming an existing legacy system, whether it's migration to the cloud, all of these are about not only making the existing systems reduce tech debt, making the existing systems more nimble as well as basically re-platforming into something new.

(15:43):

But again, for a while, when cloud computing came on, everybody's trying to migrate to the cloud. But it can't just be cloud first as in like, hey, we're just going to move everything into the cloud, but we have to be smart about it. There has to be actual benefits as opposed to just leveraging the technology just to use the technology. So I think there's a lot of considerations around are we saving money. Initially, we're moving to the cloud so we can save money, but then it's more around the cost kind of leveled out a little bit. Then it's about what kind of advantages do we get from scalability, and reliability, and resiliency? Those are the things we have to not only talk about but measure and then have something quantifiable to demonstrate the value of a large, behemoth effort like migrating to the cloud of a legacy system.

George Jagodzinski (16:28):

Yeah. That makes a lot of... I laughed because I've definitely heard plenty of executives say, "Just move it to the cloud." Or before that, "Just make it all mobile." Where it's like, yeah, but why? What are we actually trying to do here?

Stephen Ma (16:40):

Exactly. And then I think you can see it right now, too, right? AI's the new hotness right now, so everybody's like, "Oh, we need to get AI in." To do what? There has to be a direct line to business value. You can't just put GenAI into something if it doesn't actually generate revenue in some fashion, depending on the industry you're in, or achieve some of the business goals you have. So it cannot just be kind of like a solution looking for a problem. There has to be a direct line to business value at the core of it.

George Jagodzinski (17:09):

And on paper, it seems easy. We want to connect business value to the architectural decisions we make to then the experiences we deliver to our customers or our users. But it's hard. And I know you've been at really large complex organizations, but it's hard at small and mid-market companies as well. There's culture and leadership challenges that come way before the technology. I'm curious, with all the years in your experience, why is it so hard? And have you figured out any secret sauce to make it easier?

Stephen Ma (17:37):

Specifically, from a culture standpoint?

George Jagodzinski (17:39):

Yeah, really getting that nimble architecture, connected with the business value, and just really incorporating it into keeping the frontline people connected to the higher level decisions that are being made.

Stephen Ma (17:52):

The concept of a full-stack architect is really around having that kind of jack of all trades, be able to deep dive, and having that passion and aspiration and motivation to be able to want to get technical, or maybe if you're already technical, being able to want to understand the business context. And part of that, the underlying theme around that is really after a certain level in your career, you get to a point where to solve problems largely depends on whether you have the right trust and relationship with the people around you, with the business folks, with the technical folks, your peers, with others. And what happens, I go back to medium to large-sized companies have these micro-cultures, whether it's through acquisition or even if it's not through acquisition, like security folks have a different culture than, say, the digital folks or maybe the infrastructure folks. And then you have basically digital front-facing, which generally in most organizations are more progressive versus, say, the business services side of the house that provides a lot of the value towards the organization as opposed to customer-facing.

(19:02):

And these cultures, they basically are a well-oiled machine within their particular domains, but they don't talk to each other very well. And then not only that, a lot of times they do the similar things but in a different way, but it's duplicative because, again, they don't talk to each other as often or they don't share enough information. So these silos exist.

(19:22):

So after a while, to a certain degree, it's like you get to the point where you end up really just dealing with human beings. So it's not about the code, it's not about zeros and ones, and a lot of times it's not even about being right. It's about can you actually influence the others. And the larger the company, the harder it is because you have more people to influence, you've got more people to move in the right direction.

(19:43):

I go back to deep down my identity is still very much an engineer, so a lot of times, even in my personal life, I think in zeros and ones. There's a right way and there's a wrong way, most of the time. But the truth is in a lot of these organizations, it's not about right or wrong. A lot of times, people have to like you. I think that's really the challenge because now you're solving a human problem as opposed to a code problem. And then that takes finesse. That answer to that problem can change depending on the people. The answer of that problem can change depending on the day. Even if the other parameters of this problem remains the same. And I think that's why it becomes difficult. Like, how do you get the whole organization to move in this one direction? And that's when you can enact the most amount of change.

George Jagodzinski (20:32):

Yeah. Move in one direction, but also from a technology and process perspective, feel that people have a voice and they have influence in those things as you're moving in that direction so that you are always adjusting. Have you found ways to give people more of a voice across the organization?

Stephen Ma (20:51):

Yeah. One of the things with... I'll give an example. I think depending on your level in the organization, there's a different air around the people you work with. If you're in the C-suite, you talk in very much big moves, strategic. When you're boots on the ground, you're an engineer, you're dealing with different types of problem, or maybe unnecessary processes that gets in your way to trying to get things done or deliver value. So different levels solve different problems. But the thing is, they all matter.

(21:24):

What I found is, especially with a lot of times with people on the ground, especially engineers and technical architects, they don't feel like their voice is heard. You work in a big company. A lot of times, it's like, well, maybe they just think they're a number. Do what they do actually matter? Some of that kind of challenges you see even in the cultural surveys.

George Jagodzinski (21:47):

They've got a big backlog of tickets that they need to complete and they're maybe being measured on how many points they can complete in any given sprint.

Stephen Ma (21:54):

Right. And then sometimes they're happy with the work, but it's like other times it's with existing processes. They're happy with the work, but then they're like, "For me to actually get access to this one system to do my job, I have to wait two weeks because I have to submit this ticket to have it be approved by somebody."

(22:10):

So, one of the things which I did in terms of empowering the culture is when I was at Walgreens, I created this meeting called the architecture assembly, but it wasn't just for architects. It was for all technologists. And what happened was, there's two things that's different about this than, say, just a lunch and learn. One is I want a meeting that everybody can attend from all different domains, all different levels, and just attend and talk about a particular topic. The topic can be really maybe a code demo, a technology demo, but it could also be something that's not technical, like ways of working. I also want it to be really positioning to be a community that everybody can contribute.

(22:51):

But the truth is when you have a meeting like this when you start it, it's not a community. People are not going to just naturally volunteer because they're like, not only this is extra work, it's an extra meeting, and if they don't see the value, they kind of fall off pretty quickly. But I made it a point to have this as a weekly meeting, even though initially people are like, when you have a meeting of almost a thousand people on the invite-

George Jagodzinski (23:13):

It's expensive.

Stephen Ma (23:14):

It's expensive, and you're having a weekly, like, people's not going to show up. But one of my counterpoints to that is if you don't have it in your face, constantly in your face, like you have it once a month, once every other week, people forget about it, and they’ll hop in, hop out. They don't feel like they're staked to it.

(23:32):

So I end up having this meeting once a week like I did. Initially, it started out to very much be a lunch and learn kind of format where people present, and I went after people to present, but then later on, I started to get people used to the idea and start to contribute. We had an example where they start to be able to feel comfortable like a safe space to be able to voice... That's another thing too. Sometimes these challenges that we talk about people having around culture, they're afraid to voice it because they felt like maybe they'll be viewed as somebody who's complaining or something like that. This turns out to be a safe space where people can talk about the real issues that's facing the organization. Just having the avenue to be able to communicate that is huge.

(24:11):

And then also, people are able to show great work, innovation, like a great place to run hackathons. I end up running panels, too, of various people and their peers talking about real problems. For example like, "Are we a tech company?" When I was at Walgreens, we thought about like, "We're a large retail organization, but do we consider ourselves a tech company? Let's have a conversation about that."

(24:34):

Another one, too, is you start to get natural value coming out of it. For example, one person developed this really neat application to help them notify them of certificate renewals, that certificate's coming up for renewals. So they created this app that not only notifies them but they can automate part of the process to renew. When they presented it in front of a audience of 200 plus people, people in another part of the organization is like, "We came across the same exact problem. Let's collaborate." They ended up turning that into an open source application that basically they can... or inner source, in this case, within the organization, that they can just reuse that same application to automate some of the certificate renewals.

(25:19):

That's the kind of innovation and value provided that I feel not only you can do as a tech community and improve the culture, the tech culture, but it is a role I think the enterprise architecture can play a big part of.

George Jagodzinski (25:33):

You just laid out so many successful nuances in how you do that. I've been part of these types of meetings, and I've tried to run some of them myself, and it can get real quiet real quick, and you hear crickets, and everyone's like, "Why?" Then the attendees just start to wander off and get smaller and smaller. But yeah, every week, I love that concept. I love mixing it up with different formats of panels and hackathons. It's those little nuances of making it happen.

(26:02):

Had Ben Utecht on the podcast, who is a Super Bowl champ under Coach Dungy, and what he used to say is, "If you're in the locker room, you have to say something. It's either a question or a statement. But if you're a part of this team, you have to." Now, that's a little bit more mandating, more so than creating an environment of... And there's probably environments where that works and environments where more of the making it more inclusive and collective, it makes a lot of sense. I love it.

Stephen Ma (26:29):

To your point, though, it's finesse. Depending on the audience. I do a lot of talking to folks of all levels, especially people who I see would come to the meeting. And again, coming back to me being engineer, I don't attend meetings to just attend meetings. So a big part of what's constantly in my mind is why would I want to attend this meeting. I really run it really, really structured. I basically send out an agenda and then the topic of that day, but then I make sure that that topic has a technical rating so people understand because the audience is so vast and so different in their skillset. There's technical and there's non-technical folks.

(27:07):

So it's very specific around, hey, this week we're going to have a code review or maybe a code demo or something. If you're really kind of like a code monkey, you want to get into the weeds of it, this is the right thing for you. But then the next week maybe we have a debate around something that's not as technical. About ways of working or about challenges we have today with the culture or whatever it is. That's a non-technical thing. Now, if you're a technical person that you're like, I don't really care about that, don't attend. It's completely up to you. And then you start to get more traction that way.

(27:40):

But it's not easy. You're absolutely right. Initially, it was like, how do I continue to keep the participation? I certainly don't want to mandate. But you want to build that community. That community takes trust, and it takes time to foster.

George Jagodzinski (27:54):

Yeah. You talked about the AI fad earlier. And I know this from firsthand knowledge, but I bet there's organizations everywhere. As AI started to get more and more popular, they created some sort of an AI round table or AI town hall where it's like every month, everyone comes together. And they probably talked about cool stuff for the first one or two meetings, and then it just fizzled off into silence and lack of participation.

Stephen Ma (28:19):

Yeah. These kind of meetings take a lot of care and handling. It can't just be like you throw it out there and you're like, "Hey, this is a community, so you guys volunteer." Nobody's going to volunteer. You really have to run it very structured and very deliberate.

George Jagodzinski (28:34):

Yeah. Yeah. Well, that transcends technology. You're the type of an architect that says, "Hey, I need to be able to hang and respect each one of these groups that is touching every part of this architecture." And the same thing goes for process. You can't just come up with a process. You need to embrace the front-line workers, the back-office workers, the people in the warehouse, just every single one of them. It's the same exact kind of mindset I think that you need to do that. When you think about your mindset as a full-stack architect, are there certain words that come to mind or philosophies when it comes to your mindset?

Stephen Ma (29:08):

Yeah. I think half the challenge is being in tune to the tech organization to understand the technology. Part of that is being very detail-oriented and technical. You got to love tech. You have to. And I don't just... Everybody can say they love tech but really love it to be able to want to figure out how things work. Coming back to my thing about drive, self-motivation, and drive.

(29:34):

The other aspect is around you have to be authentic because a big part of this is architects influence engineering, influence technology, influence the business. They partner with product. You have to have that authenticity to build that trust and relationship. And again, I think everybody would nod and say, "Oh, yeah, we had to build trust, build relationship. That's important." Everybody would nod on that.

(30:01):

But how to do that? Trust, the first and foremost, trust is earned. It's not given. So how do you actually build trust? What is that code of deciphering how to build that trust with somebody? I find being authentic, being forward, being direct, but really care, authentic, being care. If I'm that person, how would I want to be treated?

(30:25):

This reminds me of like, I'm originally from Taiwan. When I came here when I was eight years old, there's niceties in the American culture that didn't exist in the Asian culture. For example, we say, "Good morning." We don't really say, "How are you?" So when we come to the culture, and people are like, "Hey, so how are you doing? How's your weekend?" the instant thought, I remember my parents saying this too, is like, do they actually care how I am or are they just saying that? And if they're saying that, it's pretentious, and it's fake. But if they actually care, let me tell you about my day, and you actually care, or are you just saying that? In a sense, in American culture, that's considered kind of like a nicety to say. I don't think anybody who say that really wants to take the next half an hour to hear about your weekend in the details to that degree. I'm sure some people do.

(31:14):

But that's the same thing with... Back to the authenticity in the workplace. It's about being authentic, caring about the other person, really care about what they are interested in, what they actually... Even at work, what drives them? What do they care about in their part of the business? Oh, I have to accomplish this number of user stories by this date of my deliverables and milestones and the business KPIs. Being in this space where you're dealing with all these different types of customers for architects, you have to truly be authentic and understand their context.

George Jagodzinski (31:43):

Man, I could go on a 30-minute tangent with you on common language and what it does to cultures because I'm fascinated with that. But what I love in there is... These things always sound simple, right? It's like, if you love what you do and you're authentic in the way you treat people, it's going to be infectious. Trust is going to be just a automatic byproduct of that almost if you truly live up to it. Maybe this is a reminder just to people, you need to... It's easy to forget why you love what you do. I know I do that sometimes. Because you're faced with a lot of challenges and you get busy. You got to remember why you love it. And being authentic, sometimes you're too busy and so you just build up a shell.

Stephen Ma (32:22):

Yeah. No, I love you said that. That part's really important. The goal isn't to gain trust. Trust comes naturally if you're authentic. To your point, it's a byproduct. That's exactly... It's a byproduct. If your intent is, "I'm going to build this relationship with somebody just so I can get their trust, just so I can get my agenda done," then you're no longer being authentic. You're doing something for a particular agenda, like a means to an end. I found that, in the end of the day, if you're being authentic with yourself, with those around you, and you also love tech, I think that's a great recipe to actually building up trust and delivering value, that meaningful value that people actually care about.

George Jagodzinski (33:01):

Yeah. Because if you think you're doing a good job of covering up the lack of authenticity, you're not. Everyone can smell it from a mile away.

Stephen Ma (33:08):

Yeah, exactly.

George Jagodzinski (33:09):

So, Steve, I could talk with you forever. I've really enjoyed this time with you. I always like to finish these conversations with a fun one, which is, in all your years, what's the best advice you've received, either personal, work, anywhere?

Stephen Ma (33:22):

Recently, I think something that resonates is, I think it's a Steve Job quote around, "We don't hire smart people to tell them what to do. We hire smart people so they can tell us what to do." I think that really resonates greatly with me because when you have large organizations like this, you have a lot of people. To get everybody to move in the same direction really requires that leadership, and architects are leaders almost by default. It's something I personally learned myself, and I personally did some kind of adjustments in my career as well to make sure that, look, at times, I just have to have that trust in the people I work with and the people I lead so they can do their best work. We just have to have people do great work, and that's aligned together. I cannot be there to micromanage and look over the shoulders of other people.

(34:17):

So I think that's, in general, a good guideline to go by. And ever since I heard that, I start to observe other organizations and my peers and other people too, and then it really rings true a lot. And the best leaders who lead the best teams are people who actually trust their team.

George Jagodzinski (34:35):

Yeah. And if you can make that happen, it's more fun, man. It's more energizing, for sure.

Stephen Ma (34:40):

Yeah, for sure.

George Jagodzinski (34:42):

Steve, thanks so much for being here. I really appreciated it.

Stephen Ma (34:44):

This is my pleasure. It's awesome talking to you. Thank you.

George Jagodzinski (34:48):

Thanks for listening to Evolving Industry. For more, subscribe and follow us on your favorite podcast platform, and pretty please, drop us a review. We'd really appreciate it. If you're watching or listening on YouTube, hit that subscribe button and smash the bell button for notifications. If you know someone who's pushing the limits to evolve their business, reach out to the show at Evolving Industry at intevity.com, or reach out to me, George Jagodzinski, on LinkedIn. I love speaking with people getting the hard work done. The business environment's always changing, and you're either keeping up or going extinct. We'll catch you next time, and until then, keep evolving.