Why Dropping AI Into a Broken Process Makes Everything Worse ft. Mike Toguchi

Mike: 00:00

They don't want to drop AI into a broken process. They want help creating that process. If you just drop AI onto a bad process, that's not going to fix the process. That's only going to make it worse. The groups that are going to succeed and thrive are the ones that use this window of time to really aggressively pursue change. The ones that say, hey, we're doing a little bit, but things seem kind of similar.

So we're going to just kind of do a little bit. I don't think they will have long-term success.

Mark: 00:29

Welcome to the CTO Compass podcast. I'm your host, Mark Wormgoor, tech strategist and executive coach. In every episode, we meet tech leaders from startup CTOs to enterprise CIOs to explore what it means to lead in tech today. They share their stories and their lessons so that you can navigate your own journey in tech. Let's dive into today's episode.

Mark: 00:55

Mike Taguchi spent 23 years building the systems that basically help decide who gets scholarships, who gets grants. They've distributed through the platform, not they, over 100 million in grants already. He's the chief strategy officer at Tectonic. They just rebranded. Interesting story. I want to get into that one as well. And their platform, Orchestrate, just processes all those applications. Over 5.6 already processed and for organizations such as Stanford, which I'm sure you all know.

So what is really interesting about Mike, he's not actually from technology. He studied government and politics, very different background, but he's been working for a tech semi-tech company ever since.

So really curious. Mike, welcome.

Mike: 01:36

Thanks, Mark. Great to be on here. Really excited to chat.

Mark: 01:40

So, and that first question, right? You studied government and politics a while back, and then you joined... Basically a tech company resource at the time. What happened?

Mike: 01:51

That's a great question. Asked myself a lot. I was going to college in the Northern Virginia, D.C. Area, was very interested in public policy and government. One of this was, you know, obviously I hate to date myself, but this was a good 35 years ago or so. And that was at the time when technology was starting to grow and it intersected that interest of politics and communication to find ways for think tanks, policy groups, advocacy organizations, nonprofits that worked in that space to be able to reach their audiences, to communicate, to grow their grassroots. And so that was where things started to intersect for me, which was finding the company was named eResources. As you mentioned, we're now Tectonic as we've grown and expanded. But we Found a space in that D.C. Area working with groups that wanted our policy knowledge, but the technical expertise and were able to marry those two and help them grow and expand. And it's kind of all gone from there.

Mark: 02:54

So what is it that you learned in university then, right? And your studies that you're still using? Maybe almost every day, every week.

Mike: 03:03

Honestly, for as much as we work with a lot of higher ed clients, I would say, and I know higher ed is under assault in a lot of ways, the skills that I learned there are still immensely valuable in doing C-level strategy and transformation and working with our groups. It's critical thinking. It's the writing skills, the ability to debate and talk through issues, to really understand research and define an issue from multiple angles and understand different perspectives. And I think those are things that are invaluable, particularly in an AI age where everyone can write themselves a quick prompt and find the easy stuff. They can find the easy information, but refining that and turning it into something useful and really understanding all the implications and effects and how the pieces on the chessboard will move. You can't, that's, AI is not there yet. And so those things have been extremely important for me and my current side.

Mark: 04:00

And you said it right, we're in the age of AI. You joined... You already mentioned your age, or at least how long you've been here. You joined the company in 2003. It's been a That was before the iPhone.

Mike: 04:08

While. Yeah, it's been a while.

Mark: 04:12

That was before cloud computing. That was before SaaS was even a word. Thank you. What did the company do back then? How did you guys work and how did that change over 23 years?

Mike: 04:23

Yeah, it's we started where a lot of digital companies were at the time, which was just helping to create websites, digitizing things, you know, think tanks that had large archives of, you know, their research on paper and needed to turn them into PDFs and then ultimately into sites. Helping them, you know, grow email lists, host events, process donations, all the things that, you know, folks did 20, 25 years ago. And that sort of led us naturally the digitization process to where orchestrate is our application workflow platform where, you know, everybody did something on paper. You had to, you know, mail it in or sign out a PDF and the review process took forever. And so this was something that not just in higher ed at Stanford or UC Davis, but at large nonprofits, member organizations where we were able to come in and help create a workflow, understand how departments could integrate and collaborate better and create something that created efficiency, created productivity. And some of those principles still exist, you know, 10, 15, 20 years down the road where we're trying to find a space and create a project or a tool or a system design that helps these, helps the workers be more efficient to spend their time on and their mission to feel more effective so that they're not drowning. Before it was drowning in paperwork. Now it's drowning in spreadsheets, like information's in one Google doc.

