Looking Back to Look Forward

We can learn an awful lot about ourselves, personally and professionally, when we take a moment to reflect on the past. Our past experiences, as meandering or unexpected as they may be, are woven together into the fabric of our current reality and inform our future goals. The following narrative is the result of personal reflection on my career up to this point. I found it immensely valuable to capture these thoughts coherently from the perspective of my current self — it was therapeutic, in a way, to learn from the bad and to celebrate the good, through a healthy, productive medium: professional narrative.

I encourage anyone out there who might be suffering a bit of Imposter Syndrome, or anyone who just wants to reap the benefits of professional reflection, to set aside some time for a bit of writing. Remember, you can craft your past self into the identity that makes sense through the lens of today. Sharing your story is a way to express your favorite self to the world. You choose the dimensions, the details, the settings, and the angle. You’re in control of your narrative when you choose to write your own story.

Despite the magnetism of Design as a profession, I’ve only ever held formal roles as a Software Engineer — writing code always seemed the most pragmatic way to imbue interfaces with the thoughtful attention to detail sorely lacking in most enterprise products. As an engineer, my goal was to bring consumer-grade experiences to everyone, to the tools people use every day to do their jobs effectively.

Over the past 4+ years, I’ve built tools for Security Admins and DevOps Engineers, Sales Reps and Marketers, and older adults looking to manage their health and wellness. From these experiences I can confidently conclude that “consumer-grade” is no longer a productive catch-all for “good design”. Good design is user-dependent and all users are unique. While population averages serve as a useful heuristic for targeting the right audience, the variety of ways in which people learn, use, and master products taught me that a granular appreciation of user goals, proficiencies, and motivations leads to better products for everyone.

It took me perhaps longer than I’d have liked to arrive there. After all, I was officially an “Engineer”. While design work was always top-of-mind, interwoven into my daily activities, and part of my identity (often why I was hired in the first place), I never found the opportunity to go as deep on design as I’d intended.

Instead, I learned a lot about how to build products by writing code. I learned about the tradeoffs and nuances of abstracting solutions too early or late. I learned new programming languages, libraries, patterns, and so on. I worked across the stack to learn how systems spoke to one another, to understand their limitations, and to make informed proposals about how we could leverage what we had to better serve the user. I learned how to make my tools work for me and my team, boosting our overall productivity. I found that some tools reward mastery while others punish ignorance.

Most recently, I learned how to be an absolute code-machine who could ship a working tracer-bullet in an afternoon. I learned that perfect is the enemy of done and that shipping incremental value to production, even if it’s gated, is an insanely valuable way to build products and learn from real users. I learned to instrument feature usage and performance and to collect insights from what we’d built to make data-driven decisions. I learned what it takes to be an effective technical leader, how to manage expectations across Sales, Customer Success, Product, and how to put the customer at the center of everything you do.

While most of my time was spent building, I still found ways to invest in design. I always felt a responsibility to do right by the user — even if I wasn’t in a Design role. Engineering has always been an uphill journey with lots of opportunity to grow, but it has never been what I love to do. Design, in all of its beautifully unexpected forms, has always been what drives me to build great products.

In the early years, I focused on aesthetic — I thought users valued modern design systems, crisp typography, and muted tones above all. As an early hire at my first startup, I generated visual concepts, color palettes, and component systems in Sketch and proudly showed them off to the team. I quickly earned their trust. Soon I was bringing these concepts to life through code. It was a success — we routinely heard that our product looked nothing like the dated Cisco software our customers were used to. There was hype and energy around the product; not only for customers, but internally among the team building the product. I hadn’t expected this type of reaction, but it taught me that flashy design can both motivate a team and inspire the customer. Unfortunately, it reinforced my misguided assumption that good aesthetic is good design.

Initial concept work I shared with the team

Misguided assumptions aside, I managed to make the most of the situation and found creative and productive ways to push for high standards. With front-end engineering talent distributed among autonomous engineering teams, I founded the UX Guild — a space for front-end engineers and designers to give and receive feedback, align around cross-team initiatives, and produce a shared component library. The guild increased cross-functional participation in the design process, contributing to design literacy across the team.

On a personal level, I convinced business leaders that I had something worthwhile to contribute from a design perspective. They appreciated that I not only pushed pixels, but also took the time to sketch out wireframes and workflows illustrating user journeys. This trust eventually enabled me to work directly with David Sward, Sr. Director of UX at Cisco.

With David, I was able to go deep on service-design discussions about how we might enable a touchless experience when configuring new devices for the first time. He helped me balance the technical implications while pushing for the best possible experience, something I hadn’t allowed myself to think about in the face of the technical decisions I was constantly making. It was refreshing and gave me a new perspective that I could think beyond the limits imposed by existing solutions. I wish I’d found more time to collaborate with David.

