A Dashed Utopia of Project Operations
In the latter days of my tenure as director of software engineering for a small startup company in San Diego, I rarely needed to check my email, except for handling various external requests, only had meetings on rare occasions, and my team only used spreadsheets for the occasional quick analysis.
Yet we were all in constant communication, found new customers, and kept our existing customers happy.
My software and IT team played foosball together on regular basis; we went to team building events every quarter; and we went out weekly for lunch to a local restaurant to bond over the happenings in our lives, both personal and in business.
Yet we were still hyper-productive, getting more done in a few days than most companies of our small size could get done in a few weeks.
The company hummed along gracefully, and was my team and I were delighted to go into work every day.
We had our fare share of hiccups, for sure. No company, no system, is perfect. But just a handful of years earlier, the company did not even remotely look like the blissful utopian dream I just described.
When I initially joined, the company was already on shaky ground. I wasn’t sure it would even survive the next year. Before I even got there, the place was purportedly a mess, and then in the first three years I worked for the company, I was witness to a number of bad executive decisions, misaligned directives, political power plays, petty pandering, massive staff turn over, and even software sabotage.
When I took over formally as director of software, I had a lot of work in front of me. The team I had inherited, restaffed, and then refined, had to overhaul the entire backend server system, the content management system and host of miscellaneous other tasks that had simply not been well managed over the course of he previous three years. The only thing that had something going for it was the client software, which I had diligently been working on and making incremental changes for the positive despite all the chaos going on around me.
The results of the overhaul were dramatic. The company as a whole ended up with half the staff, going from 40 to 20 people (a lot of the people in that cut were interns who did a lot of administrative grunt work or contractors who had been hired on mainly as ad-hoc employees rather than for specific contractor tasks) and we were easily twice as productive, taking half the time to do many of the same activities before I had take over as director.
We also worked far fewer hours, going from 50 hours or more a week (as is typical for poorly run software companies) down to a far more manageable 30 to 35 hours a week.
At our peak productivity, the software team was pretty much ready for any new client work that came our way; we could release customized variations of our base product in just a few short hours and the team was looking for more work to do; on top of all that we still had time to develop new apps on new platforms. We had the time, we weren’t stressed out, and the schedule allowed for it. More than anything during, and especially at the the end of this two year project, the company was ready to jump up to the next level, grow radically, and do it a smooth, controlled, and predictable manner.
Sadly, that was not to happen. We had transitioned from a tumultuous, chaotic organization that was bleeding cash to one that was running just smoothly enough to be making just enough of a profit that we could finally — finally! — hire more staff, truly upgrade our systems, and most importantly, start marketing to a broader audience with new line of products.
We were stymied and then eventually shut down by our own owners.
The company was owned by an investing group who, as it turns out, engaged in less than ethical financial behaviors. Investor fraud brought down not only the company I was director of software engineering for, but seven other startups as well. We were the last to fall, because we were the most productive, and as word had it, also the only profitable business of the eight total.
All the work we had done to pull ourselves out of the muck and pave ourselves a smooth road (a short road, granted but at least a smooth road) so that we could comfortably take on the next grand challenge… that never came.
For all of that, not unsurprisingly, lessons learned were abundant. By the end of all that work, I had five years of worth of deep experiences in turning a startup around, on top of another I had already another seven or so years of working for much larger companies, yet doing very similar “turn around” work. With all of that, I had the time and experience to gather a lot of ideas and theories about how to make software driven companies more productive.
The one major take away I’ve observed (before and after my startup story): it doesn’t seem to matter the size of the company; large or small, businesses often seem to have inherent habits to sabotage their own efforts to move towards productivity. Despite all of the books, research papers, productivity tips, process improvement gurus, and host of highly paid, yet ineffective, best practice business consultants that those companies go through the effort of hiring, business self-sabotage occurs.
From my decades of experience, I chalk a lot of self-sabotage up to a few small things:
- Over-complication or over-simplification of systems
- Not willing to spend time, simply remaining in fire-fighting mode
- Lack of transparency throughout
And so ends this part of the story. How my team and I overcame these issues is for another post! More details (as they become available) here: https://kecskes.net/projectshare.
Part 2 is here: https://medium.com/@adam.kecskes/dashed-utopia-pt2-4c7e25a3be85
This story is part of a book I attempted to write in regards to my experiences in project operations and software development. Instead of just sitting on the 41K words I’ve written (not including the probably 100K words of just brainstorming), I thought I’d share fragments instead. #projectshare