You know, your CRM has other information. And a CIO or CTO, they don't have validated data. They don't have consistent data. They don't have a good dashboard that allows them to aggregate all of these things. And so, you know, we try and utilize our strategic element as well as, you know, different technological tools to help solve those problems.

Mark: 06:08

And it sounds like you're a lot more than... Just a SaaS company you're helping these organizations like completely change or maybe the ways of working, the processes, the data. Are you a SaaS company or a services company? Is it a bit of both? Do you do strategy? What is it?

Mike: 06:24

- Tectonic is a strategy and transformation company. So we try and do, we have divisions that handle the strategic and element for overall digital transformation. We have a web and development and branding arm through VIA Studios that is extremely successful, does great creative work. The orchestrate portion, which is orchestrates an application platform, but a workflow tool. And it's such a natural fit for AI because it's all about automation and efficiency.

So the SaaS part is an important component, one that I oversee. And we have a very large MSP that does help desk.

So we try and we're able to come into midsize to large organizations. We don't have to help them with everything, but we're capable of helping them with everything. And that really provides CTOs and CIOs with a lot of comfort and knowledge that our advice is not coming without missing background or feeling like they have to manage multiple vendors. And so we really try and take a holistic view and provide them the help they.

Mark: 07:25

Need. Cool. And you've been there for 23 years.

Yeah. The world has, we said this before the iPhone, before cloud, before SaaS.

I mean, most people change jobs every three, five, seven, I think 10 years is a long time.

Mark: 07:39

Why did you stay and what have you learned by actually staying at the same company for so long instead of Joe Paul?

Mike: 07:47

One of the things that's, one of the reasons I've stayed is, we have a great team, great culture. And I think, you know, I, there's a football coach from an old football coach had this saying, you win with people. And I like to say to some of our clients, like if you have a bad process, you can fix that. If you have a poor tool, you can replace it. But if you have bad people, your operations and your system are ultimately gonna fail. And so the team, the culture, the people, that has a big part of it. But as you said, people change jobs. Our job has essentially changed every five to seven years. That's been really the fun, it's been creative problem solving. It's going from, hey, everybody needs a website, to everybody needs to digitize certain processes, to everyone needs a CRM, to everyone needs AI. There has been a shift in our, we haven't been doing sort of the same widget making for 23 years, we've been shifting, changing, growing, and evolving as the market has changed.

Mark: 08:49

Nice. That's good to hear. And have you rebranded this year? You said that from e-resources for over 20? Almost 23 years.

Mike: 08:56

EResources was started in 1999 and we just grew significantly over the last five years. As I mentioned, our MSP area, we had some acquisitions as well as strategically brought in via studio for the creative marketing and branding component. And I think it just reflected a more holistic view of the service offering and just a more, you know, sort of modernized approach in line with digital transformation. Resources sounded a little bit like the old days of iMac or, you know, a library e-resources. And so while it's still near and dear to my heart, I think this is a better reflection of who we are today.

Mark: 09:39

Nice. And your role, right, you're, I think, C strategy officer overall, but president of Orchestrate.

Mike: 09:45

Yeah.

So as a, Chief Strategy Officer, I get to help across all of the divisions and departments and surface offerings, work with the CEO, the COO, and our CMO as a tightly wound leadership team. As I mentioned, we have a lot of different business offerings? You said, are you SaaS? Are you service? Are you a little bit of both?

So because we have such a broad and diverse offering, we actually have a very broad and diverse clientele. That's everyone from a two or three person startup to some of the large, you know, Fortune 50 companies and some of the largest associations and universities in the country. And so strategically positioning the company, helping us make sure we have the right technological offerings, have the right People, as I said, we're a distributed organization, so making sure that we can provide good service and support as we emphasize our partnership model with a lot of our organizations.