Reflecting on my time building Cisco Defense Orchestrator (wow, that name…), I realize that I was missing critical context needed to do my job effectively — I just didn’t know it at the time. In my sixteen months on the team, I’d spoken to one user, exactly one time. I relied entirely on occasional context from a couple of ex-security admins and business leaders to construct my interpretation of what users were trying to accomplish with our software. That’s a pretty big leap for someone whose only previous experience was building an app for older adults to manage their health and wellness — users I could observe and understand more completely. The goals, competencies, and motivations of security admins were nearly opaque to me with what little information I’d gathered. I couldn’t empathize.

In my sixteen months on the team, I’d spoken to one user, exactly one time.

I should have given more weight to the fact that we were building a product for a rigid industry with decades of existing solutions and patterns that I’d neither encountered, nor experienced, as a user. I found myself focusing on what I understood and was unable to construct a complete story for what our software enabled organizations to do: Manage network security policies from the cloud, simply and consistently. Looking back, I can pretty succinctly describe the core features:

1. Device configuration and provisioning
2. Policy analysis and remediation
3. Stage, deploy, and audit policy changes

It hadn’t occurred to me, however to ask users how these features might benefit their workflow. I never observed an admin installing a new device into a rack and configuring it for the first time. I never fully understood why an organization might need to identify out-of-band changes. Sure, I knew there was a ticket queue they worked through, and that auditing and compliance were important, but I never really listened to a user describe the internal rules, rituals, and hacks they used to govern changes. I didn’t understand the window in which changes were staged and officially rolled out. Had I given these considerations more attention, we might have built a tool that more closely aligned with users’ workflows and preferences.

Without that depth of understanding, we couldn’t have possibly built a lovable tool. Instead, we built a money-saving solution that’s easy to copy. Our moat was vendor lock-in and the Cisco sales force. There was much left to be desired, and only after leaving did I realize our shortsightedness. From a design perspective, I hadn’t yet reached a level of maturity necessary to look beyond flashy visuals. Fortunately, these reflections enabled me to approach my next role with a more critical lens.

In the winter of 2016, I learned about a fast-growing startup, CloudHealth Technologies. CloudHealth allows organizations to analyze and manage multi-cloud cost, usage, security, and performance in one place. Contrary to the name, it has nothing to do with healthcare (even though recruiters love message me to this day about my background in healthcare). The brainchild of founder and CTO, Joe Kinsella, CloudHealth was built to save organizations money from the beginning. The story goes that Joe managed to sell the product before it was even built and then scrambled to build it that night!

Searching for a “cool” place that could further launch my career, CloudHealth felt like the right fit in terms of culture, goals, and credentials. I’d politely declined a generous offer from CarGurus (which recently IPO’d well above their forecast — congrats!) and moved forward with CloudHealth (which was recently acquired by VMware — congrats!). It was at CloudHealth where I refined my product sense and learned to articulate a coherent story around the tools I was building.

Here’s a brief overview of the benefits afforded by the CloudHealth ecosystem:

1. Cloud Visibility (Usage Reporting, Performance Management, Migration Assessment)
2. Cloud Cost Management (Reserved Instances Optimizer, Rightsizing, Cost Allocation, Budget Reporting)
3. Cloud Governance (Violation Alerts, Policy Management, Cloud Automation)

It’s a pretty comprehensive list, and I’m finally confident diving deep on all of these concepts. I was lucky enough to build a few of them, and in doing so, gained exposure to much of the product surface area. Recognizing the massive opportunity to transform the way businesses tame cloud infrastructure costs, I realized that this was not the time to focus on aesthetics. I learned that users cared about accuracy above all else. This was a tool they needed to trust, and if we couldn’t deliver that, they would build their own solution in-house.

Why did accuracy matter? Why was trust so important? To understand, we’ll need a brief overview of why customers buy CloudHealth.

CloudHealth’s claim to fame is that customers save on average 30–40% on monthly cloud spend. Businesses rely on CloudHealth to report on cloud infrastructure costs across business functions at a granular level — these reports impact budget allocation and provide insight into organizational compliance. In short, they identify good and bad actors and make continuous recommendations for improvement. “Good” reports might be highly optimized resources and constantly decreasing marginal costs. “Bad” reports show underutilized resources and ballooning costs. Either way, insights are gleaned — the cost rollup provides strategic guidance to operations managers, and financial decisions are made based on the tool’s recommendations.

