Nishant Mathew

So my name is Nishant Mathew. I am a fractional CTO, Chief Product and Technology Officer. My company is iGokey. I've been in business for the last 13 years — back when nobody knew what a CTO was, especially not what a fractional CTO was. So it's been an interesting journey through the last decade of figuring out how to be a successful technology leader and executive for different companies and startups out there.

So yeah, my company iGokey — the fundamental question was, there's a lot of companies out there. I have this belief that all companies will end up becoming a technology company. How we implement technology requires a certain level of strategy, a certain level of clear direction, vision, and such.

I saw a lot of companies struggling with that because they couldn't hire a full-time CTO. They could not hire a full-time Chief Product and Technology Officer, but they needed that skill set on their executive teams. So one of the things I wanted to inject myself into was that conversation and figure out, well, how can we make this progress for companies and move the whole market as a whole, versus these startups and special Silicon Valley type investment groups that can only get there because they have the money to back them up. So that was the impetus for why I wanted to start this company — to equalize the opportunity for getting companies to be more tech-oriented.

That's a really good question. My target customer is probably the kind that's leaning towards how does technology play an important role in their business. We can look at it as sort of a three-legged stool. They have the service, they have the operation, and then they want to add that third leg to the stool, which is technology and supporting those efforts.

Over time, I also spent a lot of time with startups, actual tech startups. One of the things I also used to see was, even though there's a lot written about how to run a good engineering organization, even though there's a lot of information out there of the do's and don'ts of engineering organizations, a lot of companies still make a lot of mistakes when they're forming their engineering engine. So I worked with a lot of startups as well to come in and help them figure out not just what is the right engine for their business, but rather what is the business trying to accomplish in the first place. So be very strategic, very clear on that direction, and move forward in that way.

Oh, wow. How much time do we have? When I was fresh out of college, I was in charge of a consulting firm in San Antonio, Texas. And right away — I did not know very much out of college. I thought I could run a consulting firm and solve problems, but what I started to really realize was people were implementing technology without an understanding of what it's capable of and what the actual potential is.

Then I moved into the aviation industry. At the time I was just getting married, I wanted a little bit more stability. What I started to realize was, again, you've got this aviation company who can definitely benefit from tech. I was very fortunate to have a CEO of the company who also had that sort of futuristic vision of how tech could help, but he did not know how to get there. He did not know what was needed. He did not understand what's possible. So he and I came together, talked, worked, and started to understand that there's a lot of potential here. With me with my tech understanding, and him with the business understanding, we were able to be quite a force of nature.

That tech went so many different places that we could not even imagine. This tiny little aviation company in Texas, which everyone thought was doing one thing, is now also portraying tech in a very powerful way — to where companies like UPS and Boeing were asking the question, "Why are we not doing this? How come we're not doing this stuff?" So a light bulb went off in my head, and I was just like, "Well, how many different industries and companies are having the same challenge?" They just don't have that partnership. Usually companies are hiring an IT staff, maybe some software development folks, maybe doing website stuff. But at the time, there's no concerted effort to build powerful tech that really moves the needle forward.

As far as lessons go, I would say that the biggest lesson I've learned is that there's a mechanism a lot of folks rely on that says there's a playbook for every situation. I would sit here and say there's a unique playbook. There are principles, and then there's the playbook. But that playbook has to be very much in line with business. What I mean by that is, where is the business going? What are the specific outcomes that the business is trying to accomplish? You can't build an engineering org in a vacuum. It has to be embedded into the business. The biggest lesson I've learned as a result is that first I need to go to the business, understand what they're trying to accomplish, and really work on translating that to what kind of engineering engine I need to build in order to facilitate that growth.

What I've also learned is that people change things. The quality of the people that you bring in to the engine — like I said, it's not in a vacuum. It's something that you have to be very purposeful and intentful about in bringing those people. That's the biggest lesson I've learned. If you're not going to bring in the right people to help you get there, it's probably not going to work no matter how much experience you have and how good your playbook is. It really comes down to the people.