So there's a great deal there just from an internal standpoint for external positioning. And then as far as Orchestrate goes, that's, Something we've developed over the last 20 years at universities, as I mentioned, large member organizations, some of the nicest nonprofits and mission-driven groups. And so building that and sort of overseeing the technological evolution and incorporating AI into it as we sort of automate more workflows has been great. Really kind of a joy and that's the team that I'm most familiar with. It's the one that, you know, has been around the longest. And, you know, lastly, we have expanded the orchestrate offering into the disability services area because there was a great, from our understanding at universities, there's a great need for it. There just wasn't a lot of tools that were available to help, you provide accessibility and accommodations offerings, and certainly not ones that were modernized and more automated. And so getting to see that product development and watching that team grow in that space has been really meaningful and provides a lot of inspiration seeing them help provide disability services through technology.

Mark: 11:55

Before we jump back in, here is something that I've learned from over 30 years of working in technology. The hardest part of leadership, it's not the technology and it's not even the people or the teams. It's often that you're added alone by yourself. There's no one in the room that fully gets what you're dealing with. There's no one that you can trust to discuss your decision with. If that sounds familiar, find me on LinkedIn. Mark Wormgoor, and tell me what's in your mind. There's no pitch, just a discussion with somebody who's sat in a chair as well. Let's get back to it. And after the 23 years, how technical are you now?

Mike: 12:29

Well, it's interesting if you had asked me that question earlier. Six months ago, I probably would have said still not just enough to get me in trouble. But, you know, in the world of cloud and open AI, there's a lot more experimentation going on and I've been having fun building some things that I never would have been able to create before, which is, you know, both scary and exciting. But yeah, I try and create a Venn diagram of, you know, business strategy and technology and make sure that I've intersected them and provided the right balance, both internally for our own work and for our clients. They're not, hiring me to go in, write lines of code. They're hiring me to help them, you know, from a leadership level, create a good communication strategy, design the right system. They don't want to drop AI into a broken process. They want help creating that process. And so we have wizards and engineers that are able to do the highly technical piece.

So I try and create, you know, try and create a good balance.

Mark: 13:35

And I was going to ask, right, who do you rely on for the real, you have like a CTO reporting to you or working in your team or? Yeah, we have.

Mike: 13:43

A, Yeah, we have a CTO and a product lead or product director. And the two of them have... Built some of the most elegant solutions. They've designed systems that both can be rolled out quickly for small groups as well as scaled to large multi-program, multi-state operations. And so I rely heavily on them. I used to be able to really in the weeds with them, but as we've grown and gotten bigger now, they've taken on a lot more responsibility.

Mark: 14:14

I think in.

That's quite a big system, all these different clients. How do you keep it all up and running?

Mike: 14:31

Well, you know, having solid relationships with them, you know, continuous check ins, documentation, making sure things are, you know, constant testing, because these are platforms, they're living organisms, and the clients themselves, they have constantly evolving workflows. That's one of those things like people will often think of transformation is like, hey, I want to put a tool in place and I've built it. Now it just runs itself. And there's a little bit of that. But, you know, priorities change, mission can change, staffing can change. And so you have to be on your toes, you know, you're constantly looking at security, accessibility, and other critical pieces. You don't get to just sort of rest on your laurels. And so we make sure we've got, you know, sort of a tailored plan for each one of these groups. There are large federal fellowships. There are admissions programs at universities. There are, you know, scholarship applications that you know, run on an annual basis. And each one of them, though they have a lot of connective tissue in their workflow, there's plenty of unique elements. And so we make sure we have solid relationships with them, understanding documentation.

Mark: 15:40

Those pieces. And the one thing you said, or at least I think you said it twice already, the value of people, right? You talked about one of the reasons you stayed for 23 years is your own people. You said about the clients you work with that you can implement a system, but if the people, the culture aren't ready for it or you don't have the right people, it's not going to work. Give me some examples of where it works really well, but maybe where it didn't work out so well. And how do you deal with that?

Mike: 16:08

Yeah, there was a large fellowship program that we worked with. This is an example of something working really well. They had a small, tight-knit team. And the technology side of it, I will say, I thought it was fairly messy. It was a little bit of the old adage, like they were building the plane in the air because they were trying to create a new program and scale it as fast as possible. But what they had going for them was within that team, they were tightly knit. There was good transparency. There was good communication. They had accountability on like what the metrics were and like who was in charge of what. They were extremely adaptable when things when they tried something new. Or tried something on the fly. If it didn't work, they were able to quickly identify it. They didn't let it fester or just use it sort of an old legacy process. They were able to change and adapt it. And I think those were lessons that I took away that allowed them to successfully create something that ended up having, you know, hundreds of thousands to millions of dollars that went out annually in grants. And I like to point to that story just because when we work with groups, we talk to them a lot about If you could just pick the tool, that's not a good strategy. It doesn't help you design a system. But most importantly about your people, like you have to have buy-in. They have to understand what their place is in this process. And you have to have adoption. If you just because you launched something doesn't mean it's going to work. They have to actually want to utilize it and understand how.