With that in mind, accuracy and trust is important to the user since the numbers can either make them look like a hero or a criminal to their organization. If CloudHealth provides poor recommendations on which computing instances to reserve or which resources to downsize, a user following these recommendations may damage their organizations’ reputation by degrading overall performance. If they follow conservative recommendations, budget is wasted and they appear to be a cost-bottleneck.

Fortunately, my time as an Engineer at CloudHealth got me closer to these problems and helped me make sense of these otherwise arcane business concepts. I gained exposure to complex systems such as scheduled background tasks and cloud automation. How did CloudHealth even report on infrastructure cost? Where were these numbers coming from?

I learned that CloudHealth consumes monthly and annual AWS, Azure, and GCP billing statements, parses the line-items, and allocates costs to respective product families currently available in CloudHealth. Because of technical constraints, these allocations are performed nightly, giving users a look at history accurate to yesterday. Further, reports come in varying resolution (hourly, daily, and monthly) and may be allocated categorically (e.g. by business function) — constructing these reports requires generating, processing, and summarizing OLAP cubes — multidimensional databases that serve as efficient data-warehouses that may be efficiently queried on-demand.

With this knowledge, I learned that our UI needed to be able to answer questions about the data at a granular level. We needed to show when the data was collected and analyzed, whether it was stale, and when it would be refreshed. We needed to provide a way for users to manually trigger a refresh to get the most up-to-date data and communicate how long it would take to process.

If we made a claim about cost allocation, could we point to the billing line-items and link directly to the AWS instances in question? Sometimes we couldn’t — Amazon made this challenging and some costs had to be calculated indirectly because there were no unique ARNs (Amazon Resource Names) connecting the line-items to real resources. Education here was critical — it meant the difference between a user who can appreciate vendor-imposed limitations versus a user who views the incomplete data as a product failure.

Education here was critical — it meant the difference between a user who can appreciate vendor-imposed limitations versus a user who views the incomplete data as a product failure.

CloudHealth introduced organizations to new paradigms in reporting on their cloud infrastructure by providing tools that demonstrate the benefits of resource-level tagging. “Perspectives” were introduced as a higher-order abstraction that enable customers to organize, view, and report on infrastructure across business groups. By tagging infrastructure, this grouping is automatic and effortless. Without tags, users are presented with a massive “Unallocated Resources” bucket — a large unallocated resources bucket means reporting will be mostly useless. The goal is to shrink the bucket by tagging infrastructure and allocating those tags to groups. It’s a smart way to incentivize users to invest in tagging. By doing so, CloudHealth can generate insightful reports that help organizations drive budgeting decisions.

Anticipating potential pitfalls, CloudHealth provided a rule-builder that allows users to allocate costs to specific perspective groups equitably for unallocated resources. This anticipatory design puts users in control of unknown costs instead of trying to allocate according to some magical, behind-the-scenes rules. The decision was offloaded to the user as a courtesy and acknowledgement of differences in organizational structure and budgetary requirements.

CloudHealth is as deep as it is wide, so I’ll stop there for now. Hopefully the narrative above provides a useful look into some of the problems we were solving and illustrates what matters most to users. Contrary to my strengths in producing flashy design, aesthetic was the least important dimension for CloudHealth and resulted in a major shift in my thinking. Trust was #1. Feature coverage was a close #2. Beyond that, learnability was important, but sorely lacking in the product. For that, the organization looked to service-design.

To find success with the platform, CloudHealth customers constantly engaged with Customer Success and Support teams, attended hands-on training courses and webinars, and consumed educational blog-posts and content-marketing materials. I learned about the importance of these functions for making users successful when adopting such a complex product. This wasn’t a tool users could just dive into and start saving money. These ancillary organizations helped customers identify opportunities for cost-savings, offered best-practices for managing infrastructure, and taught them how to fish for themselves. CloudHealth was not just a product — it was a service-provider that advised businesses on cost-optimization and cloud-migration strategies and worked to make customers independently successful.

CloudHealth was not just a product — it was a service-provider that advised businesses on cost-optimization and cloud-migration strategies and worked to make customers independently successful.

This was my first career encounter with effective service-design, but I didn’t realize it at the time. When I was an Engineer at CloudHealth, I ignorantly viewed these supporting layers as lines of defense against a confusing, bloated product. It hadn’t occurred to me that people in the organization really did care about the user — this care was expressed in ways I’d never encountered and couldn’t understand until I’d spent more time building products in enterprise SaaS businesses.

While CloudHealth services and supporting organizations were impressive, there was still massive opportunity to make the product easier to understand and navigate. Up to this point, distrust and animosity between Design and Engineering had contributed to some pretty heinous user-experiences. Left unchecked, the toxic relationship may have festered beyond repair.

