My Journey, a memoir of a once troubled software engineer (5/6)

I was back to an IC (Individual Contributor) role when I conceived the idea that later became CUI (Critical User Interaction) attribution, one of my two ten-year visions. I was a sole engineer in the Customer Engagement team for infrastructure products, with everyone else being program managers. One of our missions was to identify the end-user products that depended on our infrastructure directly or indirectly. We tackled this problem by gathering all the teams that we thought were involved between a certain end-user product and the infrastructure, and putting the end-to-end architecture diagram altogether. The team achieved some unprecedented successes. Nevertheless, it was a very expensive operation.

What if every click from users is tagged with the user’s intent, i.e. Critical User Interaction, such as “watching a video on YouTube”? Then, every server receiving the request would instantly know what end-user products depend on them. If we had that, what else could we do with it, and how much could this revolutionize our lives?

I first thought about how much time it would take us to get to this happy destination of CUI attribution. There was no way that I could do this within one year. Five years? Better, but still probably not. I felt I likely will need more time to fully tap the potential of the idea. What about ten years? That just might work. That’s how CUI attribution became a “ten-year” vision.

Once I allocated ten years, I needed rough high-level milestones. I relied on Technology adoption life cycle from “Crossing the Chasm” by Geoffrey Moore. It describes the adoption of a new product or innovation in five phases depending on the types of target customer segmentations in each phase: (1) Innovators, (2) Early adopters, (3) Early majority, (4) Late majority, and (5) Laggards. Ten years and five phases. That meant two years per phase.

We start with zero customers. In each phase, we get more partners that we could build products with, and more customers that we could test our ideas and demonstrate the value with. We share the findings and values with more people to acquire more partners and customers. And we repeat. That was the little plan that I had.

Year 1: Starting with nothing

At the beginning, I had nothing but an idea; no engineering team to pursue the idea together. No customer who expressed interest in the idea. Just a proposal. I shared the proposal with a few familiar faces. There were a few technical concerns, but they were not huge issues at the moment. The main concern was that I needed the end-user product teams to tag the requests. It’s a simple task, but however simple it might be, asking other teams to do something for you isn't always easy. And for that reason, some even foresaw that this idea was going to be a non-starter.

Nervously I shared the proposal with a few end-user product teams. Luckily soon I found that the end-user product teams were suffering from a problem that might benefit from this idea too. Infrastructure teams were wondering the requests from which end-user product they just failed. The product teams were wondering which infrastructure far away just started failing their requests. As I was speaking to more people, I also learned that some other teams had similar ideas that they were pursuing. Some even had a prototype. We quickly aligned our interest and agreed to join forces.

We decided to position ourselves as a cross-product working group for all the people pursuing this line of thoughts, now known as CUI (Critical User Interaction) attribution. The product teams working on the existing efforts became our first partners and customers at the same time. Despite us all being 20%ers, this allowed us to quickly prototype a few simple tools and test the idea leveraging existing prototypes.

As a cross-product working group that embraced multiple similar existing efforts, we intentionally focused on the alignment across multiple product teams and standards development. That way we differentiated the working group from existing or even future similar efforts, and at the same time garnered bargaining power to other central stakeholders, representing all the parties of the working group in unison.

By the end of year 1, we had a group of 20%ers working on CUI attribution in the form of a working group. We had a few partners and customers that were working with us. We started making our names for ourselves in the small corner of Google.

Year 2: Shaky success

We continued producing more promising and interesting results and sought many potential application areas. We shared the results with more folks via documents and presentations. Sometimes word of mouth brought us more customers. Sometimes we proactively reached out to more product teams, looking for customers who were willing to explore the future with us. More customers and collaborators joined us. We appeared to be successful.

On the other hand, concerns were looming. We had so many “potentials”, but none proved to be of business value yet. We had many “prototypes”, but we didn’t have any dependable product, given that we were all only 20%ers. The critical question followed: is this the right time to explore these potentials? We felt desperate.

As we were sharing our successes and concerns with senior folks, one person noted how much our working group was like a start-up. We had a great idea, built prototypes looking promising. Continuing the analogy of a start-up, he said, maybe it was time for a Series A funding. His observation struck us like lightning.

Later he connected us with someone that’s close to a VP, who he thought might be interested in our work. A few months later, we were finally presenting our work in front of the VP, sharing all the potential values. At the end of the presentation, the VP mentioned that he was able to poke holes in most of the potential values, but he did find at least one of them close to the real business value.

A month or two later, the VP decided that the official CUI attribution “team” be formed with 3 dedicated headcounts as part of an organization responsible for Google’s monitoring. Like that, our lifeline was extended.

Year 3: Transitioning to establishment

Becoming part of the establishment as a formal team was definitely the right direction. No more concerned looks on people when we described the amazing future that we were building but that we were only a group of 20%ers.

At the same time, the transition required some changes. As I started a new team with the official funding, I departed from all volunteer 20%ers. Despite having 2 additional headcounts to hire engineers beside me, I was once again the sole engineer till those roles were filled.

Only after we hired two engineers dedicated for CUI attribution, things started moving again. Soon, we demonstrated a product feasibility of our soon-to-be first business value: automated triage of incidents on distributed systems. This led us to polish our north star into a more concrete vision as well - reducing the majority of huge and major outages in Google by automatically triaging outages within the next five years.

Three years in, we now had a concrete vision. We were part of a bigger organization whose mission is aligned. And most importantly I now had two other engineers who believed in the vision and pursued the mission 100% time. It finally felt like we were ready to tackle this vision of CUI attribution.

Year 4: Crossing the chasm

Translating the feasibility study into features of products for mainstream users required support from the larger monitoring group beyond the CUI attribution team. However, the cold truth was that CUI attribution’s existing customer accounts for only a tiny fraction of Google, and the monitoring organization had a duty to the entire Google. For CUI attribution, the chasm manifested as a chicken-and-egg problem between the acquisition of mainstream users and the acquisition of investment needed for productization.

Asking the monitoring group to reduce existing commitment to make a room for CUI attribution for future value seemed unpalatable. The only option left then was to somehow magically make the majority of Google as serviceable customers of CUI attribution to make the needed investment more palatable.

For CUI attribution, the predicament of increasing the serviceable customer was that product teams had to tag their requests. What we realized at that point was that most teams struggled to define the critical user interactions (CUIs) for their products, not to tag CUIs, slowing down the adoption.

What if we could automatically approximate CUI with the API (Application Programming Interface) of the frontend? This would lower the cost of adoption for our users down to zero. Users could taste the value of CUI attribution without putting any effort upfront. This is exactly what we just prepared. We’re now planning a rollout of this automatic CUI tagging later this year. And with that, we are ready to cross the chasm and enter the mainstream market.

Year 5+: The mainstream

Looking back the journey of CUI attribution so far, I see so many challenges that could have stopped us. Yet somehow we survived and continued the vision to date.

I’m pretty sure there will be even more challenges on our way to the future. In fact, we can already feel another point of friction as we enter the mainstream. The rapid growth in the user base is likely to accompany a lot of user feature requests or bug reports. The small team size of CUI attribution will fail us carrying all the responsibilities of prototyping, productization, productionizing, and customer support. So we already requested Series B funding.

Now that we are hardened enough through so many obstacles together as a team, I feel that we can overcome whatever obstacles are thrown our way.