How Did I End Up Here?

It’s always good to remember where you come from and celebrate it. To remember where you come from is part of where you’re going.

—Anthony Burgess

Before we get into any discussion of frameworks or models, let me talk about the process that landed me here. Many, many years ago, I stumbled across my first struggling development team. After nine years as a relatively successful entrepreneur, the sale of the company and a year of R&R, I was invited to join a rapidly growing startup to lead their Development team [1]. The company had built a thriving services business creating web applications in the heady early days of the internet [2]. When the company pondered an IPO, they were told that product companies raise a significant multiplier over services companies [3], because services businesses scale only with the addition of people.

So the founders did what every late 90s Internet entrepreneur did – they completely changed their business model to one that could raise more capital [4]. They started a product team with some of their best Engineers and started to build a product [5]. There was no Product Manager to speak of other than one of the two founders, who split his time between financing discussions, press interviews and giving random requirements to the team. When I arrived, I asked what the product did, but I couldn’t get a clear answer. It was a bit like the old story of the blind men and the elephant [6] – everyone had a different view. One Engineer said that it was a multi-device development platform. Another said that it was a universal XML processor. Yet another said that it was a self-service application for telecoms.

I did get to see a complex architectural diagram. When I asked for an explanation, I got some very lengthy, but vague descriptions and was told that not all of the modules were actually there yet. But I was assured that it was capable of anything. That sounded pretty cool, but I still couldn’t figure out anything that it actually did.

Only a couple of weeks in, I was asked to accompany the Sales team to pitch a Customer on the “product”. The Sales pitch was not any clearer, but in those days, some great PowerPoints that led to confusion about what the product actually did somehow made the product seem more mysterious and appealing [7]. So, obviously, the Customer said “Yes” to a pilot project [8]. I spent two weeks with one of the Engineers trying to get the product up and running at the Customer site. It turned out that the code only compiled [9] on one Engineer’s computer back at the office [10] and we spent most of the two weeks trying to get it to do so on-site at the Customer. Left with only about a day to build a Proof of Concept, our resulting demonstration was underwhelming to the Customer and – of course – no sale was made.

Like the Sales prospect, I eventually realized that the framework did nothing. Sadly, the team had spent about a year to get to that point. To make a long story short [11], I formed a completely new team, shelved the project and we built a new product based on real Customer needs. Within a year and a half, the product was good enough to justify several large sales and an acquisition by a large US company.

I have had several other chances to turn around teams and each of my successes was fueled by many errors and failures. I eventually started to seek out opportunities to work with broken development teams and projects [12]. Each time, I tried to do a little better, repeating what had worked previously and learning new lessons.

Fast forward about twenty years: I had just helped a team finish a successful project that replaced a badly failing one [13]. One of the Engineers innocently asked me, “Why do you think that the original project failed?”. It seemed like a really simple question, but it turned out to be a complex one.

Over a series of whiteboard discussions, I started, for the first time really, to codify my learnings and my philosophies. When we got to the root causes through asking “Why?” a lot, the core issues started to emerge. What you see on these pages is the result of this process and I thank that Engineer for asking that simple question to force me to document my thoughts.

I hope that what I have captured is helpful to you in becoming a better Engineer, Engineering leader or – if you’re neither – to working better with your friends in Engineering [14].

So with that explained, let’s get to the main course in the next post: the model.

This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker

Footnotes:

[1] I was hired late enough not to be one of the employees who knew their hiring order number, so maybe employee number 40 or so.

[2] This was in the late 1990’s for those too young to remember.

[3] At the time, the difference in valuation between a pure services company and a product company was about 5-10 times.

[4] Notice that I didn’t say “more profitable”.

[5] Because, obviously, this is what product teams do.

[6] Link to the elephant story    Link to another elephant story

[7] Remeber that this was the era that popularized the terms “vaporware” and “slideware”. I’m truly shocked in retrospect what people were able to sell during that time.

[8] I’m hoping my sarcasm is obvious – these were crazy days indeed!

[9] For the non-Engineers, compiling is best described as the process of taking the Engineer’s code in Java or some other language and turning it into the 1’s and 0’s that the computer can understand.

[10] The prospect was about 1,000 miles away in an era when distance mattered quite a bit, since the best internet when you were working remotely was still dial-up.

[11] and it is a very long story 🙂

[12] I’m sure this proves that there is something deeply wrong with me. Very few people who know me well would argue this fact.

[13] For the record, this project was probably the biggest train wreck that I have ever seen (and I’ve seen a lot).

[14] If you’re not friends with your Engineers, you should be – we’re really awesome people and cool in our own way.

Credits:

Simon Migaj  Featured image of footsteps in the snow