So we decided to take action. I was lucky enough to work with the most hard-working, empathetic, and thoughtful Engineer I’d ever met. Devin had been my onboarding-buddy when I started at CloudHealth and we’d since worked together on some challenging engineering projects. We shared a deep interest in all things design and he was my go-to foodie. We aligned politically, discussed diversity and inclusion efforts, and vented to one another about whatever ignorance we’d experienced that day. He was always the example of what great looks like. Simply put, Devin raises the bar across every dimension.

So Devin and I got together, along with then-newly hired Sanjana — an energetic product designer overflowing with positivity and fresh perspectives — to brainstorm how we might improve CloudHealth’s relationship with Design. I remember Devin jesting about the radical concept of “the Pencil at CloudHealth” after having been looked at sideways by an engineer who questioned why he was writing things down on a giant Post-it easel pad and planting pencils and scrap paper across the office.

Without designers embedded into engineering team, the otherness was palpable. Engineers couldn’t trust Designers to make timely, informed recommendations, and Designers couldn’t get their proposals implemented by engineers. There was a large bridge to gap, so we chose to start small: we’d invite everyone across all of CloudHealth to participate in brainstorming sessions where they’d have a judgement-free opportunity to post their perspectives around which principles mattered most when building products for CloudHealth customers and users. Through this exercise, we’d distill down common themes into a set of shared Design Principles which would serve as a basis for discussion between designers and engineers when making product decisions.

The exercise was a success. Physical cards were printed and shared with the whole Product team. It was the impetus needed to get the team talking to one another and engaging in healthy design discussions. Around the same time, Devin & co. had successfully shipped a product designed and built in partnership with one of our largest customers. It was a valuable precedent that elevated the voice of the user as a first-class citizen, serving as a clear example of how designers and engineers can work together productively to build something amazing.

Around that time, I’d been approached with a few new opportunities that aligned more closely with the types of products I wanted to be building. CloudHealth was retrospectively an amazing learning experience, but I was ready to build something where the fabled “consumer-grade experience” was within reach.

December of 2017, I interviewed with two amazing teams that both blew me away: Appcues and Drift. The positive energy, product excellence, and opportunity to be a part of either of these teams was a rare privilege.

The team at Appcues genuinely felt like a family. Everyone was extremely pleasant and I enjoyed talking with all of them. They were smart, friendly, and mission-driven. I ended the day interviewing at Appcues by having a conversation with Jonathan Kim, founder and CEO. I admired his approach and was hopeful for an offer — I was inspired by what they’d done so far.

Somehow, a day later, I found myself in the 7th floor of Copley Place — a luxury shopping mall and host to online furniture giant, Wayfair. Drift was on the 7th floor. Walking through the doors, I didn’t know what to expect, other than lots of energy. Nothing could have prepared me for the blasting Sonos, ringing gong, banana suit, and general outrageousness of what I’d experience that day. Inside, I spoke with designers, engineers, and Elias — the founder and CTO of Drift. After a quick hour or so, I shook Elias’s hand affirming my decision. Maybe it was the energy I’d encountered on the way in. Maybe it was that I’d watched Elias announce to the entire team that he was giving everyone the week off for hitting some ridiculous goal. Most likely, however, was the fact that they’d built an amazing brand and product, and I wanted to be a part of it. They were building a movement, and changing the way businesses buy from businesses. I decided to give Drift a shot as a Sr. Software Engineer and politely declined the offer from Appcues.

Drift is the first place I’ve worked where Engineers, Designers, and PMs love working together and genuinely admire one another. An egoless organization, we thrive on feedback, coach each other daily, and know that everyone is here to build an enduring company with a team of self-aware, respectful, fully formed adults. Everyone is constantly raising the bar and setting the new example of what good looks like. We talk about how we can “10x” designs, engineering solutions, and product experiences. It’s ridiculously energizing and refreshing. You can’t help but come to work every morning excited to crush through your big rocks for the week.

It’s ridiculously energizing and refreshing. You can’t help but come to work every morning excited to crush through your big rocks for the week.

How did we get here? What makes the culture at Drift so palpably electrifying? It starts with the founders. Serial co-founders David Cancel (CEO) and Elias Torres (CTO) seeded the culture for customer-centricity, personal and professional growth, and no ego. Having been through multiple successful exits and acquisitions since they first met, DC and ET knew what type of company they wanted to build from the start. From there, they selected the brightest minds in Boston who aligned closely with these attitudes and principles. Before long, the culture took off and there was no turning back. DC says to this day that the culture is a shared reflection of the people and values we celebrate and the attitudes we choose to tolerate.

