Parting ways with CODE11

After almost 18 years at CODE11 (even before it had that name), I’ve decided to part ways. To say the writing was on the wall would be an understatement; it’s as if Banksy was in the room spraying “Get out!!” on the walls and hitting me over the head with the can, while I stood there going, “Hmmm, I wonder what this means?”

The last two years have been pure cancer from a professional perspective. Yes, there were ups and downs as there always are, but the trajectory was clearly downward, and the downs severely outnumbered the ups.

While the outside context wasn’t favorable (the IT industry has taken a turn for the worse), the fatal wounds were mostly self-inflicted. I can imagine a version of events in which the current mess could have been avoided, if we could turn back the clock 3-4 and years knowing what we know today.

Off the top of my head, our downfall can be broken down in three main buckets:

1. Cultural issues Our open nature and flat structure bred complacency. Even though we liked to think of ourselves as technical partners, in practice we often acted more like just another outsourcing company - far removed from the problems and needs of the end user.

2. Technical issues Instead of taking the best frameworks and solutions off the shelf and becoming proficient with them, we often built our own custom-made solutions and approaches, which by almost every metric were a poor investment.

3. Business issues The business layer was deficient as well. Plenty of people on the dev team complained about a lack of support from the business side, and collaboration between dev and business often came with friction, creating frustration on both sides. On top of that, many on the dev team felt there were far fewer new projects in the pipeline than we’d been led to believe.

There are probably more reasons for our downfall, but these are the ones that come to mind.

On the bright side, what I enjoyed most over these past two years was product discovery. It’s never been easier to explore, mock, and build features, and to find the best solutions to a client’s needs. This ties nicely into the biggest lessons I’ve learned:

1. The client doesn’t know what they want Insert “faster horse” quote here. What the AI age has liberalized is access to domain experts. They might not be as knowledgeable as a human with decades of experience in the field, but they’re more than good enough - and available 24/7.

2. The best alignment tool is just building the thing Over the years we tried many frameworks and tools to align with clients: Miro flows and wireframes, Figma prototypes, OPM diagrams, event modelling, flows with data-powered cards in Fibery, and so on. They all worked to some extent, but they were all limited. What became obvious along the way is this: there’s no better alignment tool than just building the thing, or the closest approximation of it.