When outsourcing goes bad, part 16 of 16

Too big to fail: when you've no option but to brazen it out

Jul 10, 2024

I did not stay long at DevModeMax. A friend of mine was starting her own startup, so I left to join her on her adventure. But I think the AndersonRiskAssessment/DevModeMax story is an important illustration of how outsourcing can go bad.

The story I'm telling in this essay is an unusual story for one obvious reason: top level executives at large firms tend to be risk averse, and firing 25 of 30 engineers is reckless. Especially shocking is the fact that AndersonRiskAssessment had record profits, and could easily afford those 30 engineers. This was not a desperation move, this was not a move forced on AndersonRiskAssessment because of circumstances. AndersonRiskAssessment could have kept the 30 engineers and also hired DevModeMax, expanding the team. That would have been the safe move.

So why didn't Arwin take the safe move? The only thing I can think of is that the possibility of failure never occurred to him. It is likely that he hired DevModeMax a few years ago, at another firm, and they did a fine job taking over some IT departments that ran standard Microsoft software, and so Arwin concluded that DevModeMax was a highly competent team that could handle anything, and so it never occurred to him that the Luganesk software was too complex for DevModeMax.

Now that they have rehired 4 of the engineers who were fired, it seems obvious that Arwin regrets the haste with which he fired them. Partially undoing a decision (firing the team) is a clear indicator that the decision had been excessive.

It is likely that Arwin was well aware of the fact that he'd made a mistake. But what could he do? This was too big a mistake to simply say "Oops, bad call, lets do something else." He was in his early 50s, a big success would catapult him to the top of any industry that he wanted to be in, but a big failure would force him into early retirement. All of his dreams of success, everything he'd been working towards for the last 30 years, was on the line. He could not afford to admit that DevModeMax was a mistake, therefore he had to brazen it out, to pretend that the current difficulties were the normal difficulties of any transition, and that soon everything would be fine.

At one point I was told that the Luganesk team, at its peak, cost $10 million a year but now it only costs $3 million a year. I've no way to verify these numbers. But assuming they are true, $7 million a year was saved, and then spent to hire a larger team at DevModeMax. The real cost was the lost year, when AndersonRiskAssessment/Luganesk was supposed to move into new market segments, such as medical malpractice insurance, and instead was frozen and unable to do anything at all.

Was it worth it?

At one point, Lucy told me that they used to think it took two years to fully onboard a new engineer at Luganesk, one year to learn the code base and one year to learn the insurance industry. To be useful, an engineer had to be an expert in both. But that implies that the leadership is constantly nurturing the growth of the team, as one might a garden, because there is no way to suddenly create a garden, it is something that one has to do patiently.

For most of its early history, the tech team at Luganesk had a culture of trust. That allowed them to be honest about mistakes, and it allowed them to correct themselves quickly. Deep conversations about the evolution of the commercial insurance industry shaped how they wrote the software, and the abilities of the software shaped which new market segment they would go after next. It was an iterative process that allowed a small startup to grow into a major player.

Could that culture of trust ever be recreated with DevModeMax? Clearly no, so I have to assume that Arwin is working with the common paradigm, "We design things in America and then they do the grunt work of building it in the Third World." Arwin is assembling a team in Atlanta that will, in theory, allow him to design the new version of the software that will replace the Luganesk software. My own belief is that Arwin will spend many years trying to catch up with what Luganesk already has.

As an example of bad practice, the emphasis on "10 story points per engineer per week" does not allow for deep discussions about the future of the insurance industry. But that's because Arwin thinks all of those high-level conversations will happen between him and the team he is building in Atlanta. From DevModeMax, all he wants or expects are mere mindless drones who do what they are told.

Whatever design Arwin comes up with, he will ask DevModeMax to build it. While this style of development obviously can be made to work (it is now in use by most of the world's major corporations) I doubt the somewhat adversarial relationship between AndersonRiskAssessment and DevModeMax will lead to the same kind of fast, iterative development that was possible at Luganesk.

To put this simply: Luganesk was a gem. It was beautiful. It was special. It's something every CTO should dream about, should hope for, should try to achieve. And Arwin does not seem to realize what a gem he had in his hands. So he decided to throw it away.

Whenever an entrepreneur is successful, it is natural to ask if they were lucky or were they smart? Bo Peabody built Tripod, back in the 1990s, one of the great success stories of the early Web. He later wrote a book with the title "Lucky or Smart?" and he concluded, "I was smart enough to realize that I had been lucky." But Arwin was the opposite of that.

I hope for success and prosperity for every client I've ever worked with. I want to see AndersonRiskAssessment and Luganesk and DevModeMax grow more and more successful. I assume that they will. Still, I think this story should operate as a warning to other CTOs: be careful how you outsource. You don't want to lose a year or two trying to onboard a new team. Consider taking a gradual approach that does not put your fastest growing division at risk.

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!

6. The Old Team Returns

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

11. Like a punch to the face