Well, that's a great question. The way I like to put it is, for quite some time, technologists and technology leaders have kind of been playing with the idea that the reason we're in tech is because there's a scarcity — meaning we don't have enough, but tech can fill in the gaps with that scarcity and make it work with duct tape and twine and whatever else they can find.

Now I think the tables have switched a little bit, in the fact that we are actually in a time of abundance. I believe we've been in abundance mode for quite some time, but considering today, the big thing is we have all this abundance, but we've been very oriented in a scarcity-mode-type approach. Now with all this abundance, what do we do?

It's exciting, it's scary. I see a lot of companies and a lot of engineering leaders constantly scratching their heads — their CEOs coming in with 50,000 things and saying, why are we not implementing this stuff? The key really is, are they going into that surviving mentality of, I need to wade across this hype? Really what most people are struggling with is this idea that actually we're in abundance mode. It's like, I've been wanting to do all these things all these years, but I couldn't because I did not have the resources, I could not have enough people to do this. Now we're in a situation where I could within a couple of hours get something going, and it's no longer a scarce resource for me anymore. I don't know what I do now.

A lot of even engineers are very used to that scarcity mindset when it comes to business. I just think that this is our evolution moment. This is our inflection point for an amazing step in our evolution here. So I'm really excited about this place that we're in right now. The people that are really thriving during this time are doing incredible. It's really an amazing thing to watch.

So where does this place the CTO in this world of abundance? Most CTOs usually walk into their C-suite teams and are constantly in this state of, well, how do I keep all of these requests, how do I keep the floodgates controlled? Most of the time the idea is that I need to run this as lean as possible, cannot spend a lot of money, keep my costs down. And now with this abundance mode, we're in a state where it seems like CTOs are trying to put the brakes on, but not going too far down a path. The challenge still remains the same — what does research and development look like? What does that roadmap look like? How do we make sure that we keep a healthy organization that understands it's not just about feature delivery but also about innovation delivery? It's all intertwined. Feature delivery is not separate from innovation. Maintenance is not separate from innovation. All these things are all together, and yeah, CTOs have a really tough job navigating that. It's very exciting times, but there's a lot happening.

The most profound thing is that in this age of abundance, it's the CTO's job to make sure that we don't get too fat. We don't overindulge. We don't underindulge as well. We don't keep ourselves away from the buffet table, as it were, but also at the same time not get completely unhealthy as a result of it and lose amazing ground that can be taken instead.

I think the biggest question is people, as it always has been, but I think now it's even more profound. Do I go build that 50-person engineering team now, or do I figure out how to do it with 10 engineers and an army of AI agents? There's this tension now that exists because a lot of the big startups are making those kinds of moves. Is that where we need to be? There's a big challenge for a CTO to try and figure that out.

The way I'm approaching it, as I've always approached things, is that it's really about what is the business trying to achieve? It's never the case about the number of engineers that you need to bring on to your organization. It's about what is the outcome that you want. I don't think the CTO's mandate has changed in that regard. It's always been that. It's just, can I achieve the same outcome with five engineers or can I achieve the same outcome with 50 engineers? It's kind of the tough challenge.

My advice for tech leaders would be: focus on what the business needs and then accurately translate that to an engine, not just an organization that has a hierarchy and this is my engineering manager structure and et cetera. Really look into what is that engine. Is it a V8? Is it a V12? What are we talking about here? Because a Toyota Corolla will get you just as quickly and efficiently as a Ferrari could. It's really trying to make that determination of what is necessary right now.

When I'm building a team, what I'm looking for is, what are the specific capabilities I need to make this engineering organization work? Too many times people approach it with, "Well, I need a back-end engineer," or, "I need a DevOps engineer," or, "I need an SRE." But they're not quite clear how those people fit into the overall capability structure of that organization. What I try to do is sit here and say, "Okay, in order to achieve this outcome, what are the specific capabilities that we need? What is the maturity level of each of those capabilities?"