Formally, we have Sales, Product, Marketing, Customer Success, Company Success, and Growth teams. But you’re never out of earshot of an engineer chanting “ABS! Always be selling!”. Or a CSM shouting “Always be ‘cruitin!”. While these are fun tag-lines, they’re mostly a reflection of shared values and willingness to do whatever it takes to make everyone ridiculously successful, even if it’s not in your job title. We’re all always selling, recruiting, building, marketing, and serving the customer. Look around and you see Engineers jumping on customer calls to answer a quick question or to help them go live without a second thought. This customer-centricity permeates every team and individual at Drift. As a reminder of our shared mission, we all come together every Friday at 4:00pm for “Show and Tell” to celebrate wins and reflect on what we’ve accomplished that week, even now as we soar from 100 to already 280+ Drifters in 2018 alone!

With that background on Drift’s culture, it comes as no surprise that engineers, designers, and product managers have extremely healthy relationships with one another. The mutual respect and trust among each member of the autonomous product teams is infectious and encourages you to do your best work and push for the highest standards.

For me, Drift was an opportunity to express my design fluency while learning from those who’d come before me. I quickly found ways to engage in designerly discourse during product and engineering discussions and offered valuable insights and recommendations when appropriate. Through multiple product launches, lots of code, and plenty of opinions, I’d built a reputation as a trusted product advisor, as someone who sweats the details and always raises the bar to ship the best-in-class user experience.

I learned a few things along the way, too.

From an engineering perspective, I learned to ship customer value, fast. It was my first time working with React professionally, so I also invested lots of time learning Redux, RxJS, Recompose, and other supporting libraries. Some of these were extremely challenging to wrap my head around, but ultimately unlocked more expressive ways of modeling solutions. I learned how to build Chrome Extensions, NPM Packages, micro-frontends, and public-facing Chat Widgets. I worked on a Java backend to integrate with Google Calendar. I dove into WebSockets and real-time messaging topics. I researched role-models like Slack to understand and recommend how we might build more succinct APIs. I learned to track user behavior and glean insights from data. Along the way, I was fortunate enough to have ex-PayPal and ex-Venmo technical leaders investing in my growth. It’s been a solid year as an engineer.

Along the way, I explored the expansive Drift ecosystem, saturating as much knowledge as possible and building out some pretty fun products.

From a design perspective, Drift taught me a few new tricks. Around the same time I started, Shannon Bain joined as the Director of Product Design. A sharp, experienced Designer, Shannon helped expand my design vocabulary by discussing problems and solutions at length whenever I had questions. I often consulted Shannon to help elevate and coach the Design team on how to produce lower-fidelity mockups in favor of exhaustive user-journeys. He produced some really impressive visual artifacts to illustrate the actors and systems at play for our calendaring feature (which also included a hilariously accurate avatar of himself stylized as if drawn by a Pixar artist). Inspired, I asked to see some examples of previous work where he’d attempted to eliminate assumptions between designer intent and engineering execution by modeling painstakingly detailed system diagrams. I was sold on Shannon — I wanted all of our designers to enumerate corner-cases with this level of depth while skipping the high-res back-and-forth.

While it wouldn’t happen overnight, I realized that this was permission to think differently and suggest a departure from the ways things had been done up until that point. I worked closely with Amanda Yee (@yeezy), my product design partner at the time, to eliminate assumptions and make sure we were building designs productively. Amanda had been with Drift from the start, so I obviously couldn’t just upend her process without appreciating her strengths in visual design. While we never arrived at the lo-fi diagrams I was after, Amanda doubled down her efforts and began enumerating and annotating edge-cases in her Sketch files. This was a huge step forward, and something that she carried across teams. By rendering different states within Sketch, designers were forced to think through and communicate all of the possible cases, giving engineers as sense of how to best model the interface through code. This was much closer to where I wanted us to be. Designers became invested in uncovering problems and edge-cases, and began recommending more completely specified solutions. Engineering cycles were freed up to invest in better code, more resilient systems, and, faster ships.

After some time writing code at Drift, I considered moving into a full-time design role. I’d shared my frustrations with Shannon and my then Tech Lead, Trevor (@trun), to try and make sense of what I was feeling. I knew that I was capable of shipping code and would learn a lot by continuing to do so, but I constantly felt like I wasn’t living up to the expectations I’d set for myself regarding design. Trevor counseled me to give it more time, find ways to lean into design throughout my daily activities, and suggested that I was someone with a lot to offer in terms of product sense and quality standards who would continue to be invaluable as an engineer.

I wasn’t living up to the expectations I’d set for myself regarding design.