And then you have to be able to take the feedback portion of it. If you don't have feedback cycles to say, like, hey, this isn't working or I don't understand how to make this process work with our review or we're seeing inequities or unfairness in the review process that have evolved because of the growth. You have to be able to adapt to those things and make changes. And so I think that, you know, that was one of the anecdotes I would have shared from a fellowship standpoint that we really saw success, even with a process that wasn't optimal.

Mark: 18:13

Those are the people. And the opposite, have you had programs or implementations where maybe it was the opposite? The technology side was maybe rather straightforward and easy, but the team just made it so difficult. And what did you.

Mike: 18:24

Do? Yeah, absolutely. It's, and I think that was, I've got one from a university. I don't, you know, won't, I won't single them out, but we had a university that the leadership sort of, they, ran forward with a project and It was probably their third or fourth big technology initiative in the last five years.

So the team was already burnt out and not really trusting. They wanted to integrate something across multiple departments, which is something we advocate for. It allows leaders to have, again, that good data, clean data. It allows you to create efficiencies. But each little silo had their own workflows and they were very protective of it. And so the implementation ended up being more about and they. Didn't have sort of the backbone to say no to edge cases or And so people were trying to protect legacy platforms and legacy processes or work them in, you know, sort of using, putting the lipstick on a pig, the, you know, put, use a new tool over a bad process. And leadership didn't, you know, sort of use the strength to fix that, to use the transformation as a chance to design a new system that was going to work for everyone. And so I think. The project eventually sort of evened itself out and there were some successes that came, but it was a much harder and longer process than it needed to.

Mark: 19:51

Be. We talked about edge cases. I love that because I think that comes up in almost every complex implementation, but for you as a software vendor.

I mean, almost every client must want their own customizations and if there's one thing that they need changed and if you accommodate everything I think by the client number 100 you're going to have almost every feature bills and probably half of them only for one client how do you manage those edge cases on orchestrate.

Mike: 20:18

That's a great question. We... We try and balance, again, understanding people want to be able to configure things. They want to be able to tailor it. And we want to be able to offer that. I think it's the idea of SaaS is like, you know, off the shelf. You get what you get. If you have a feature request, you send it in an email and pray that maybe it comes out in the next version.

Like that stinks. That doesn't help people really automate or create something that is efficient for themselves. But the reverse is true, which you mentioned, which is if you just spend all of your time, you can spend time, budget, scope, building something to try and accommodate an edge case that really doesn't, it doesn't provide value. It doesn't, line up with your success metrics. It doesn't give anyone any additional value. And honestly, often when you do that, it's for a particular person or group of people that have just been around, like they're trying to accommodate something that they want to retain. And they don't, you don't even know that they'll stay.

So like, you'll build something out. That's the whole like, the flaw of custom, you build something custom and the person leaves.

And then the next person that comes in is like, why were these decisions made? Like who authorized this? Why did you create this. And so we really try and draw any custom request back to, again, the top level mission, the values, the success metrics and say, like, what are we getting out of keeping this or not changing it or not folding it into the process?

So try and make things as uniform as possible and as flexible as possible and sort of align it with many of our programs are looking to scale. Like they want an implementation, they want a transformation, but they want more program you know, more application systems, more states involved. And so, you know, we say, well, what happens if you bring in another department, if you bring in a different scholarship? Would this apply to all of those or is it only for you? And so that's an important part of our role, almost to play the bad cop and to help the leadership, you know, sort of inflect the change that is necessary. And Yeah, standard standardization within the confines of like it.

Mark: 22:21

Almost force standardization across at least their processes.

Mike: 22:30

You want to promote growth. You want to promote, you know, innovation for and you want a team to be able to solve their own problems. We don't want to standardize something in a way that breaks a process and creates inefficiencies or inequities. But we don't want to customize just for the sake of, well, what happens if one student does this or one applicant does that?

You know, that's not good business value or strategy.

Mark: 22:55