For instance, you could say that we need a fantastic data onboarding solution. That's a capability we need to be a successful company. Okay, what is our maturity on a scale of one to five? If it's a one, what do I need to do in this year to get it to a two? If it's a three, what do I need to do to get it to a four? When we break it down from that standpoint, we start to really understand from a hiring standpoint what do I need to bring in, and who do I need to bring in. There's also the struggle today that many people are looking for an AI engineer, for instance. Well, what is an AI engineer? I'd rather ask, "What capabilities are we looking to fill, to give us that advantage as an organization?" Hiring, to me, what's really important is what is it that exactly you're trying to accomplish, and how are you trying to resource that correctly with the team that you're about to hire.

I think companies like Howdy — what's so amazing about them is they have this incredible suite of capabilities of people spread across Latin America that you can tap into without having to really overthink about how that's going to work out either. It's such a beautiful thing because I'm able to come to Howdy and say, "Hey, look, I'm looking for these capabilities. This is my success criteria for the next 12 months." Howdy listens to me and translates that into, "Okay, you need these types of resources." Super helpful, so easy, beautifully plug-and-play type situation. I've just been very impressed with how that works.

The most common red flag I see is, too many times I think we only look at what tech people come to the table with, rather than what is the cultural impact they're going to have on your org. A lot of times we tend to prioritize what I get out of this person versus how this person is going to affect my overall organization. A big red flag is when you might get a very powerful "10x unicorn engineer" that's fantastic on paper and if you don't hire this person right now, there's something wrong with you. That tends to go back to that scarcity mode — I need a power player so that I can kick out features and such.

I see a lot of mistakes being made where the wrong people, especially from a cultural standpoint, keep happening a lot. I too have made similar mistakes where I prioritized, "Well, I need to get the thing done," versus is this the right person to be part of this org? Because I'm not going to just need this person for the next three months, six months. I'm going to need this person for quite some time. They have an impact on my well-being, the well-being of my team, the well-being of my organization.

Also, let's not stick this just to engineering. They have to work with other departments. They have to work with product. They have to work with customer service. You really have to think through what is the kind of cultural impact that you're looking for by bringing this person on. That's a huge red flag — if you're naturally prioritizing what they come with from a tech standpoint and not really understanding the cultural impact they will have.

I don't know if this is a hiring answer, but I would say that when I start to see things are not going in the right direction, not making the decision to let that person go or whatever the case may be — ultimately, CTOs have to understand it's through this engine that things move. It's really important to keep that engine as healthy as possible.

Asking those kinds of questions during the hiring situation — really putting the candidate in a place where they are speaking from things they've gone through, as opposed to theoretically. These are smart individuals; they can usually figure out what a question is trying to get at. But if they have gone through the operational thing, they're going to answer it from a very different place. They're going to come at it with what's worked and what's not worked. You can get a lot more depth with that person when you're interviewing them. That's the thing that's going to help you decide whether this person is going to be right for the role, because too many times if you're fielding theoretical answers from the candidate, they're more than likely not going to be the right person for the job. It's a big red flag I see.

Why I love Howdy.com, and why I believe that CTOs love Howdy.com, is — I've worked with a lot of recruiting firms and staffing firms in my career. The biggest difference is that when I work with Howdy, I've noticed there's a higher quality of signal-to-noise.

When I first encountered Howdy through Jacqueline, I was looking for some resources for a client of mine. She listened a lot to what I was looking for and what exactly I was trying to get accomplished. She also started to realize — she didn't want to say that she was the solution to everything. I found her ability to really try to figure out the signal and not just be about the noise, "we'll try to find somebody for you," — I noticed that this is a very different recruiting agency. I found out that Howdy is not about just anything. They're very specific. They want to listen to what their customers want, but they also want to partner with the right customers. I think that's really contributed to the success of who Howdy is — a very clear ethos of how they want to operate.

