Through the Looking Glass (Part III)

And into YCombinator

This was originally a much larger piece regarding our experience as a team working under the YCombinator program, but has been slimmed down. The original remains as a point of reference, but some significant aspects, and personal elements, are now no longer part of this three-piece article. Part II can be found here.

After 6-weeks working 18-hour days, 7-days a week in Mountain View at YCombinator, I landed in the UK a week after our designer, Gabi. In that time Ravi (our core developer) and I had focused on solidifying authentication mechanisms and launching the company web site. The site was untested, but it was a distraction and a low priority; we needed to focus any user interface time on the product, and not on spending any more time cannibalizing our backlog with web site improvements.

Our recruitment efforts were not delivering anything useful, mostly due to the lack of time I had to speak to potential candidates. It was a sporadic effort at best. The relaxed 3-month timeline had changed with the project requirements to become a frantic catch-up, and we simultaneously lacked resources and the time to find any.

We’d spent evenings with other YCombinator alumni, discussing different projects, and my concerns about the immaturity of our concept was validated; we were in an uncommon group of YCombinator applicants with no product on day-1 of the program. In fact, most other startups already had paying customers before they began the program, which is exactly where I had suggested we should have been before I committed to the project.

The time in the UK flew by, and I was unable to focus any effort on the project as I traveled across the country to attend meetings and personal events. By the time we arrived back in at the studio in Helsinki Gabi and I were keen to be back to work, but although we were accustomed to working across timezones, it seemed not everyone in the team was.

Each “morning” standup was now in our late evening, meaning we were discussing our goals for the day, and then stopping work, where-as the team in Mountain View were just waking up and warming up. When we awoke, we’d find a huge backlog of messages and a complete misfire of tasks. We’d then spend the day working on our tasks, before attending the standup and finding we’d also misfired in respect to what the team in Silicon Valley were expecting, based on new discussions with prospective investors and clients. We were all on separate tasks, but as a team we needed visibility of the project as a whole, and that wasn’t happening. People began making excuses not to attend the stand-ups, but I pushed them ahead with whoever was available regardless.

The user stories that should have been living requirements, were being abandoned. Ravi, unfamiliar with agile processes, was entirely technology focused, with no understanding of the product at all. The team in Mountain View did not seem to be bonding as closely as they were before we’d left, and the communication was severely suffering, with Pete and Ravi a desk apart, and entirely disconnected, and Dwayne spending all of his time reverse engineering open source code for his proprietary DLT platform in isolation.

At one point, to try and push for another client demonstration, I worked until 04:00 the next morning to pull the project together, but it became evident that the lack of communication had caused a divergence in conceptual design and implementation; the services and the UI were entirely different products now. At just after 04:00, with my flight back to San Francisco looming, I needed to stop the work, and concede defeat. I was looking forward to being back on the ground with the team where I could begin to fix the cracks that had appeared in Silicon Valley.

When I arrived, Pete was flying to the UK. I didn’t unpack, and I didn’t pause. I walked into the house, pulled up a seat beside Ravi, and spent the rest of the evening trying to get us back in synchronization. We had another demonstration to produce over the next few days, and rather than focusing on a sustainable workflow, we were now battling for these demonstrations, diverting attention from any form of stability or quality, and simply hacking together what was remaining. It was destructive to what had been put in place before I left, and frustrating to see the chaos that now existed in the team.

Fixing the Workflow

There were three distinct issues with the current product. Firstly, it did not align with the user stories we’d written over a month earlier. In fact, none of the user stories had been referred to. This meant the code did not align with the business view of the product, and significant features were missing. Secondly, the code did not align with my design concept. I had struggled to find the time to lay this out clearly, with recruitment, fundamentals, and code taking my time, and so I was handing over the technical design piecemeal, verbally. It was unsurprising that the code had diverged so far from that. Thirdly, it was way behind where it needed to be, and seemed to be going backwards as each day would produce a refocus on a different part of the product due to requests from clients and investors.

