Another Retreat

There was, not too long ago, a seven month project.

In the beginning, before my time, the mandate had been for multiple teams to be set up, each working on a particular new product. Many of these teams had outsourced their technology development, and each outsourcer had begun work on a stack that was completely different from the others.

By the time I was pulled into it, it had been running for six to ten months. The mandate for me at the time to was to set up an engineering team, and to streamline these applications. I recommended the implementation of a single engineering team to build and operate all these applications on a common platform. But, ex-technology, the organisation faced problems in other aspects of business development: lacking quantified KPIs, detailed financial governance, operations teams, and a cohesive narrative about each of several products. Much of this was obvious as soon as the situation was described to me.

Once on-site, we had four products to recover. Hiring was complete by the end of month-2. The team stood at five. The prototype application, which would be the parent of all other applications, was prepared in the first week of month-3... this was effectively a clone of the simplest of the four products to be recovered. That product's business operations were shut down in the same month. The team moved to repairing another application.

In month-4, the business owner of the third of the four applications requested that the engineering team provide design services. I took it upon myself to play the role of product owner in order to deliver this. As we neared the end of month-5, it became clear that no operations staff has been hired in that business unit since its inception nine to ten months prior - despite loud warnings from myself over the past four months.

So the first application, and the third application, had no operations teams. We had two new applications being demanded from top management. I volunteered to set up an operations team, with the caveat that we should kill off some of these applications if their operations proved to be unfeasible within a month. We would begin in month-6. We did not face negative criticism in month-6, whereas our lead developer, fatigued by the organisation, jumped ship instead of accepting an official promotion. We hastily scraped together replacement engineers for that, and other roles which had been schedule to end in the same month. We hired engineers with no experience in software operations, and several part-time students, as well as a remote engineer.

In month-7, top management became agitated that progress had been limited. Additionally, a non-engineer received the mandate to "restructure engineering." I had been signalling my interest in a holiday for several weeks, and then I was informed that my termination would be by the end of the final week of month-7. I was happy.

//


All of this leaves out various sub-plots and stories about a fifth, a sixth, and a seventh application, housed under the same roof. Those, we let loose to the sands of time.

Much happened thereafter, but it is not my place to say what.

Pretty Much Why I Can't Musk

Musk: “If we don’t succeed...people will say, ‘Well, they couldn’t do it, how can we?’”

Me: "If I don't succeed, someone else will figure it out. It's not that hard."

Abyss. And Instant Noodles.

I was wondering where my day went, then I remembered a random job interview that an acquaintance set me up for. There was no clear problem definition, besides the absence of a warm body, so I referred four candidates to the employer. More pro bono work, I suppose.