Michael Krigsman was our special guest.
His Twitter: @mkrigsman
Transcript
[Yegor] Hello everybody. This is Shift-M podcast episode 29 and we have a special guest today, Michael Krigsman, and he will introduce himself right now. Michael, please.
[Michael] Oh thank you so much for having me here. I’m just thrilled. So I am an industry analyst and the host of CXO talk and we bring together the most innovative interesting business leaders in the world talking about disruption and how they’re managing their business and managing changes and expectations from buyers, from employees and related topics. So thank you for having me.
[Yegor] Oh, great. Absolutely. It’s an honor for us because I’ve seen your CXO talks, a few of them and I am really impressed by the quality. Our podcast is not as high quality as your own and your talks. But as I said mostly programmers and IT managers are listening to us and my questions today will be about management of teams and resolving problems with teams/people which actually write software, which create products so I will have a lot of questions about that. I will start with the first one about IT failures. I’ve seen you on a few Youtube videos saying that blaming project managers is not, you know, the best recipe for resolving IT failures. So my question is what do you think is the primary cause of IT failures and what’s the right solution for that in the majority of cases?
[Michael] Well I’m so glad you brought that issue up because when there is a problem on an IT project it’s very tempting to look at the project manager, because the project manager is the visible person, right, there’s the person managing, controlling the schedule or controlling, at least on the surface, the budget. And so it’s tempting to point the finger there and say “Oh it’s that person’s fault. And now we don’t have to worry about it any longer.” In reality projects fail not because the person managing the schedule usually got something wrong. They fail because there’s a lack of communication among different stakeholder groups. So for example you have this software development, you have a software vendor, say it’s an implementation, software implementation, you have the software company, you have the customer that’s buying the software, you have the system integrator—and each of these groups has a different set of objectives and goals. So the customer just wants the software implemented, the software company wants to sell their software, the system integrator tries to sell services. And so the incentives are different, but then it gets even more complicated. So inside the customer, for example, you may have different stakeholder groups from different departments, and each of these departments wants their particular problem solved. Only we’re implementing one system. We’re not implementing five different systems for five different departments, and so it becomes very complex. And so they afford to simply say that “Oh, it’s, you know, the project manager who screwed up.” It’s simplistic and it’s oftentimes and usually a mistake, it doesn’t solve the problem.
[Yegor] But like you said the problem is the communication, the mistakes in the communication, right?
[Michael] I think yes, I think it’s expectation. So for example if you’re building software, and inside a company, what are you actually building? Right? I mean look at Agile development why does Agile exist? One of the core reasons is to ensure that the developers and the end users are closely aligned. And if so, if you don’t have the right type of communication, if you think about traditional waterfall development, that was one of the big problems, is you have these big projects and at point zero, when the project is starting, the developers go out and gather requirements and if it’s a big project, the users may not see any results for a year, can be longer than a year, by which time the end user… Well first of many of the users may have moved on but their needs may have changed because the world changes and the business changes. And to me, I call these failures of communication and I call these mismatched expectations.
[Yegor] I totally agree but the question is who is supposed to be responsible for resolving that issues?
[Michael] Well isn’t that an interesting question? And I think that’s… you know there are so, you know, the statistics say that something up to 70 percent of IT projects are late or over budget. And it’s not that these people are stupid, it’s that it’s really complex, as we know. Building software is, as you know much better than I do, you’re a developer, building software is really hard. And getting business people on the same page to articulate what they need, and then, over time ensuring that those needs are stable, that it’s not a shifting goal. It’s really hard. So the answer to who’s responsible… I’m hesitating because again you know… let me tell you what I was thinking. I’ll tell you why I’m hesitating so what I was thinking is it’s actually the business people who are responsible because they’re ultimately, it’s their project. But then again, maybe it’s not their project, maybe it’s the IT department’s project. So who’s responsible? Let me ask you, who’s responsible?
[Yegor] Well I thought that we have project managers exactly to help us solve those problems, so we are programmers, we’re sitting, we know how to write code, and we have some customers who know what they need, so we need some middleman, we need somebody who will, you know, connect us somehow and make sure that we’re synchronized and resolve all the communication issues. And that’s why when we don’t have proper resolutions and we have problems, then we are ready to blame the project manager. That’s what I thought.
[Michael] Okay. Well it’s, you know, fair enough, it’s a reasonable perspective in theory, but I would argue that in practice what you’ve done is you have forced the… I’m a big fan of project managers, you can tell. So in practice what you’re doing is you’re forcing the project manager to have expertise both on the business side and on the development side. But not only that, not only do you want the project manager to have expertise in both of those areas, but you all are demanding the project manager to be able to interpret both sides, interpret intention and meaning on both sides and the person that bridges the gap. And that’s a really-really-really… I would have a very hard time playing that role. It’s a really hard role, so I’m not sure that you can say that. That’s why I say it’s really complex.
[Yegor] Yeah that’s true. And let me put it this way: what would you suggest to blame project manager for?
[Michael] That’s an interesting question. I love your questions. I would blame project managers for getting from managing the schedule and the budgets incorrectly. So it is the job, the responsibility of the project manager to gather the information that is needed in order to put together a schedule, and then be communicating at all times with the people contributing to that schedule to ensure that there are no issues, that there won’t be any issues causing delays for example. Right? So, clearly managing time and managing money is clearly the job of the project manager. On the other hand you can’t really say that the project manager is responsible if the developer somehow screwed up or if the business people are late. But on the other hand, I keep going back to the other hand and the other hand because there are so many pieces to this. So on the other hand, the best project managers that I know become invisible. And what I mean by that is they are just managing things and handling things so well that everything, the project just sort of goes and does what it’s supposed to do without any hassle or stress to the other people involved. And so that’s the ideal kind of project manager. But again in summary the project manager is responsible for time and money and making sure that those two things come out in the right way.
[Yegor] I like the concept of being invisible but on the other hand I hear a lot of people saying that project management is dead and leadership is alive. So we don’t need managers anymore, we need leaders, and leaders by definition, according to my understanding, they are visible. So they are always upfront, they’re always ahead of everybody else, they are leading people. So how would you put these two things together? So do we need leaders who are visible or we need project managers who are invisible?
[Michael] I… again, it’s an excellent question. I think that the project manager… you need both of those things, from strictly a project management standpoint, I don’t know if I have a project manager working for me and they’re doing project management. I don’t know. By the way, I have construction outside, can you hear that right now?
[Yegor] A little bit, but that doesn’t bother me a lot. I can hear you.
[Michael] Okay. So if I have a project manager working for me I really just want that project management to be transparent to me. I don’t want to deal with it. That’s that person’s job. And if they’re doing their job well the project is just happening in a great way. At the same time the issue of leadership I do ideally want that project manager to play the role I was describing earlier which is to talk with the the end users, to talk with the developers and to build up a kind of a 3D model. I don’t mean literally, but a mental 3D model of what’s needed, of what the users need on the one side and what the developers reasonably are capable of accomplishing within reasonable time and budgets on the other side to communicate, and to do that absolutely requires leadership. And so I think that there’s no conflict between the project manager being invisible for certain things and taking a very strong leadership role at other times, I think that both of those should work together. I absolutely agree with you.
[Yegor] And do you think it’s the job of a project manager or a leader to find the team, to build the team, to put the team together or that somebody else has to do that, like in many companies there are HR departments for that and sometimes and quite often project managers or leaders or team leaders, they just happen to have a team, they just happen to be here, and they have a team, and they have to manage the team. So do you think this process has to be driven by the leaders, by the project manager, or the manager has to be able to manage whatever it is in the office, whoever is in the office.
[Michael] So on this one I think that the issue of leadership is you do want the project manager in this case to be a very strong leader, because I tell you what, I don’t think works well and which as you’re describing have been in many companies, that somebody puts together some boss someplace and puts together a budget and says “Okay, we need this project done. Here’s the budget”, HR hires the team and then they call in the project manager and they say “Here’s your problem, here’s your project. Here is your team. Here’s your budget and here’s your schedule now. Good luck at that time.” That’s terrible. That doesn’t work. And that’s, you know, you talk about a cause of IT failures right there. You have a good one. So I think that if the project manager is taking that leadership role then they should have input into the hiring of the team. They should have input into the definition of the project because if you don’t have… if you don’t have communication upfront at the beginning before the project begins, in the definition of the problem what are we actually trying to solve with technology. Then the solution becomes compromised. And so what you really want is the ideal, is to have the business being the driver of the need because it’s a business project, not an IT project. You bring in the project manager to have the discussions that the project manager should be part of those business discussions, as the business isolates what it actually needs. The project manager can then go to the development department and start having conversations with the development management saying “You know, we need this thing done and it’s urgent, or it’s not urgent whatever it is. And now can we start to get some developers involved, so that we can construct the project from a development side in a way that is realistic, that’s going to help us get this thing done as the business needs. That’s a great role for let’s distinguish between a project manager and a project leader, that’s a [inaudible voice] project.
[Yegor] You know sometimes people say that there is a role of a product owner, so-called. Like, there was a project manager who was responsible for like you said schedule, budget, I don’t know, risks, quality control things. And we have a product owner who is responsible for making the product right. You know, who are responsible for how the product is going to satisfy the requirements of our users, of our business part and all that stuff. So what do you think about the separation of a project manager who is like a person of a documentation person mostly and management, and product owner who is more like a product person.
[Michael] I think it’s fine. I think in some situations especially with a complex environment where you have a lot of people involved. It’s a great idea just because in this case the product owner as you’re describing is taking the role of the understanding the business needs. However I would say that again I think it’s a mistake to simply delegate the… assume that the project manager can manage the budget, manage the timeframe without understanding the project goals. Yes, it’s done over time, but I think the more up to speed the project manager is the better job she or he will do that’a my own opinion.
[Yegor] You know, I can tell you the story which happened to me a few years ago. I was working at a company and my boss was like the CTO of the company, he decided to put me in charge of a small group of developers. And when I started to work with this group of developers I quite like… Next day I found out that one person is not really a good developer at all and it would be better if I do something, I mean, remove that person somehow from the team and move it somewhere else, so I wasn’t really happy with the productivity of that guy. Not with the productivity but the professional skills most like. It was clear that he is not as good programmer as other people there and I started to complain about that but the boss, the CTO, told me that these people are in the company way longer than I am. So I just have to put up with that and just manage what I have. So I don’t have the the power, I don’t have the permission to do any organizational changes in this team, and that was a really difficult situation for me because it was obvious that I had to do some organizational changes but because in order to demonstrate to the team for example, that I care about the quality, I see the difference between good programmer and bad programmer, but I wasn’t able to do anything because my hands were tied by my upper management. So how would you analyze that one. What was it?
[Michael] Yeah. I think that one would be hard for anybody. It’s you’re kind of in a no win situation there. And because on the one hand you know that the person who’s doing the job doesn’t have the skills to get the job done in the right way. And at the same time you don’t have the ability to make a change which means that when the project fails, you will be blamed. And so in that case you might want to look for another job. I mean, look, if it’s a very big project, a very important, very visible project and you’re in this kind of situation where you know you’re going to fail. Well you know the project will fail and you will be blamed for it in the end, then you know maybe it’s best to leave maybe that.
[Yegor] That’s right. Here is my next question. That person who was not really a good programmer, he was really a good communicator. He was staying in this team from the first days. So he knew everybody. He was like a glue in the team. You know he talked a lot, he knew all the stories of this company. He was like a main guy of the company even though he was not the best programmer, the worst one. But he was like a friend of everybody else. So that brings me to the next question. So what’s more important for us—to have the programming skills or to have that so-called soft skills that help us talk to people around us. Maybe that will help us to stay in companies that projects follower like my example demonstrates.
[Michael] Well that’s a very good point I think. I don’t think you could say that one is actually more important than the other. I think I would probably give the nod a little bit to the technology, to the technical skills because if you don’t have sufficient technical skills, then you just can’t build what you need to do. On the other hand even if you have great development skills, if the communication is not there then your project… you’ll end up with a project after it’s done and you’ve spent the time, you spent the money that doesn’t do what it’s supposed to do. So in a case like this one, where everybody likes this person maybe what it would be possible to do is… like, this might be a good case, where you can split off the development role into two pieces and make this person like the product owner because they’re communicators. You can say “Okay well, can you spend 10 hours a week doing this thing and then let’s get your colleague Mary or Joe to help with development and you make sure that Mary or Jo is a really-really strong developer. So that’s an idea.
[Yegor] Because now, currently, I hear it very often, that people are saying that just writing code will not get you anywhere. So you have to know how to talk to people especially now when people are sitting further and further away from each other, there are more remote programming, more remote IT work and the companies are spread all over the world. So how to talk to people, especially people sitting somewhere and speaking different languages, is more important skill than just creating code. That’s what I hear.
[Michael] I think that’s absolutely true. I mean I myself and CXOTalk have a very distributed team. We have people in the US, in India, in the UK, in Australia. So I think when you have a distributed team, the ability to articulate both the business requirements, the needs, as well as issues that come up on development becomes even more important, and where it gets very difficult is when you have different cultural attitudes or different, you know, different words can have slightly different meanings in different cultures, you know, here in the US versus, say, India. I mean, you have, kind of, you have to somehow learn to overcome that, because otherwise it becomes very frustrating, right? It’s like I’ve told this person what to do. And yet they’re not doing it. But what you told them may not be what they understood. And so it becomes… so it places a greater burden on everybody to be clear and emphasize that communication. It’s hard.
[Yegor] Yeah, it’s a good point. I totally agree. I’m also managing programmers from different parts of the world and I see that sometimes one person from Moscow, another person from San Francisco, they need different types of, you know, explanation in order to understand what needs to be done. But isn’t it, let’s talk a little bit about this diversity problem, isn’t that some kind of, you know, a first step to discrimination, sort of, if, for example I’m a manager and I have managers under me, wouldn’t it be right to like call a meeting and say “You know guys, if you manage programmers in India, this is how you manage them. But if you manage people in San Francisco, this is how you manage them.” They may say ‘Look, what are we talking about. They’re all like we are supposed to be like, you know, equally managed, so why this sort of discrimination is in the way of management?”
[Michael] Yeah, I think you raise a good point and I think you have to be extremely delicate about that and I know I’m not advocating that you should do that either. I think that would probably be a mistake. However, there are some very practical things. Okay? Just for example, in certain times of the year, in certain places, in parts of the world, there can be a rainy season and then it’s conceivable that during the rainy season the developer can’t get to work. And you have to just, you know… it’s just the way that it is and you have to acknowledge and recognize that. So that’s kind of a… no, maybe it’s an obvious example, but there are differences between people and I think that we need to respect those differences. And it also becomes place the burden on ourselves to try to understand what we need to do in order to communicate more effectively for the benefit of the other people that we’re working with. So I think that it becomes a big problem when you start to point the finger at other people and say “Oh, they need to change, they need to be different” as opposed to saying “You know, this is not working. So I need to figure out what to do. How can I be a better communicator, how can I listen more carefully? What can I ask them to help? Help me understand what’s going on with them. All of each has to come from the perspective of being respectful to those people and starting with the assumption that everybody on your team has been selected very carefully and they’re all competent, and they’re all trying to do the right thing. And therefore, if there’s a problem, it’s not intentional. And so we have to work together and collaborate to solve it.” At the same time look, if you have teammates that are weak, then you have to deal with that. But presuming you hired the right people, and you have the right people then everybody has to make that effort. That’s my feeling.
[Yegor] That’s a good point like right people. Let me give another example, for example, in our company we have the quality control and the quality control procedures. They demand certain things from all programmers. So no matter where you’re from, no matter what’s your culture, no matter what’s your gender or whatever, you’re just supposed to follow these procedures in order for your code to be accepted and you’ll get paid, for example. And we just know and it’s like scientific fact that people in certain regions of this world are more or less assertive. So for example people from Western Europe are more assertive and more direct than people from Asia. So when you tell somebody from Germany that you have to do it this way, that person will just understand that this is the procedure and we’ll do it that way. It’s just a cultural thing. And people from Asia, they will feel more like there is some area for compromise and they will try to find a compromise. So for them it will… Hello. Do you hear me?
[Michael] Now I hear you, you dropped out for a minute.
[Yegor] I’m sorry. So for those people like for example Asian part of the world and from India for example, they will be at our protests, our procedures, our discipline of the work, will be more difficult to adopt, because this is against their culture, it’s against their… how they usually work in their territory. So would it be correct for us as a company to say you know we don’t want to hire people from Asia, because we know that for them it’s difficult to work in our model. So we just hire people from, say, Germany, I think
[Michael] You have to be careful about making distinctions that are potentially discriminatory
[Yegor] This is very discriminatory, like I told you, then I don’t make that. I’m just thinking that what would happen if I do that I’m not doing it now, because you know what I’m doing now, and I’m trying to help everybody who joins us to follow the procedure. But I just see that for some people it’s more difficult, for some people it’s easier. So I’m thinking what if I say, or other companies who are listening to us right now would just say “You know, we just know that certain amount of people, certain group of people coming from that culture, coming from that territory, it is just gonna be difficult for them to work like we work. So how about we discriminate them. I don’t like to say that but I’m just suggesting. What do you think?
[Michael] Yeah. Yeah, I think you just have to be really careful. I think there’s two parts of it. One—you have to be very careful discriminating against a group. And I think it would be generally unfair to say that everybody in Asia, no one in Asia can do the work the way that we wanted to do, right? I mean that’s just wrong. That’s not correct. At the same time you can expect individuals and demand that individuals do it the way you want to do it, and so I think that you should apply the same set of criteria to all groups. Okay? You have a criteria for how you do development. You have a set of expectations for how you work and what you want and different countries have different economics, for example, and different time zones as well. And so you then choose the developer based on a number and this is always true, right? I mean you’re going to choose based on a number of characteristics you’re going to choose based on are they qualified? Can they do the work? The price? Because different economies, different countries have different pricing levels, so what’s the cost going to be? You’re going to choose based on time zones. For example if you’re in the US, you might want somebody in Europe who’s five hours time zone difference as opposed to Australia or Singapore, say, where it’s 12 hours time zone. And then there’s education, you know, you’re going to choose based on education, which is going to be also correlated to the amount of money that you pay. Are you’re going to choose based on an experience, how much experience does this person have both as a developer and also working on the types of projects that I am working on, right? So you’re going to look at all of these characteristics and I think that when you start isolating groups of people based on that you know rich set of characteristics then you go into discrimination and you also are now cutting off people who could do a great job for you. Both of those things are happening.
[Yegor] That’s true, yeah. You know like you just said, for example, if I decided I only hire somebody with the master’s degree or higher then I basically discriminate the group of programmers who were all able to get the master’s degree for social reasons, right? But I entirely isolate that group of developers who potentially may bring good value to the project, but I just say no, just at the beginning of hiring process, just because they don’t have the degree.
[Michael] Yeah, but you know what, if you let’s say that you have… So now you’ve hired all of these people with master’s degrees and Ph.D. and now you have all these really experienced people and you’re paying a lot of money for them and now you need people to fix bugs or to do testing. Oh now you’re going to go and you’re going to hire people with much less experience who are much less expensive and you’re also now going to be discriminating against the class of people who have master’s degrees.
[Yegor] True.
[MIchael] So I think this is a very important issue. One needs to be very sensitive to it but at the same time I mean I think you can kind of go overboard. I mean look every job has requirements.
[Yegor] Exactly. Yeah. So we do discriminate anyhow, right? So somehow we discriminate but maybe the question is what criteria we discriminate on, like that criteria which these people have no control over for example gender, or the color of the skin, or the criteria which these people can control, like education.
[Michael] Maybe you know I’m not sure discrimination in this case is the right term. The reason is that… yes, it is discrimination in a sense. But actually the problem is that discrimination has taken on a lot of cultural and social and political very negative overtones. When the reality is that we make discriminations or let’s instead of using the term discriminations let’s say we make judgments or evaluations constantly, all day long. I mean when you choose to go to your local coffee shop as opposed to Starbucks you’re discriminating against the class of people who work at Starbucks and vice versa. If you go to Starbucks you know why are you discriminating against, you know, people that run independent coffee shops. But the reality is that there are some criteria that’s important to you. Like you know the local people I want to support my local businesses or they make coffee better or they don’t make coffee well so I go to Starbucks and we make these judgments and we make these evaluations all the time but we have to be intelligent. But I think it’s different when it comes to people and we have to be very careful not to give in to preexisting biases that we may possess, that both is wrong culturally, socially, it’s just the wrong thing to do. And at the same time can also compromise our ability to put together a diverse team. You know in CXOTalk I speak with some of the most experienced leaders and researchers in the world. And without exception, when I talk with people who understand team dynamics, they say diverse teams bring great strength. And so we don’t want to limit our teams and and block ourselves from having the advantage of diversity, of different types of people, and different types of experience, and different types of perceptions, but it’s a delicate issue.
[Yegor] Oh yeah. Very much. Don’t you think that those speakers are saying that’s a little bit, or maybe mostly because of the modern trends in this area, and it’s just important to say that or they really feel that?
[Michael] No, I think that the people I speak with you know they’re studying this stuff and I wish I had data on this right in front of me. But I mean I’ll just give you an example. I spoke, I interviewed just very recently. I haven’t published this yet. One of the very top people of ADP. You know, it’s a huge company. The payroll processing company. It’s one of the largest companies in the world. And I just interviewed their head of products, and he was saying to me that their research says that diverse teams bring the greatest strength. And that’s not something like, I mean, when a company like that goes out and does research, it’s very serious and so when somebody tells me that I say “I believe it” and I don’t think that they are just saying it, because it sounds nice to say, they’re saying it because they want their customers, their clients to follow that recommendation.
[Yegor] But they are saying that diverse teams bring great value comparing to a non-diverse teams or just great value.
[Michael] I think it’s compared to non diverse teams because also diversity can take on as we were just talking can take on many different attributes. So for example you can have a team of the attribute of country of origin of racial composition, of background and experience, of whether they are a full time employee or a contractor. Right? So there’s all of these different dimensions. And I think that for your given, for any given project you need to look at what are the dimensions that the judgments that you need to make to compose your project, your team. Look at the end of the day. You know we started this conversation talking about IT failures and project management. At the end of the day there is one single cause of success or failure on a project, and that is the people that are involved. And that’s it because if you have the right people, the right people means that they have the right skills and they also have the right judgment. So if you have the right development skills and you have a project manager or you have a product owner as you were describing, who is able to talk with the businesspeople and you have businesspeople who are [inaudible voice] and not conflicted themselves about what they want. You bring all of those things together and you will have a successful project. And so therefore the composition of your team, the success of the project. And to get back to the very first question you asked me is should we be blaming the project manager. And I make the argument that the success comes before the project begins. That’s where success lives. And it’s all about the management, the selection of your team. And the diverse teams are a part of it. It’s not the only factor, but it certainly is a part of it.
[Yegor] Oh, definitely. But look you just said. I totally agree. So the skills are important. The selection of the team isimportant. And then all of a sudden we have this statement, that claim that when the team is ready, let’s say that we selected the right people, we know that the skills are perfect or good enough for us and then we think “Okay, wait a second. This team is not diverse so we don’t have… we only have like programmers who are from 25 to 27, so we don’t have anybody who is over 50. So now when you to find somebody who’s over 50 to make the team diverse. So when you to remove somebody who has good skills and gets somebody who maybe have also good skills but that person will be over 50. Right?
[Michael] Ok. Well I don’t think that’s weird at all. And I’ll tell you why, but it depends on what you’re doing. So let’s say for example that you are building enterprise, let’s say, two different situations, okay? And the one situation you’re building enterprise software where to understand the business process, you really need to have worked for, you know, a career. Okay? And there are three types of software where if you don’t understand the business processes and understand how enterprises work, the software is not going to come out right way. So in a case like that then, if you don’t have somebody who really understands the process which means the senior person maybe not as a developer, but on the business side to explain it to the developer, you have a big problem. On the other hand, if you’re building an app for college students, then I don’t see the value necessarily in somebody who’s been working for 30 years inside a big company.
[Yegor Exactly. But then the manager will tell you “No, we want diversity. It’s important to get somebody who is over for senior because the diverse team is more productive like everybody says. That’s my question. Doesn’t it look like that aiming for diversity and no matter what. It’s kind not stupid but it’s kind of weird because the diversity by itself is not the logical goal because the goal is the right skills, the goal is the people who have the right skills and diversity comes next. That’s why I’m asking.
[Michael] Yeah I think that this is… I don’t think it’s that complicated. Okay? Because I think you build your team as you’re describing, based on the skills that you need and at the same time and the outcome right? I mean you’re trying to get a certain outcome so what’s the team that will help you build that outcome. Okay so that’s where you start. At the same time there are legal and compliance and also ethical issues that are involved in team selection. So as long as you are using common sense about the building of the team based on what you really need and you’re not violating legal compliance or ethical considerations in the selection of the team members, I think that’s… I don’t know what else you can do. I mean that’s all you can really do. You can only try your best and make a good faith effort at doing this and don’t violate legal compliance and ethical standards when you’re doing it.
[Yegor] Yeah I agree.
[Michael] And sorry. Sorry, just to finish I didn’t mean to interrupt you, but to be respectful you know to like realize that when you’re building your team, you have to start with a respectful and an open mind. And I think if you do that, you’ll be in pretty good shape.
[Yegor] Yeah, that’s exactly what I have in mind, so that’s my thought. That’s my thinking as well, that, like, don’t aim for diversity but never say no, don’t never be prejudiced against anything so no matter who’s coming in, if the skills are right. Just get in. So no matter what your age, what culture you are coming from, it doesn’t matter, as long as you can bring the value to the project you’re welcome here but saying that you know what we have enough you know male programmers here, so now we need three more females. And because of that we don’t hire male programmers anymore this year. That’s a little bit weird.
[Michael] Yeah, that’s right. Unless you are… there are times when for legal or compliance reasons, you just have no choice. And then you have to, you know, you have to go with it. You don’t have any alternative.
[Yegor] You know, it’s true, that’s why I asked. Originally I asked like a few minutes ago, so what do you think these people are saying “Diversity is so great” because this is the trend, because it’s the legal requirements or they really think so, because the law says so, okay, what can we do? Because it’s a law. But do we really think so? Do we really think that the team has to include 50 percent of male programmers and 50 percent of female? While we all know that in the world only 7-8 percent of programmers are female. So building a team of 50/50 is kind of… it’s against the market, it’s impossible because we cannot find that many, you know, good female programmers versus good male programmers because it’s only misbalance on the market. We know that, it’s a fact, statistic. So why aiming for diversity, it will only make us worse, only make our team worse not better.
[Michael] Yeah, I mean this is why it’s such a difficult problem to solve. But there’s another factor, another facet of this which is when you hire somebody who is from a group that historically has been discriminated against, like women, for example, very often what you find is that at a given level the women may even be stronger than the men because to get to that level, this is definitely true I think at senior levels that the woman has had to overcome so much to get to that same level that they have to have even better skills because of the adversity that they’ve just faced
[Yegor] Yeah, that’s true. I agree.
[Michael] So that’s another dimension of this, too.
[Yegor] Well that’s for sure. Yeah, it makes sense it’s a difficult subject actually because we all talk about that, but it’s you know, we can’t find the ultimate truth there, I think.
[Michael] No it’s a really hard one. But like I said I think you start with your business goals, you start with what you need. Make sure you have respect for everybody. You know having as a goal bringing diversity onto your team of whatever type in general is a very-very good thing. And so you try to do that and then you make sure that you don’t violate legal ethical or compliance standards. And if you really make a good faith effort at that and you’re willing to work at trying to get women on your team for example eventually you’ll be able to accomplish it. That’s what I think.
[Yegor] Okay. Yeah. Some people, yeah, I know a few people who are saying that we are aiming for diversity and we actually achieved that. So we have like you know a good balance between different ages, different genders, all that stuff. But…
[Michael] There are companies that do this. There are companies that are able to hire a lot of women. So it’s not impossible, it can be done.
[Yegor] Yeah, I can give you a practical example, I’m looking right now for a Ruby programmer for one of my projects and I posted an ad on Stack Overflow, it’s quite big website for programmers and I got like maybe 60 or 70 applications so far and only one person is female out of there. So for me to build a team, a good team of Ruby developers I cannot do it technically because I have 59 male applications and one female. So what do I do, what’s my next step? How can I… Let’s say I need a team of ten people. So should I wait for another three months or it’s impossible to achieve. Technically, it’s just…
[Michael] Yeah, I mean what you could do is you could find somebody who is a female developer, a great Ruby developer who maybe has a job and say to them “Do you know any female friends?”
[Yegor] Yeah. But she may also have the same statistics, I think she will also work with the same market she will go, it will maybe a little bit more balanced towards females but in general the statistics will be close to the same like 7 percent of the programmers, or 7-8 or something females. So it’s like it’s not good. I’m not saying it’s good. You’re right. You’re saying they were discriminated for historical reasons. We have that, we’re not saying it is good, we’re saying it’s a fact, you know, statistical fact. It’s like you know the majority of pilots on the airplanes, they are males. Statistically it’s just sex. So it’s not good or bad. It’s a different question but if you start an airplane company that you want to have to hire pilots then you will deal with men only. That’s it. You cannot have 50 percent male/female there.
[Michael] So maybe what you do is you hire females in other positions or maybe other types of teams. You know maybe hire a female project manager or a female PR person where it’s easier to hire women.
[Yegor] Yeah definitely. A few more questions and we’re close to the end I wanted to ask you about what do you think in general about hiring friends, people who you know personally or going to the public market and getting people who are complete strangers when you start a project? So the question is how important personal relations, according to your experience, versus just professional skills for a team?
[Michael] So you’re talking about at the beginning like when you’re starting out?
[Yegor] Yeah, you’re starting a team, you’re starting a new project and where do you find these skills, from your friends? You look over your connections and close friends or you go to the market?
[Michael] I, you know, I think a lot of times you don’t have a choice. The reason I say that is it depends where you are if you’re just at the beginning. If you don’t have funding, if you haven’t gotten funding yet then very often founders, you know there’s two founders who know each other professionally, who have the right skills and have the right type of relationship. So I think in a case like that then it’s better to go with people that you know and you hope that they have the right skills even though you recognize that maybe over time not everybody will have the right skills which will then lead to the very-very painful situation, are having to ask somebody to leave in the future. But on the other hand it’s not so easy you know. I mean you know better than I do that if you’re doing a startup, it’s not just about the skills but it’s about the chemistry as well. And it’s not so easy to put an ad in the paper that says “Willing to hire cofounder, must have good chemistry.”
[Yegor] Yeah. Finding like a partner for marriage.
[Michael] Exactly, right, exactly. But I think that once you hit him at a more mature stage where you’ve now got the core team together and you have the funding where you can go, where you’re not looking for chemistry as much as you’re looking for specific skills. But even then it makes sense to look, you know to get a job boards and to look for professional things, professional sources. However, at the same time even at that stage, if your company, if you’re trying to have a certain type of culture, then to me technical skills is the least of it. You know you can generally, unless you’re looking for somebody who’s a real specialist, you can tell you’re hiring technical skills as a matter of money. You have enough money you can hire the right tech skills. However, finding somebody who’s going to do what you want, who’s going to fit in and be there for a while and give you what you need without life being horrible and stressful—that’s harder. And so I can tell you when I hire people, I look like like the technical skills are table stakes. I expect, by the time I interview somebody, I already know that technically they can do the job. And so what I’m interviewing them for is where I suspect technically they can do the job or even talk to them. And so therefore what I’m looking for is, in my case like with CXO talk like excellence is absolutely essential to what we do. And so I want people who are going to give me really their best not just in words but I want to just absolutely their best and that’s a certain kind of person. So that ends up what I look for when I hire somebody, just as an example.
[Yegor] So basically, if I got it right, during the interview you’re not checking the technical skills you’re looking for, you know, you’re looking deep in their souls understanding whether they will be loyal to you in the long term, whether they will share the project values with you and all that stuff. Correct?
[Michael] Yeah I mean I validate that they have the technical skills but usually by the time I talk to somebody…
[Yegor] You already know.
[Michael] I’ve already done you know I’ve researched them I don’t just invite people in because it takes so much time. We’ve talked to them on the phone. I research them. And if there’s a project manager then I have to ask the project manager to do the initial screening interview, so that by the time they come to me, I’m confident that they can do the job, I’ll validate that nobody else has made a mistake that yeah they really can do the job technically, but I’m looking for can I work with this person. If I tell this person that there is some detail that needs to be done differently or better, are they going to do it with a smile because they take pride in their work, or are they going to be resentful and resist doing it. That’s what I’m looking for, for me.
[Yegor] Okay, my final question to you. Can you give our listeners the recommendation on how to detect that, how to validate that, whether the person will do it with a smile or hold their hesitance?
[Michael] Yes I can. There is a way, and I think the answer is you don’t have a technical discussion, or let me rephrase that, you shift the discussion away from technology and you have to get to know them as a person and start talking about something completely unrelated to technology, talk about politics. I’m not sure that it is today, maybe three years ago, but I’m not sure about today, even three years ago, probably politics and religion is not the way to do that. But ask them… you know, just start talking about, you know, something that you’re doing, that’s interesting to you and just see how they react. You know, are they friendly, are they open, do they seem mentally and emotionally flexible enough to take a conversation in different directions. That’s a form of emotional intelligence, the ability to shift away from the technology sphere, right? That emotional intelligence is how closely do they listen. Like for example, let me ask you, you know you have, you’re involved in all of these adventures. What’s the most important what’s the hardest thing about juggling all of this stuff?
[Yegor] Oh it’s… I would answer that. It’s how to deal with the personal stress coming from failures. Because when you juggle them you sometimes you fail and you fail quite often, the more ventures you have, the more opportunities you take, the more companies and startups you start, the more failures you have, so that the stress which is coming out of failures is difficult to deal with the personal. So that’s the most challenging and difficult part in it for me.
[Michael] Okay so look at what we just did. We just completely shifted topics away from hiring people to a completely different topic and you jumped there and I asked you that without any any planning. So you jump there very-very quickly without hesitation and so to me that indicates a certain ability to… there’s a certain type of intellectual flexibility that’s involved, that’s required in order to do that, in a certain… also a certain level of confidence, that’s required to do that.
[Yegor] So you would hire me?
[Michael] Yeah, sure. But I also know, given your background and all the things that you’re doing and the fact that you’re an entrepreneur and have done all of these things, so I also know that there’s a pretty good bet that you’re a selfstarter.
[Yegor] Yeah, it’s true. That’s the interesting part of that, I really will take that advice from you because that’s… because I’m making the mistake, I quite often focus myself on technical questions. Now I realize that this is a really good advice.
[Michael] Oh well thank you. I think the technical… and I’m not a technologist so I don’t really have a choice here because I don’t have the ability, I’m not a developer. So I do not have the ability to evaluate technical skills the way that I would really like to. So I try to get somebody else to evaluate those technical skills but I know enough to be dangerous. I know questions that I can ask that will be really hard. Not stupid questions but things like you know performance tuning, like say on a particular website that their performance has an issue, and I know that it’s hard to solve because I’ve seen developers who worked for me having trouble with that kind of thing. So I might ask a developer well how would you address this kind of issue. So you have to validate, but at the end of the day it has to be harder when you tell them what you want like how do they react, are they excited or passionate, or were they like “Yes I can just do that whatever.”
[Yegor] Ok it sounds good. It was really a good conversation for a whole hour and I have to wrap it up. Thank you very much.
[Michael] Thank you so much. I’m honored to be here. Tanks a lot.
[Yegor] I pretty hope to have you with us one more time.
[Michael] I would love to do it any time you want.
[Yegor] Thank you. Bye-bye.
[Michael] Have a good day. Bye-bye.
