Initially, I spoke with some people at AndersonRiskAssessment who said they needed help training the team at DevModeMax. I would work for DevModeMax, and would be embedded in their team, and would help improve quality from the DevModeMax side, improving the architecture and training their software developers.
At this point, I had a long one-on-one conversation with Emory Azin. His thinking about the Luganesk software, and the mistakes they had made in the past, and the direction they needed to go in the future, was profound. Frankly, his intellect was dazzling, so much so that after an hour I said:
Me: So, listen, I'll speak honestly here. Are you sure you need my help? I feel like you've already figured out every problem you have. You seem to have an intuitive feel for software architecture at large scale, and you know what needs to be done next. So why would you need my help?
Emory: Well, first of all, it would be good to have an outside opinion to either confirm or refute some of my ideas about how the architecture should evolve. But second, we need help dealing with the staff at DevModeMax. We were promised senior level engineers but we got a lot of people who have no experience. This is their first project. And they are really struggling.
Me: What have you done to help them learn?
Emory: We've done some pair programming, but we are spread very thin. Up till last year we had 30 engineers at Luganesk, but then they suddenly let 25 of them go, so now there are only 5 of us who still know the system.
Me: Wow. That must have been a shock.
Emory: Oh, it was. We had no idea. One day some of us were invited to a meeting, and everyone else was invited to a different meeting. And when we got to the meeting, they told us that everyone at the other meeting had just been let go.
Me: Why did they do that?
Emory: I don't know.
Me: I have the impression that AndersonRiskAssessment is doing well?
Emory: Record breaking profits.
Me: So this was not a desperation move?
Emory: No.
Me: But they must have given a reason?
Emory: Our new CTO, Arwin, he said that he thought this would enable further growth.
Me: Has it enabled further growth?
Emory: Well, the problem is, we've been stuck for the last 8 months, unable to get anything done. At first, DevModeMax said they needed two months to learn our system. Then another month. Then another month. A few of them started in July, but most of them started in August. We started offering classes for them in August, educating them about our software. But it wasn't until January that they began to write code.
Me: Wow. That was a long time.
Emory: And still, even now. Our pace is about 20% of what it used to be.
Me: That must be frustrating for everyone in the company?
Emory: At some point you'll talk to Lucy. She is going crazy because of all the delays. Everything that we planned for this year has been postponed.
Me: Okay, so let me repeat, are you sure you need my help? You sound like you know exactly how you want to evolve the architecture, and the problems you have with the new team sound somewhat political.
Emory: So, what I was thinking is, you come in spend 90 days learning the software, and then you can help us train the team at DevModeMax. Or, sometimes, you can identify who is unable to learn, and then we can try to remove that person from the project.
Me: What exactly do you mean when you say "try to remove a person from the project?" You mean fire them, right?
Emory: No, that is not how the contract was negotiated. The contract was negotiated in terms of how many software developers DevModeMax was contractually committed to offering to us, but not who they are. We have no power over who works on our software. There is one individual, we've asked that he be removed from the project, because he's already done a lot of damage, but 2 months later he is still working on our software.
Me: Whoa! That is wild! It sounds like the contract was negotiated in a way that it lacks some basic systems of accountability?
Emory: This might surprise you, but you are the first person we've been allowed to talk to, before you are hired by DevModeMax. We've been asking for the right to talk to potential new recruits, but so far DevModeMax has not allowed us inside their hiring process.
Me: I admit, I'm stunned by this. I've been at many companies that have outsourced some work to India or Brazil or Vietnam or Ukraine, but I've never heard of a company outsourcing so much control.
Emory: They don't trust us, that is the problem.
Me: Who are you talking about?
Emory: AndersonRiskAssessment.
Me: I don't follow. What do you mean that AndersonRiskAssessment doesn't trust you?
Emory: They don't trust us. They think we made mistakes with our software. That's part of the reason they want help from DevModeMax.
Me: I'm very, very confused. Are you saying that the leadership of AndersonRiskAssessment trusts DevModeMax more than they trust you?
Emory: Basically. I mean, look at what they did. They ambushed us. They negotiated the whole contract with DevModeMax without ever telling us that they were talking to DevModeMax. They let go most of our team without ever asking us what we were working on or what we thought the future direction of the software should be.
Me: This makes zero sense to me. Zero. Why would the leadership of AndersonRiskAssessment trust an outsourcing team more than they trust one of their internal teams?
Emory: I don’t know. Arwin worked with DevModeMax before, at some other company, a few years ago. So I guess he trusts them.
Me: Arwin is the new CTO?
Emory: Well, he's been with us since the summer of 2021. He'd been with us maybe 8 or 9 months when he made the decision to bring in DevModeMax. Unless, maybe, he was always planning to bring them in. For all we know, when he was hired, he pitched that as his plan, maybe he was hired specifically to bring in DevModeMax. The problem is, we are kept in the dark.
Me: Wow. I don't know what to say.
Emory: Look, I'll be honest, if you start working here and after a month you decide it's too big of a mess, and you suddenly quit, I totally understand.
Me: Thank you for that. But my whole career has been focused on helping companies through difficult transitions. It's practically a specialty of mine. I know I can help train the team at DevModeMax. However much that might help, I'm happy to dive in and do that much.
Emory: That would be great.
Me: And maybe over time we can convince the leadership to trust you?
Emory: That would be especially great.
For several days, I turned this conversation over and over again in my mind, like it was a bizarre sea shell I had found on the beach – sometimes I looked at in one light and it seemed familiar, but other times I wondered if I had discovered some new species unknown to scientists. I had dealt with distrustful CTOs before, and I’d dealt with bad staffing decisions – all of that was familiar. And yet there was something about this case that felt extreme.
Why is that sometimes a CTO does not trust their team?
One upon a time, many years ago, I was invited to a job interview at Time Warner. They were going to transition all of their internal websites to use the Drupal framework. I hated Drupal, but I knew it, and I needed a job, so I went and spoke to the engineer in charge of several teams, a man named Marrot. I liked him very much, and we seemed to agree on many subjects related to computer programming, so I finally said to him:
Me: Look, to be honest, I've never liked Drupal that much. I haven't liked engineers who liked Drupal. But you seem very intelligent. You seem like a good engineer. And you obviously love Drupal. So tell me, what is about Drupal that you love it so much?
Marrot: Oh, I hate Drupal. It's awful. It's too complicated for what it does.
Me: Uh... Oh, I see, so it is your boss who loves it?
Marrot: God know, my boss hates Drupal.
Me: Uh... oh, I see, so you just really need to get rid of your current system, and you figure Drupal is at least a little bit better?
Marrot: No, no, no, nothing like that. Our current system is great. I want to keep it. But we are switching to Drupal despite that.
Me: Uh... so.... why?
Marrot: Well, some departments said they needed more features. We could build them or we could switch to some system that maybe already has them. And our CTO decided to hire PriceWaterhouseCooper to come in and do a study. They spent $7 million doing the study. And in the end they said Drupal. So the CTO is making us all switch to Drupal.
Me: Did the CTO talk to you about what you thought you needed?
Marrot: No. He just listened to PriceWaterhouseCooper. So now we need to build a new system using Drupal.
I did not take that job.
But I have thought about it a lot.
Why would a CTO not listen to their internal teams?
1. Maybe the CTO thought the internal teams lacked perspective?
2. "When all you have is a hammer, every problem looks like a nail." Maybe the CTO thought that PriceWaterhouseCooper would have a big vision of what was possible, something the internal teams were lacking?
3. Maybe the CTO didn't actually care about the answer, they just wanted an answer, and they wanted it to be an industry-standard answer, so no one could accuse the CTO of doing something unusual. High level executives at big firms are typically risk averse.
4. Or maybe the CTO felt that Time Warner offered minimal salaries to software developers, and therefore attracted minimal talent, and so the internal teams consisted of stupid people who were poorly paid. By contrast, the analysts who worked at PriceWaterhouseCooper were very well paid and therefore they must be intelligent.
In the end, who knows? All I can say is, I've seen this pattern many times, where the CTO did not seem to trust their own team (or teams).
(But I should add, I did eventually meet some good managers in AndersonRiskAssessment. The CTO at Luganesk had been a guy named Walter, and after the acquisition he was promoted into AndersonRiskAssessment, and given the title of VP Of Engineering Of Transactions. From that vantage point, I think he did what good he could. But he was not able to protect the Luganesk team from being fired.)
Read the whole series:
1. But what do these glib little bullet points mean?
2. When the CTO does not trust their own team
3. Everyone is under pressure, everyone is too busy to help
4. They lie. They lie flagrantly. They lie all of the time, about everything.
5. That place is a total sweatshop!
7. I am very, very proud of you. The work you are doing is amazing.
8. I blame you. You suck. You are the problem.
9. We just got $10,000 dollars!!!!
10. The Taj Mahal was built with blood
12. Where are my story points, Gujurat?
13. We are the best people to help him, so why doesn't he want our help?
14. Should a toilet be listed as an amenity?
15. I am simply telling you how things work in India
16. Too big to fail: when you've no option but to brazen it out