Skip to main content
Gun.io Home

Interview with Mike Kritzman, CEO at SkillNet

Mike Kritzman, CEO at SkillNet, joins the podcast to discuss how Skillnet is helping companies to do better with their HR by upskilling and reskilling to retain talent.

David Ledgerwood
David Ledgerwood
· 22 min

Transcript

Mike: I’m dialed in from Chicago where it has been snowing and very wintry in the past couple of weeks.

Ledge: You’re keeping warm inside I hope.

Mike: Doing good.

Ledge: I’m next to the fire in Nashville and we hope it would be a little bit warmer.

Would you mind giving a couple of minute background, just introducing yourself so the audience can get to know you and your work a little bit?

Mike: Yeah, of course, Ledge.

I’m Mike Kritzman. I’m a CEO of a startup that I founded six years ago called SkillNet. I like to introduce myself as the father of three people and two companies. This is my second company that I founded. The first one was acquired by Charles Schwab.

We are currently busy in sales with our skills measurement and personal development platform.

Ledge: Off-mike, you and I were talking about I saw, when I originally read your bio, that your expertise and that of your team is really around how companies can do better about using and developing and retaining and engaging their human resources.

I know from startups and from enterprises that I’ve been involved with, you don’t have to look very far on the income statement to see that number one investment item is always people. Yet, organizations seems to fail to retain them and engage them.

I wondered, what’s your experience been – now as you’ve stepped out from larger enterprises and start to think with different organization about that? What’s being missed?

Mike: I think I’m going to try to keep is simple and provide a level of detail that we can go deeper on.

I worked at Oracle and Ernst &Young and a handful of other startups. High growth. Two went public, one was acquired. Then I got the idea to start my own companies.

The inspiration for me was the variance of people who managed me and my observation of how other managers treated other people. There’s a lot of variation. I think all managers mean to do well and everybody means to be good at their job, it’s just you get lost in the day-to-day transactional stuff that you’re doing. Report in on how the sprint is going instead of what part of your job is a struggle for you – how can we help you overcome that.

So, we’ve constructed this platform I guess with that mind, to have clear definition of what’s expected in your role and then put that in front of the manager and the person being managed so they can talk about it as part of their one-on-ones.

The crazy thing about many big companies is, they do an annual performance review and that is one of the only times they really talk about what’s expected in your job. “You didn’t do well at this.” Sometimes people didn’t even realize that was part of their scope.

So what we’re trying to do is bring those expectations down into frequent conversations that are about, how do you get better? Not, we’re not going to pay you as much as other people because you didn’t do well. What coach would tell his players at the end of the season they weren’t playing right? They’d be yelling at them during game time. We’re not suggesting anybody yell at anybody at work, but just have more frequent discussions about how they’re doing, with enough detail that someone can take action on it.

Ledge: That ability to take action is such a critical component there. I’ve done these exercises for myself, and I often find that it’s hard. It’s a lot of work to really write down what am I responsible for, in a way that captures all the nuances and the things I’m actually doing and the roles that I take on. They call it like my second shift work. What else am I doing, and how am I bringing value to the organization?

How do you capture that? That it’s more than just your day-to-day task level activities.

Mike: That’s an insightful comment, Ledge, and I’d say that that’s the hardest part of our project. Launching the technology, uploading users, connecting them to the expectations and doing assessments and setting goals – all the things that we’re able to do with our platform, the individual development path of what learning is important to them in order to master their role – all of those things are predicated on what you just mentioned as sort of the hard part. Is, what’s really expected?

That is frequently identified in a job description. So somebody thought about it at some point. But when we engage with the client and we say, “Where are the expectations?” The most advanced thinkers that we come across have done it in spreadsheets, which is hard to sustain, hard to get data for and keep it all current.

Frequently, it hasn’t been thought about in a couple of years. They’ll pull out job descriptions as our starting point, and then when they look at it and really read it carefully they’ll realize that it’s not really what’s expected anymore. Especially true in the IT organizations where new tools and technologies and techniques are coming out every month.

So I think the hard part of launching a system like ours, whether you use the system or you do it manually, is thinking about what do we really expect of our people today? Then having discussions of where they are in each of those attributes, so that you can identify where things are going less than optimal and come up with some guidance on how they can muscle up.

Ledge: I love that you noticed and think about the technology organizations because the expectations of what makes a good technologist have just exploded in such a different way.

I was a software engineer when it was cool to sit in the basement and the lights were off and we’re all sitting behind these glowing terminals. That’s just not the case anymore. There’s expectations to talk to customers and to have empathy for the other users, and interact with product, and think about UX. My guess is that, none of that was really anticipated – the speed of technological change for product development, and product and engineering and innovation becoming the center of all the discussions. Shipping code or shipping product faster.