I had chosen the Rust programming language as the primary building tool for the product. It was partially experimental; I’d used it internally at the studio for a few components which needed to extract extra performance from the system, but had chosen other languages for the majority of the business logic for faster development times. I felt, with maturing third-party components, and a Rust-focused developer, we could utilize the language for a lot more on this project. We decided to spend two more days pushing the stack forward so I could analyze how much progress we were making, and whether the stack was the issue.

I analyzed the code repositories and the kanban boards for updates to see any patterns that could help me re-think the team workflow. The boards were abandoned by everyone except myself, so that was the first fix; I pushed the team to begin using the user stories again. After a few days, user stories were the primary source of work, and of our daily objectives.

Secondly, the first two hours of every day were unproductive, so I pushed in the mornings to see demonstratible changes. As a polar opposite, Sunday evenings were the most productive; it seemed the team were panicking and pushing harder just before our Monday retrospectives, and subsequent Tuesday demonstrations. Using user stories as our daily objectives would fix this by keeping us focused on tangible improvements.

After two days trying to finish the core Rust work, we were still behind. Ravi worked 48-hours straight, and the code was finally looking complete, but we now needed to align it with the diverging front-end application. Another demonstration went by, unsuccessfully, and Dwayne — an outside DLT service provider on the project — and Pete, our CEO, were coming back from these meetings increasingly frustrated. Equally, having identified the issues, made fixes, and seen the product approaching maturity, I was frustrated that our technical achievements were invisible and this was causing the team to split into hostile camps, with a breakdown in trust and confidence.

The Collapse

In the next 2 days Dwayne was intending to take the product he hadn’t touched in any way to be demonstrated to some of the YC folk in an effort to regain some confidence that we were capable of delivering. We pushed hard to get the code into the right state, but the quality in the end user experience was vastly lacking. It was capable as a demo product, but the user interface needed work for scaling large numbers of concurrent users in production. We delivered with 20-minutes to spare, messaged Dwayne, and sat back to gather our breath. We’d worked hard, and I’d even worked 48 hours straight, without a break; we were much closer with a few days left before it would be a workable product. We needed that time to inhale, before the inevitable final push.

The demo never happened. Dwayne left the house, then 20-minutes later he came back furious. He said it was “pointless” and there’s no point demoing a product that doesn’t exist. I asked if he’d used what we had deployed, and he hadn’t even looked. He hadn’t checked his messages. He had simply called off the meeting. I was angry at this point as the decision came without any due diligence on where we were at. It felt like internal sabotage, and I stormed out to get some time to unwind. Everyone else went to catch up on sleep.

I took a few hours off of work, and decided to quit the project, ending my tenure at the end of the YCombinator program. I wrote my notice of resignation, keeping it to myself, and then went back to work to finish the project. It was untenable to work in a project I was seemingly unable to control and where YCombinator were having the final say in every step we made, causing dysfunction and division within the team.

The Fallout

The CEO, Pete, soon arrived back, and we had the majority of the product ready. We had focused for the remaining week on filling the gaps between the rough product, and the user stories, with a few remaining. We were now moving so quickly, we were close to delivering the file storage solution, and the kanban board. We just needed a smoother, more efficient messaging user experience. By the time the next Demo Day arrived, we were 4-hours away from dropping the new product into a new service mesh, having re-written the user experience and begun integrating with a new service layer.

The code actually looked good, the product was efficient, reasonably secure, scalable, and production ready. It finally aligned with the ambitious promises Pete had been making to customers. Unfortunately that was no longer enough. The team was disbanded in the backyard, with Dwayne and Pete remaining on-board, and the rest of us moving on. As I’d already decided to leave, I was relaxed. Angry, but unfazed. I was disappointed that my designer, Gabi, would not remain to see her hard work delivered.