And along the same lines, you have customers that are maybe very small, single departments, maybe three people all the way up to these Fortune 50 organizations or large universities. How do you build something that works for this really small team or that works for this really large organization and everything in between?

Mike: 23:14

Yeah, it's you have to have a good discovery and planning process, essentially creating a roadmap. The smaller groups, they aren't always easier just because they're less people. They are more prone to, you know, wanting to make decisions based on sort of personal preferences.

Sometimes it's harder because they are wearing multiple hats like it's the person does marketing and sales. And, you know, you're trying to help them when they're running around like crazy trying to handle too many different things.

So trying to create a baseline for them and a foundation and help them envision like how is this going to make you successful in year one, but how is it going to look down the road. It all comes kind of back to that planning and road mapping for them and tying it to mission, tying it to metrics. Once you start scaling, the problem becomes more too many cooks in the kitchen.

Like, well, hey, this is, Like I mentioned, you have three or four different departments that they all have their own metrics and they want the system design to fit what their process is, to fit what is going to make them most successful. And you have to be able to thread those things together so that the top level leadership, they get the value out of it, but, and everyone else isn't put in a position where the system doesn't, is ineffective.

Mark: 24:31

For them. And who's your main stakeholder then? Is it the, I don't know, the faculty or the marketing people they could mention or they, ...engineering teams and those... Clients.

Mike: 24:42

It changes like and that's part of the like sticking around and having a different experience. It's very much client to client basis. There are times where we have clients. Very little contact with a CTO or an engineer or a technical team. And there are other times where they're deeply invested because of you know, database integrations or, you know, other elements of their database sort of oversight. But I would say our main stakeholder is usually a combination of whoever the leadership financial stakeholder is, like a dean or a regent or board, and then the leadership level, like a program director, executive director, someone who oversees a scholarship, oversees a program. And they're responsible for, you know, the throughput. Is the application pool growing? Is the quality of the pool growing? Do you have enough reviewers? Is the review system efficient? Is it fair?

You know, that's one of the things we keep seeing is people are adding in, you know, AI tools to review processes, they're scaling their programs, but do you have systems in place to make sure that actually works? Is there too much bias in the system? Do you have Z-scores or other standardizations to make sure that there's you know, maybe, you know, the diversity of the pool isn't going down. And so, yeah, I would say our main stakeholder from an average client tends to be the program director, executive director, that is tied to, you know, a board level person when that's in the university setting, when you're talking about nonprofits or associations or corporate, it tends to be someone in like that CIO type role.

So, yeah. Because they essentially blend in between CISO and the security and the technology. The CIO tends to be the person that is most responsible for seeing that this internal infrastructure and operations are running.

Mark: 26:43

Efficiently. A quick one before we continue. If you're getting something out of this conversation, please hit the subscribe button below. That way, other tech leaders can find us as well. I would really appreciate it. Let's get back to it. The reason I ask is you've said somewhere that most important technology decisions actually get made outside of the engineering team or maybe not even involving the engineering team. What did you mean by.

Mike: 27:06

That? Well, yeah, that, that, Well, we kind of go in with this attitude that, And AI is only increasing this. But again, I know it's parked. The tool doesn't really matter. It's about the system design. It's about the people that you have. It's about the strategy and hitting metrics. The technology is just the tool that you're using, the force multiplier that makes it work. And all the important decisions are made automatically.

You know, sort of well before you get to that tool stage. It's about that planning and roadmapping. It's about having, you know, alignment for, You know, what is our security and accessibility standards? What is our operational, you know, what are our operational needs?

And then creating that workflow, whether it's for two to three people, whether for it's a team or multi department, or whether it's for a fortune 50 company, the executive level, the C level that is making those decisions, and how they decide to implement it, communicate it. Keep people accountable to it and, you know, and create who's going to be in charge of that design. The engineering team becomes like the tactical weapon to execute on it. But to me, that is far down the road. It is the upper level and that first part of the process that is really going to be the crucial one.

Mark: 28:24

Makes sense. Let's go back to the AI one. You're implementing AI or... Maybe some universities want AI in this tool set. And like I said, you could use it for assessing applications maybe, and there's so much risks there for buyers or other risks. Where have you started implementing AI? Were you really careful and What are your biggest concerns?

Mike: 28:48