The expectations have just ramped up incredibly on those technological people at the same time that the demand from the marketplaces has picked up and we just can’t find enough of them. It’s been difficult.

Are there different ways that you would think about the technological workforce versus the others, or is this a universal truth?

Mike: I think it’s magnified or accelerated in the IT space because of the abundance of new companies creating functionality that didn’t exist before.

I think if you talked to somebody who was an all-star programmer from three years ago and they haven’t kept current, a lot of the stuff they know how to do has become somewhat obsolete. How do you deal with whirlwind change in terms of tools and techniques?

That doesn’t even touch on the more stable category which you touched on, which is being a person. All the soft skills, communication and working as a group. All those things I think are relatively the same over time, but the IT workforce is particularly for being current on all the new stuff.

We’ve seen some fantastic e-learning providers emerge. Pluralsight may be leading the instructional area for that. But each company has different expectations. One insurance company might think a Java programmer does things in JavaScript and in Azure, and another one is up in Oracle just using Java. So, even though the two jobs are called the same thing, a Java programmer, there’s. It’s tricky.

I think that we can be super helpful to companies that are trying to move their pack, keep them current, and have discussions about how they can help them improve their skill. With the talent shortage so magnified in IT – I think there’s like a 20% more demand for IT people than there are people – you need to be developing your people and doing more than just expecting them to get stuff done if you want them to stay.

Retention in IT is a big problem. I think we can take a bite out of both of those problems; upskilling and retention. It’s something I’d like to talk more about with any of your listeners who would have interest.

Ledge: Absolutely. I wonder, if I’m an organization and I’m kind of thinking about these things but I don’t know what to do, symptomatically speaking how do I recognize myself as a customer that would benefit from a solution like this?

We all wake up and say, well, I need to increase retention, I need to reduce turnover, I need to make sure my people are happier. I’m thinking all of these things, and culture, and then that gets lost. The entire thinking gets lost behind perhaps poorly indicated business metrics that don’t account for it. But symptomatically speaking, how can a business or technology organization kind of wake up and say, oh, I’m definitely in need of that?

Mike: Everybody means well. People come to work. They want to have a good day. They want to nail everything that’s expected of them. Managers want to have a good vibe with their people and be helpful and coach them and have a positive influence.

Good intentions don’t always carry the day. Just my nickel’s worth advice on your show today would be, take the time to make a list. Inventory what’s expected of people in their different roles. Project managers have very different expectations than programmers. Cyber security has got its own set of skills and responsibilities. Then, everybody should be a human. Take an inventory of what’s expected for each person, and have a conversation about how they’re doing on that. That is, I think, where the road begins.

Managers will find out that there are certain areas that are struggles, and then come up with some kind of a training intervention to help people over their struggles and the team will perform better. I think, ultimately, that’s what everybody wants.

Ledge: I think it’s so hard too in technology and the pace of change, you could be a really experienced, good manager who could probably really do well in this, and the vocabulary moves so fast that you can’t even describe what you really want. It’s got to become, in some way, collaborated with the technologists themselves. You might know what you want but you might not even have the vocabulary or the words to describe what you want.

You want to ship software faster, which you probably want to think about as some kind of a DevOps or delivery engineer, but you don’t even know how to ask for that when you’re putting a job req out.

I have empathy for the managers who probably check 80% of the boxes and could really holistically manage a team really well, but don’t know how to even understand what they’re up against.

Do you see that happen at all? That the vocabulary has just moved so fast that it just makes this exercise difficult?

Mike: That’s what I was talking about. The velocity of change in information technology makes this problem much harder. It’s going to be tough, if not impossible, to really keep a team of 10 people have current data in your notebook – which is what most of leadership walks into a one-on-one meeting with, a notebook and tries to organize notes. Really what they’re doing is they’re making a journal of things that that individual might talk about. Most people in a one-on-one meeting are not going to talk about things they’re struggling with. They’re going to try to put a positive spin on, “I’m doing really good at this.”

That’s the art of management, is to help people overcome their gaps. That is something that you have to have kind of a cheat sheet to talk about and say, what is the whole list of things that you’re working on and where is it not going so well. When that list keeps changing like it is in IT, technology is a great kind of.

Ledge: You talked about building the tool that you guys use and the software experience for your own company. Curious how that was. Do you describe that as you’re a CEO with experience in some in technology, or do you like to build software and work with developers that you had to hire to do that?

I would love if you would describe that from the customer standpoint. What was important to you? We’re dealing with a lot of developers that have those initial conversations. What makes it work and not work? Talk about expectations from your standpoint as the buyer and manager.

Mike: I’m going to cover that in just one minute, Ledge. There’s something I wanted to share with your listeners that I think will be very interesting.