I've seen that evolve over the years with all the things they're trying to do. The biggest thing I've really loved about Howdy was — I think this has been by design — the world of recruiting and staffing usually works with this veil of ignorance, of not knowing what's happening in the background. You don't have any ideas of how your team members are being taken care of, what their payroll situation is, what their living situation is. There's a lot of things that we are not aware of. It's all behind a very fixed pricing for that type of thing.

What I saw Howdy doing was very courageous and moving forward in a very transparent way. We all know exactly what those engineering folks are actually making and what is the cost that is going to Howdy. There's this beautiful transparency that was very valuable in my ability to then take care of my team members in Latin America, because now I understood their needs. Whenever I did performance reviews, I was able to interject myself in that whole cycle. The biggest thing that Howdy gave me — and I think this is why a lot of CTOs love them — is that these are my people. There wasn't this gap of, "Well, these are our contractors," or "this is a vendor that's providing." No, it felt like this was my team.

Beyond that, Howdy has gone to certain extra levels where they provide you with an operating infrastructure around those people. There was an engineering manager assigned to your team members who supports them from the other side. Not only can I support my team member, but Howdy was also supporting these people, looking after their needs, helping them with any kind of acquisition, whether it's hardware, skills, learning, language, whatever. The love is crazy with Howdy. It's the relationship you dream of having with a company like Howdy.

For me, I think culture is such an important thing because I've seen that no matter what you do and how best your intentions are, if the culture is not there to back it up, it'll end up the way it will naturally go. What's very special — this ethos that Howdy brings, with the type of quality of customers they bring on, is also found in the type of people they bring on from the resources standpoint. I want doers for sure, but I also want the engagement.

A lot of the recruiting scenarios I would go through in my career were a lot of yes-people, a lot of people who would do anything. If I told them to build a bridge or I told them to build a flamingo, they're going to do both. Probably I'll have flamingos embedded into the bridge. There were weird situations, and it was very difficult to create that culture of questions and questioning — what is the real thing that we're trying to achieve here?

I knew that I was on the right track when — I wouldn't say this was a senior-level engineer, I would say they were a junior-level engineer — they asked during one of the calls where we were discussing this giant feature set, basically right in the middle of the call, they said, "What are we trying to achieve here?" I was just like, "Wow, I am so happy right now." Because here is an engineer who's not just interested in writing code, but is so interested in a beautiful outcome for what we're trying to achieve that he wants to understand that. I knew I was on the right track. And this wasn't just the one person that I brought onto my team — this was multiple people doing this. This is very hard to get to, by the way. This is not something that can be forced. It's not something you can just make happen. There has to be a natural organic element to it, which makes it more powerful. The ethos of how Howdy works and the types of customers they bring in — you can definitely see that quality is maintained on the partners they bring on on the other side as well. That's one of the biggest reasons why I feel that Howdy gets it right, because they're very particular about the intent.

The biggest thing I've seen in comparison to hiring in Europe, Eastern Europe, India, all these different areas — and I've had teams all over the world in that regard — what I see that is incredibly unique to Latin America is the level of care. How shall I put this? They want to do well for themselves, but they also want the company to do well. There isn't a separation of what it is that I want from what it is that they want.

With a lot of situations, especially working with India, for instance, not only do you have the time-zone challenges and the chasing-the-sun-type situations, the biggest thing was really trying to facilitate a culture that cared about the business being successful. Eastern Europe also — this is a very, very huge challenge, getting the team to really care about the business being successful, because the business being successful means they're successful, et cetera.

It was not just another job to punch into, or, "I can make more money with this next outfit that's interviewing me." I feel like there was some staying power with the folks that Howdy brought on. I could see myself working with these people for many years to come. They could see working with me for many years to come. It really felt like this was my team and I'm not working through a third party to get to these people. Same for them — they had full access to me, I had full access to them. I think that's incredibly special, because the things we're trying to achieve is solve complex problems for customers. That can't be done just from a sense of building technology and hoping to God it works. It really comes from a place of, do I care about the impact that's going to happen for that customer? Translating that to an engineer is hard if you're having to do it manually. It's beautiful and it just happens organically from their end. That's what I've seen in the folks that I work with at Howdy.