My biggest concern right now is probably around policy and governance that the speed at which AI is sort of hurtling forward, it's unbelievable. I mean, even the changes in the last, this quarter, the first quarter, it's grown by leaps and bounds. And Everyone feels the urgency to innovate, to incorporate these tools, to find efficiencies. They were in that spot even beforehand.

You know, budgets are shrinking. Everybody wants you to do more with less. But it's very difficult to keep up from, you know, for a university, for example, or an association that has a board. These are the folks that are used to meeting, you know, quarterly or annually to set policies and things like that. And, That's not really realistic right now. You have to be able to make calls on like, hey, if you have, are people allowed to use Plod Codework and allow it to search through their entire drive or email history? What kind of data is in there? What kind of risks are included? And so that could be an entire conversation alone is just the strain that the pace of AI is putting on making sure you have secure data and strong policies, people that have guidance and training on it and know how to use it so that you don't put yourself at risk, create compliance and liability problems.

So that's really one of the, that's the thing that the biggest, that's the keep me up at night, you know, sort of stomach churning piece. When I think about the exciting part of it, it's where you start looking at it and saying like, hey, we've created systems, design platforms and helped groups streamline workflows and automate processes. And this is a tool that is going to turbocharge that. The ability, for example, to Instead of, you know, you have an integrated note taker that can then summarize everything. Using my example of the disability center that has thousands of people coming in asking for accommodations. Can you quickly use these tools to find, assign them to the right specialist, help them understand based on their description, what accommodations could be used, look through their, you know, faculty roster to determine like, you know, is there a good fit for this?

So a lot of the you know, manual work that was happening. Can be shortcutted if you do that. But again, you run into like there's a lot there's protected health information, there's student data, there are considerations where it's like you can do this. But, you know, is it something that fits within the policies that are allowed?

So. Yeah, we're very excited looking at it, you know, whether it's higher ed or associations or nonprofits, just the ability to take some of these manual things, you know, reading through documents and summarizing them, auto assignment policies, you know, things like that are going to save immense amounts of time once they get refined.

Mark: 31:50

And internally, why do you guys use AI and to what extent has it already been part of the product?

Mike: 31:56

Yeah, I mean, we have really robust internal initiatives right now. As I mentioned, we have a lot of different divisions or departments or offerings. And so each group is looking at things. We kind of have it structured in a way where there's three or four levels. First level would be the individual level.

Like what are each one of our staff members utilizing AI for in their own personal life to personal professional life to, you know, save time to work? Take care of tasks, you know, and then the second would be a team level. Does it is a design team that is working with Figma able to, you know, find, you know, new quick ways to create things is a engineering team that is, you know, trying to create code using this to accelerate their QC process or write code itself.

And then the corporate level where you say, hey, things like, you know, marketing or, you know, can you automate your marketing calendar and pulling of content? Can you Help with your, you know, sort of CRM and pipeline to go through, you know, I've seen some really exciting things with people, you know, searching through your contacts and finding ways to personalize very quickly outreach to them.

And then the last would be that product level where, you know, we have all of these offerings where we know AI can play a role. And so we've got kind of a four-tiered platform. System internally to try and promote use of AI. But we run into the same challenges like, is it aligned with our security policy? We have a lot of data from our customers that we have to be extremely protective of. And a lot of groups I see they're experimenting and they're piloting But does experimenting and piloting really lead to something that is a measurable outcome? How do you get longer term adoption? How do you ensure that people aren't just, you know, grabbing tools here and there? Which, again, the pace of it. Every week there's something new to test.

So...

Mark: 33:55

True. I love that as well. But yeah, it does take a lot of time, I think, from everyone.

So yeah, which sometimes generates business value, sometimes doesn't. And even you started using FUD. Code or co-work, I forget what you said at the beginning.

Mike: 34:09

Yeah, open AI, cloud co-work. We're building some agents and things like that. There's just...

So much, you know, that was the part where I said it's really, there's some scariness of it, but it's really kind of fun and exciting to see the application to be able to say, hey, can you help me create documentation? Can you know, review all of these things and, you know, automate some outreach? Can you help me, you know, build strategy guides? And I know that And that's just on, you know, on my non-technical end. I know the engineering team, the CTO, like they're able to do things by leaps and bounds faster. And so, but again, it requires oversight. There's still how long the human in the loop phase lasts. I think it will be quite some time, you know, so, but it is still definitely changing the business a great deal. And.

Mark: 35:00