A very large financial services firm out of New York – somewhere around 10,000 people – recently began a process with us to see if our tool could help keep track and identify who were the people in the organization who have learned about machine learning and artificial intelligence, because they didn’t know and a few years ago when people got hired, it wasn’t such a big thing.

Their thesis is, a lot of people have attended training and done things there’s just no inventory of it. They’re actually calling it a project that is labeled a talent marketplace. They’re trying to figure out from their staff and their contractor pool, who are guru at different capabilities that have recently emerged.

Ledge: I love that. Like a skills inventory. Like, things have changed and we already honed what we need and we don’t know it.

Mike: Yeah. We might already own it. Yet, if they don’t know it, they’re going to put out job reqs, hire new people. They might sit them next to the guy who’s been working at night to learn all that stuff and then that guy’s like, “Geez. They don’t even know who I am here.”

Ledge: I love that direction. Yes, I asked the other question but this whole thing has been on my mind too. Is, how do you run a skills inventory at scale? It’s a huge problem in IT. Do you have any insights into that?

Mike: That is an infomercial for what we’re doing with our tech. That’s what we built it for. Was to do these talent inventories and then go a step further with what we could call an individual development plan.

Each person has got different things they’re aiming at. One of my favorite saying is, one size fits none. You’ve got to personalize. We personalize our music with playlists. We should personalize learning in a similar way – and we’re able to do that with our software.

I would say that my vision for using this kind of thing internally, we might be a bit of a case of the shoemaker’s kids have no shoes. We’re running and gunning and we’re a small company right now. I’m doing one-on-ones and stuff every day. It’s a constant sprint.

The more organized and structured larger organizations that we do business with really has this problem. You can’t just fix it because, like I mentioned about that New York firm, they just don’t have any way to find out who knows things currently without doing some kind of a survey or assessment. Then, if they did that and it landed in Excel or Survey Monkey they can’t connect the dots to three months or six months from now and they want to see where they are then.

We purpose built the system to do this kind of stuff.

Ledge: Yeah. You can imagine, how do you combat the survey fatigue? You can’t ask people what they learned last week every week or they’re just not going to answer anymore.

Mike: It would get pretty annoying. Right.

Ledge: But, some way or another it’s in the employee’s best right to say, “Well, I took this ML course on my own over the weekend and I’d like to be able to apply that.”

Mike: Yeah. There’s a new product and they’re trying to figure who to sit their project with and you want to the only way to do it.

Our approach is, just put it out so somebody can pick up their phone and update their machine learning ratings. Then the next time something comes along and somebody looks, they’re going to show up as a higher rating because they’ve been putting in the spade work to get there.

I think that recognition is like that old saying, the tree that falls in the forest that nobody saw. If you’re working on stuff but your manager, the organization you work for doesn’t know it, that’s pretty frustrating.

Ledge: Right. Absolutely. I love that. That’s great. Maybe we can make sure that in the show notes you get some links out to some of the stuff you guys are doing.

Come back to the question of, you built a complex system and you had to work with software engineers – not having one on the staff. How did you deal with that, and what was good and not good?

I think that we’re always trying to learn. How can that experience be great for innovative companies who are not innately software people?

Mike: We are very careful about doing surface level specs. Designing what we want things to look like so there’s a clear understanding, and then doing use cases so we can harden the idea and avoid rework.

I think the time you put in to doing the blueprints on what you want are going to pay back in scale on the efficiency of getting the work done.

We’re offshore, which makes it even a bigger requirement, but I think even if you had a local team, taking the time to really dial in what you’re aiming at is a technique that has proven to work.

Ledge: Absolutely. Definitely agree. Then iterating through and not making huge investments into things without looking at it and kicking the tires makes a huge difference. I think that’s good advice.

Last question. You talk about, you’re a fast scaling startup. You’ve been in fast scaling startups. This is the kind of thing that if you set the baseline for and you build a foundation around this type of practice, it will pay off a thousand to one down the road. And yet, it is one of those remarkably time-consuming and expensive things that founders really struggle with. You have to invest in this in lieu of marketing. A dollar can only be spent in one bucket.

I wonder how you balance that. Maybe being an expert in the space you can say, hey, I know this is going to pay off but this is an easy thing for small companies to get wrong early and not recover from. What’s your advice for them?

Mike: That’s a great topic to end on. I want to thank you for having me on your show.

The biggest challenge we face as a company is that nobody’s heard of us. CIOs and other leaders in IT are under siege from vendors. So if we try to outreach or send emails or phone calls it’s frequently not answered. Referrals are a big thing, and then just getting the name out.

I think it’s a lot easier to build software than to take it to market, and we’re grateful for you having us today so we can talk about what we do and hopefully stir up some new discussions.

Thank you.

Ledge: Absolutely. It’s great to have you, Mike. Thanks for spending the time.

Mike: Awesome, Ledge.