At the same time, Shannon was in need of some engineering help. He was tasked to remediate the consistency drift (no pun intended) in our UI before things got out of control. With a centralized designer on his team working to create a component library, all he needed now was an engineer to drive adoption throughout the engineering organization. I spoke with Shannon about this on a few coffee trips. He was extremely effective at framing this as an opportunity, and that I would be a perfect candidate since he needed someone on the inside who other frontend engineers trusted and would work with. I shared that I wasn’t particularly excited about the prospects of a centralized role producing a component library. It was too constrained, too far from the customer, and not dynamic enough to hold my attention. It sounded like working at a factory, and I’m happy that I declined. Some designers and engineers love this sort of thing, but it wasn’t for me. I needed to design or own an end-to-end tool, product, or experience. Even though I didn’t join Shannon’s team, we still worked together closely; he coached me and Amanda on how to work better together and gave helpful feedback when we made design proposals.

In October 2018, Shannon left Drift to move to SF with his wife who’d just been named the new CMO of Lyft. I was sad to see him go, but appreciate what I’d learned from him, and knew he’d find another great opportunity on the west coast.

With this departure, Tim O’Brien joined as the new Director of Product Design. Tim was the opposite of Shannon, in a way. Shannon wore tight black jeans, a black t-shirt, and black rimmed glasses every day: his “prototypical designer outfit”, he joked. His hair flopped neatly across his head, overhanging the other side, partially covering the closely shaved sides. He was a healthy skeptic and humorous cynic. He practiced self-deprecation, listened to hardcore rock, and read lots of books. Tim, on the other hand, frequents a sky-blue oxford shirt and keeps his hair tighter on top. His blue eyes and big ol’ smile make him almost as lovable as a teddy bear. His low, ASMR-inducing voice is approachable, yet confident. His demeanor is overall less private: Tim bounces around from desk-to-desk to catch up with designers and carries around rectangular sticky notes and markers to quickly sketch and communicate ideas. While both Shannon and Tim are amazingly effective designers, they are very different people, with very different ways of running a Design department.

Tim’s done a great job so far. Not only did he have to step into the shoes of a skilled Director, but he also had to earn the trust of the product designers, engineers, PMs, and CEO. No easy feat, Tim managed to exceed expectations, quickly earning trust and finding new ways to move the organization forward.

Tim is a generator — he comes up with tons of ideas and creative solutions to any given problem. He recently started a weekly UX contest, complete with prizes and bragging rights for the winners. Each week, designers pair up with engineers to ship UX hit-list items to slowly chip away at our design debt and elevate the overall consistency of our product. Entries range from microcopy updates, to swapping out one-off components with their Tide counterparts, to cleaning up margins and padding on neglected views. However small, participants are encouraged to share their work for a chance to win a Tatte gift card for $8 (enough for the designer and engineer to celebrate with victory coffee). Drift loves Tatte, so this was smart move #1. Smart move #2 is that Tim creates a video each week announcing the winners. He goes through the submissions to show off the amazing work, adding witty commentary along the way. Tim knows how to tell a story — he’s a DM in D&D, after all. Finally, he reveals the winning team, overlaying crown emoji and other zany graphics onto the winners’ avatars. This weekly contest has quickly become a beloved ritual, teaching new engineers and designers that all of the little details add up to an amazing experience.

In efforts to legitimize and ramp-up Drift’s UX Research efforts, Tim, along with UX researcher, Freja Mickos, recently sent an open invitation to the entire company to come watch a usability-testing session from a remote observation room. In classic Tim form, he brought cookies and made a note about said cookies in the invitation. (There were these super soft, candy-chip ones that I binged on, hard). The goal was to increase awareness for what it was the Freja was doing by giving everyone in Product a chance to watch it happen live. Freja did an amazing job, of course, asking open-ended questions where appropriate, and more guided questions when she needed to direct the user more carefully down a path. Back in the observation room, we crammed in all of the product designers, a few PMs, and even some engineers. While the goal was to have higher engineering attendance, it was still a great start. It introduced engineers to UX Research as another tool for building better products. And it made them like Tim even more for bringing those cookies. Biggest takeaway from Drift: If you ever join an organization as a Design Director, bring treats. Funny how a few grams of sugar can motivate an entire team.

If you ever join an organization as a Design Director, bring treats.

I’m fortunate to have worked with both Shannon and Tim. They’ve demonstrated what it takes to run a healthy, successful Design organization at a fast-growing company, and equipped me with the tools I’ll need to do it myself some day.