You just spoke about your clients as well, that they're struggling with the policies, with the compliance. I think probably the same ones you talked about internally, they go from having monthly or sorry, annual or quarterly board meetings to having to approve, review. The ones that are like at the front or the ones that you've seen that are at the front, what do they do? How do they do.

Mike: 35:20

Different? I would say that the... Strength is from smaller groups or departments that have good leadership. And again, it kind of ties back to that idea that, you know, whether it's a board of regents or a board of directors, groups that have put a good leader in place that have stated like, hey, I want you to have room to experiment if something succeeds. Let's see if we can scale it. If something fails, report back to it. But again, they're doing it in a measured fashion where they say, experiment, but here's the guardrails that we have. And if there's something that we need to escalate to a chief security officer or to somebody else, let's not... You can dip your toe in the water, but let's not, you know, dive in with two feet and create risk for ourselves. And so I think the ones that have been successful so far are small to midsize groups that understand that they're trying to balance things. They're trying to go as fast as they can with urgency and purpose tied to their mission. But they are not just, you know, sort of experimenting in 90 different directions and assuming that, you know, just because you signed up with your account means that it's secure, that the data is safe.

Mark: 36:34

Absolutely true. Where do you think this is going to go in the next, I know Alaskan was the one that's questioned every guest, in the next two, three years? Five years is very far in this day and age, but what's the future for at least orchestrate or tectonic or the universities that you work with, the clients.

Mike: 36:53

Yeah, I mean, it's a, I wish I really knew the answer. I think we could, you know, both of us could be, we could profit a great deal if we knew the full direction. What I see right now is the things went from last year, it was you know, AI experimentation to this year is experimentation is not enough. People need strong workflows. They need to implement this into as many parts of their operations as possible to figure out where the value is. And it's not it's threading a needle. It's trying to redesign processes on the fly. And, you know, we talked about earlier, like if you just drop AI onto a bad process, like that's not going to fix the process. That's only going to either make it worse, expose the challenges you have. And so What I'm hopeful and what we're working with our groups is trying to get them to take that strategic view to say like this is what an opportunity this is to use this sort of revolutionary technology to affect real change as opposed to just kind of like limping along or hey, you know, maybe your P&L look good enough or your numbers on your scholarship applications were suitable, but they weren't what you wanted. This is your opportunity to really, you know, sort of do something big. I don't know. It's hard for me to think about AI even six months down the road, because if you had asked me six months ago, I wouldn't have been able to predict where we are right now. I do think that the one thing I mentioned earlier, I do think that human oversight is going to be critical for the foreseeable future. I think corporate always moves faster than nonprofits, which moves faster than universities. And so I think that there will be a slow burn for a year, two years, three years, where a lot of work still looks similar. But I would say two or three years down the road, you could see that's where you will start to really see the changes in the workforce and people's job responsibilities. I think the technology will be far more mature at that point. And so I think that's where I that would be, I guess, is my prediction is that a lot of. Sectors will look similar for 18 to 24 months, and then you will start to see big changes. And the groups that are going to succeed and thrive are the ones that use this window of time to really aggressively pursue change. The ones that say, hey, you know, we're doing a little bit, but things seem kind of similar.

So we're going to just kind of do a little bit, I don't think they will have long-term success.

Mark: 39:41

Makes sense. There's a lot of work to be done for a lot of different people, including us. That was all the questions I had. Thank you so much for coming on. If people want to find you, where can they go? Where is your... Best place to find you.

Mike: 39:55

You can find me on LinkedIn. There's not a lot of Mike Taguchi's floating around the world.

So that's an easy one. Or you can find our website is teamtectonic.com. That has information about our strategy and transformation and as well as orchestrate and our MSP and all of our other service offerings.

So I'd love to hear from you. You know, again, whether it's just something you heard that was interesting and you'd love to, you know, brainstorm or chat or whether or not you're interested in working with us.

So. So it's, Always great to connect with people, hear about their problems, learn about the challenges they're facing. Thank.

Mark: 40:28

You so much.

Mark: 40:29

As we wrap up another episode of the CTO Compass, thank you for taking the time to invest in you. The speed at which tech and AI develop is increasing. Demanding a new era of leaders in tech. Leaders that can juggle team and culture, code and infra, cyber and compliance. All whilst working closely with board members and stakeholders. We're here to help you learn from others, set your own goals and navigate your own journey. And until next time. Keep learning. Keep pushing and never stop growing.