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.