Since October 2018, I’ve been working closely with Sr. Product Designer Akhil Dakinedi to build Drift Inbox. This inbox-inspired real-time messaging app enables the next generation of Inbound-SDRs (or Conversation Development Reps; CDRs, as we say) to chat with site visitors and qualify leads who are ready to buy now. Using an IP-enrichment provider, we’re able to enrich otherwise anonymous website traffic with detailed company profiles, including firmographics and other qualifying metadata. For visitors who provide an email address, we’re able to create a richer profile, pulling info from LinkedIn and other social platforms. With this powerful tool, CDRs can quickly qualify leads in real-time.

Recently, we’ve been focusing a lot on how to best serve high-volume customers. These are customers with heavy site-traffic, many chats, and often multiple CDRs handling chats full time. To make sure we’re solving the right problems, we’ve been spending a lot more time on customer calls watching high-volume users do their job. Through this research, we’re able to learn about all of the internal rules, hacks, and habits that govern Drift usage within a particular org. We uncover the nuances of what the user focuses on in the view. Where do they move their cursor, and what actions do they take? How frequently? Do they ever click that button? Do they even use tags? What is it about tags that they care about? Do they ever click the Company tab? How often are they sending saved replies? Are they closing conversations? Sorting them? When do they jump to the closed filter? Questions like these are quickly answered through a few quick calls with the right users.

They’re also answered indirectly through data. We’ve recently invested heavily in click-tracking and are becoming more metrics-driven. From page-load performance, to number of filter toggles per session, these data help tell a story about our product. By thinking about the data, we force ourselves to think about whether we’re solving the right problem for the right user.

Our most recent strategy has been for Akhil and myself to scout ahead using experiments to validate risky assumptions. We identify potential problems, make a hypothesis about how a particular solution will perform, and then go build a lightly engineered, well instrumented experiment which we then un-gate for a subset of users. We set up time to watch these users, take note of what’s working and what sucks, and review the data. If the hypothesis was supported, we return to the team with the recommendation to proceed with a more resilient engineering implementation. If it fails, we ask why, and propose new hypotheses to test. This process repeats, enabling us to continuously validate assumptions with real users. We’ve already dodged some costly engineering efforts using this approach.

Finally, I’d be remiss if I didn’t discuss what I’ve learned about my design strengths and weaknesses through working with Akhil. What makes our partnership so effective is that Akhil, like Tim, is a Generator, while I am a Synthesizer. Akhil can throw out a hundred solutions effortlessly, even if ninety-nine of them are thrown away. Fortunately, I balance out the equation by discarding the ninety-nine and quickly find the one that works best. But that’s not enough. I then ask where the solution can break. “Why don’t we try something a little different? What happens when user does X? This still isn’t right. Something here seems off — it’s not solving the root problem.” I poke and prod until we find something we’re both super excited about.

What makes this work is that Akhil never assumes bad intent. He knows that all feedback comes from wanting to give users the very best product experience. With that understanding, my continuous commentary is food for Akhil to generate new ideas. We repeat this process over and over, our ideas sometimes meandering, sometimes wandering, and sometimes repeated. We’re quick to recognize when we’re moving in circles and know when to step back and put a stake in the ground or rule out a distracting edge-case so we can make progress. This organic ebb and flow leads to solutions far beyond what either of us could have come up with on our own, even if time was not a factor. I’ve learned that when paired with a Generator, my effectiveness skyrockets.

Needless to say, we’re planning to make massive progress in 2019.

In the final week of 2018, I’ve had the opportunity to start laying the foundation for a transformative new year for the Inbox product. With such rapid growth in this past year, we’ve started pushing up against the limits of some of our systems, processes, and technology. Some of the ways in which we used to work are no longer compatible with what’s needed at our current stage. From a technical perspective, consider the familiar case of a monolithic application becoming slow to build, slow to load, and precarious to develop as the team grows. Although Drift has been ahead of the curve — already having dozens of micro-frontends deployed and a repeatable process for creating new apps — there are still some interesting challenges remaining.

For example, how do you balance the need to show constant, incremental progress with an increased focus on quality and measurement, against the hindrance of outdated dependencies, bloat, and infrastructural inferiority of the remaining monolith vs starting from scratch using the new application template? This has been a recent focus of mine as a member of the Inbox Team. Consulting with other Frontend Leads who’ve migrated legacy portions to the new system, I sought advice and learnings from what they’d already been through. Difficult to please everyone, there have certainly been tense moments where someone may have been burned by a particular approach in the past and strongly cautions against it. It becomes especially interesting to navigate this complexity and to synthesize the advice when you realize that the constraints and circumstances under which previous technical successes or failures occurred were completely different than this particular challenge we currently face. Fortunately, Drifters drop the ego and tend to support you with whatever decision you take. Once you’ve committed, everyone is going to do what they can to make sure you’re extremely successful.