As a team we worked from various coffee shops for the rest of the week. The house no longer felt hospitable and we were still buzzing from the quality of the product we’d built, even if the code was sitting, untouched now. Ravi diligently documented his code for the “next developers”. I finished off improving the user experience to be smoother and more memory efficient during conversations, and Gabi worked with Pete to redesign the site again to imitate Slack’s official web site.

Our site was beautiful, professional, modern, and designed with accessibility and portability in mind. Pete, on advice from YC, had now decided that we needed to copy Slack’s more playful website instead. Gabi was upset that her work had gone from something to be proud of, to something that was a clone of another company’s brand. She did her work, continuing the long nights to change every detail, and delivered what was asked for, filled with regret that she had taken on the project at all.

I was asked to migrate the entire front-end to run on Dwayne’s proprietary DLT product, reducing the company’s usable IP to nothing. Despite 5-years in the making, the DLT product had no usable API I could use, so it wasn’t until Thursday of my final week that I was given a single sample of JSON to reverse engineer into an API client. Unsurprisingly it was never completed.

In the previous 4 weeks, Dwayne had been extracting what he could from open source JavaScript cryptocurrency projects to build his own Web-based encryption library, but it was still incomplete by the time my final day came.

Applied Learnings

After our term was over, Gabi and I moved onto our own projects, taking some of the advancements we’d made through the YC program and applying them back into our original project. We moved to focus on our original artificial intelligence product, built with partial usage of Hyperledger Fabric again, delivering a new product in the first two weeks since leaving the YC program. We spent evenings with Ravi watching films at the local cinema, visiting NASA’s Ames propulsion lab, as well as the new Apple campus, San Francisco, and San Jose.

Ravi applied all of his new knowledge into his own web site, using Rust to build a web application engine on a service cluster. Soon afterwards we began working together again on an official messaging bot SDK in Rust for a third-party secure product, this time under the studio, and built in a single week by Ravi.

Within a few weeks of leaving the house, the CEO had become the CEO of Dwayne’s third-party propriety DLT company, and listed the original company as “acquired”, my shares non-existent after I left. Access to the source code of the product automatically expired for the team, with zero attempts to access it since we left, and myself as the sole possessor.

My Lessons / My Mistakes

So, after 3-months of hard work from the entire team, we learned a lot. I’d rather avoid focusing on the mistakes of others. The articles have enough bias as-is, and my own introspective analysis covers many of the areas I feel could have made a difference.

• I should not have accepted joining the YCombinator program with no product and no customers. I knew this was premature and risky, and we had no validation of the concept. Having a product, and customers, provides validation that would mean a stronger reason for sticking to our original ideas, with minor pivots during the program, backed by data.
• We should have delivered the monolithic application first, and then scaled, but our pre-YC marketing material backed us into a corner to deliver everything from day-1.
• I should have recruited an experienced developer in the first two weeks. One additional resource would have provided me additional time to document some of the system design for the team early on.
• I should have rejected the proprietary DLT product before I began. It provided no benefits, and seemed to be more of an influence on our product than it should have been. Often we’d find it lacked in many areas and we were being used to identify gaps, rather than building a simpler, more suitable core internally.
• I should have used Rust slightly less in some areas, until the product was ready and stable for customers. It was a perfect fit for our product, but provided a few challenges in networking concurrency that slowed us down. Our other core languages, Go and Swift, would have been quicker to develop with, and although I knew this, I was distracted by seeing the results from increasing our use of Rust instead.
• I should have blocked further development of the company web site early on. It was a distraction and consumed too much time. We had a temporary holding page that would have sufficed.
• I should have insisted on attending the meetings at YCombinator. I lost a lot of control by not being present when decisions were being made, and allowing a non-involved developer to represent our technical work.
• I should not have taken on a project I had very little interest in technically. I’m a technologist at heart, and that’s what drives me. I want to build products I’d like to use, and this wasn’t one.