With a strong sense of urgency to set us up for success in 2019 (and to seize this rare window in which most of the team is on vacation), I got to work coming up with the plan to migrate our application off of the monolith and into its own isolated app. Within a week, I’d gone from having a vague, nebulous idea of the approach, to having a rock-solid cutover plan successfully rolled out on January 1. While I didn’t start with that level of confidence, I’d certainly learned quickly through tactical changes, deployments, and discoveries. I realized this was a very surgical operation, requiring clear steps, rollback plans, and most of all, strong communication. I also realized that the optics of this operation were almost more important than the underlying work and initial impact: the Product organization should be able to understand exactly what we’re changing and why. It should be easy to follow along as the migration unfolds, and key players should know their role in the event of any unexpected issues.

Taking what I’ve learned from Tim, I looked to video as the medium of choice for producing a narrative around our migration strategy. 112 Google Slides, many draw.io architectural diagrams, hours of weekend work, and a 15-minute recording later, I’d produced something I was extremely proud of that clearly articulated why we’re doing this, where plans went wrong, lessons we’d learned, work remaining, strategy for rollout, and how we’d cleanup after ourselves. I crafted an equally refined Slack message and eagerly posted to highly visible product channel.

Diagram shown in video to illustrate interim flow

Responses ranged from “Legit fire”, to “those flow visuals for the app loads were suuuuper helpful and professional as heck”, to “i understood approximately 6% of this, but really appreciate the transparency.” There were numerous emoji-reactions ranging from 👀 to 🔥 to 🙌 and the Drift signature ⚡️. I received a few DMs from engineers who were really appreciative of the way this was communicated. I felt warm and fuzzy, as seen by the tooting of my own horn in this recollection.

Good feelings aside, this validated my hypothesis that the optics matter, and that video is an immensely useful tool for sharing information and seeking feedback in Slack.

But like all great plans, this one took a last-minute turn around 1:00 PM on the final day of the 2018. An astute Tech Lead on the Growth team — Vignesh Mohankumar — noticed that our approach to rolling out the migration to all customers required a code change. Which meant a deploy. Which meant the possibility of delayed rollback and blocking all deploys if anything went awry. This wasn’t ideal, so we listened to what Vig had to share. Recently, he’d been using a new service for feature flagging and experimentation. With that service, you can instantly cutover 100% of traffic to any variety of treatments, while also having support for org-level and segmented whitelisting. For us, that meant we’d have instant rollout and rollback without having to deploy any code. A sound solution, we adjusted the plan and moved forward.

New Years Eve, I found myself walking through the final steps of the plan and clicking around the app in QA some more to see if I could break anything. And as it happens, I could! I identified a tricky race-condition where the experimentation service had not loaded in time to decide whether to show the app within the monolith or to hard redirect to the external app. So if we’d decided to cutover all traffic to the new app, many of those users would not be receiving the correct variation. Fortunately, I was able to track down the issue and worked together with Vig on a solution. We went back and forth for a few hours until finally settling on the right approach. January 1st, 2019–12:00 AM: “Thank you for your patience,” I messaged him. A fitting first message of the new year.

Finally, January 1st, 11:30 AM. We met our internal milestone and prepared for the rollout. Teammates Mate Rakic and Dan Whitcomb joined me in a group chat as we ensured any issues that had appeared in our monitoring stack were unrelated to our changes. Realizing only one of us had access to modify the experiment for traffic cutover, I pinged Vig asking for invites for the rest of the team and he made it happen like clockwork. This would ensure there was no single point of failure or inability to rollback if anything happened over the course of the day. One final tweak, isolating environments in our application monitoring framework for the new app, would eliminate noise between Production and QA so we could focus on customer-impact in the event of an issue.

With the pieces in place, we dialed the experiment to cutover 100% of traffic to the new app. We verified that users were indeed being routed to the new app, that the number was steadily increasing, and that no errors were encountered. Success! The efforts paid off, and we could rest easy, passively monitoring throughout the rest of the day and knowing we’re in a safe place to declare victory on the cutover to our new, isolated app.

It’s been an intense 2018. This recent project has been a defining moment for how I view my interactions with the systems and people that drive our success.

It’s been an intense 4+ years of personal and professional growth. Reflecting on the experiences I’ve gained, I’m energized by what’s next. I know there are long, meandering paths ahead. Dips, crests, chasms, and mountains. I know there are forests of confusion and fog of uncertainty. Bouts of discomfort, and lands of discovery. But they’re all part of this exciting journey. Here we come, 2019. See you all there!

Thanks for reading! Visit breademojidesign.com for some fun 🍞 animations.