Categories
eCommerce Growth Leadership Prototyping supply-side

Beat Company Plan

(The RealReal : 1/17-6/17)

In January, peers in different areas of the company came together in a cross-functional guild with the goal to beat company plan around yearly supply-side user acquisition. Over the following months, we ideated and executed on a few ideas to make that happen.

Where I saw opportunity to realize the most gains for the least amount of (engineering) effort, I acted as Senior Engineering Representative and spoke to the likely costs of implementation, overseeing the ideas we as a guild prioritized.

Re-consign

To realize an idea around “re-consigning” – that is, enabling demand-side to re-sell an item they purchased from supply-side, I threw-together a “reconsign” link with an Javascript alert and beaconing usage via Segment, worked with PROD and DSGN to flesh out the feature in-full, and then managed a remote team to to get the feature (fully-baked) into production.

Friendbuy

Long championed by the CFO, and by consensus of the guild, we scoped out and delivered an integration with Friendbuy; which wound up being beneficial for user acqusition on both sides of the marketplace.

Funnel Optimization

The guild sanctioned a prioritized idea around optimizing the supply-side user funnel. DSGN built out wireframes and I managed the team to realized the new acquisition funnel in Phoenix.

Results

  • Led best 2017 revenue-gen (adding $3M to the bottom-line) and best 2017 lead-gen features (boosting leads by 50%.)
Categories
Leadership Optimization Performance Engineering supply-side

Improving Speed and Conversions

With no-one on staff having formal performance engineering experience or training, I led the effort to address a 6s sitewide page load average. Over approx. 6 months, stealing time from each sprint as I could given other responsbilities, I assessed bottlenecks using performance tools, including procuring a contract for Insights, Browser Pro, and Synthetics.

In a nutshell, assessing some of the pages having a roughly 13s page load, skewing the overall site’s average, I determined that the bulk of the performance issues were in blocking JS libs and then crafted a remediation strategy and established SMART goals for baselining/measuring impact of changes quarter-over-quarter with intent to drop from 6s to 3.5s by the end of 2017. Below you’ll see a spreadsheet I kept, noting the average Page Load Speed every Monday morning. Finally, in May, we address the bulk of the blocking JS libs and reversed the upwards trend.

The CEO was amazed at how much faster the site felt.

Results

  • Intro’d performance engineering, leading to page load speed reduction by one full second and 11% bump in mobile web conversions.
Categories
Collaboration Innovation Management

Collaboration @ TRR

(The RealReal : 9/16-5/17)

Facilitated smooth cross-team (PROD, DSGN, Platform, Mobile, Web) interactions towards scoping and delegating engineering work for:

  • Black Friday/Cyber Monday
  • modifications to supply-side NUX towards increased signups
    • first in altering/improving the basic flow
    • then while incorporating different verticals (Art Home)
  • conversion of non-responsive UIs to responsive
  • shipping/up-sell through Narvar
  • payment processing through Hyperwallet
  • analytics reporting shift from Snowplow to Segment
  • Google Tag Manager modifications/optimizations
  • cross-browser test coverage of business critical paths through Rainforest QA
  • shoppability/conversion usability improvements (e.g. faceted navigation filters)

Results

  • Built rapport with business partners (Product Managers, Designers, Marketing) and direct reports to get work done.
Categories
Innovation Leadership Process Prototyping SOA supply-side

Phoenix Homepage POC

(The RealReal : 2/17-3/17)

Early in 2017, a Tiger Team formed of me, a Lead ENGR, the CTO, the VP PROD, and a PM.

The CTO and VP PROD had an idea to empower Merchandising and Marketing to further drive content/conversions from the Homepage. While they previously had some power to manage that content through an admin interface with a limited schema, the idea was to give them even more creative expression, allowing them free-reign over their HTML.

A few weeks into the project, the Lead ENGR, who had been tasked with building out the intial POC, left (leaving us in a lurch.) Under pressure, I still delivered basic CMS functionality via Rails and demo’d same to the C-suite.

Shortly thereafter, when requirements radically changed and the mandate from the CTO was suddenly to move towards a WYSIWIG experience through a 3rd party Content-as-a-Service provider as rendered via Phoenix, while moving away from a lazy-load landing page to a 3×3 grid, I built out a simple placeholder homepage in Elixir and then evaluated and prototyped against several CaaS vendors (e.g. Prismic, Kentico Cloud, Contentful.)

When the CTO settled upon Prismic for us to move forward with, I conceived the project plan for engineers to carry the effort forward while also developing the initial migration plan for porting route-by-route from Rails to Phoenix.

Results

  • Built MVP of company’s Rails-to-Phoenix migration.
Categories
Architecture Prototyping supply-side

Not Ready for React

(The RealReal : 1/17-2/17)

When I joined, it was with the understanding that as the company was growing, we would need to be splitting out the codebase into a more service-oriented architecture.

In late Q1/17, seeing an opportuntiy to leverage React components to both DRY up and reuse functionality and in a bid to further decoupling frontend and backend, I tasked the remote Russian team with the introduction of React around signup functionality.

When the project was almost complete, an engineering executive required that we pull out React and implement the functionality in a more vanilla way, citing that “any changes that engineering [made] causing the business to potentially miss its numbers would be bad.”

Results

  • Explored (but had to abandon) use of React at TRR.
Categories
eCommerce Innovation supply-side

Hackathon : Browser Extension

(The RealReal : 2/17-2/17)

Results

  • Won “Best Hack” while pairing w/DIR Design to create Chrome Browser Extension (similar to Honey) to cross-sell inventory on related retailers.
Categories
APIs Architecture Backend Collaboration Frontend Innovation SOA SPAs

Next Gen FE

(Bluxome Labs : 7/16-7/16)

Leading the Charge

Upon returning from vacation, I disovered that the VP ENGR gave the recently-joined Team Lead carte blanche around moving ahead with the next phase of re-engnineering the codebase for a further SOA-influenced frontend and backend split.

Being intimately familiar with the current system architecture, in a race against time for Week One (only had a week before VP ENGR wanted Best Practices/new workflows/adoption of new technolgies and because one substanitally differing proposal – likely much more costly from development and operational standpoints – was on the table,) I set out to formulate a concrete strategy towards delivering in the short-term while providing a basis to iterate against a longer-term architectural shift.

Architecting the Solution

First, I advocated for the adoption of the ‘Launch Page’ as the testbed with which to move forward. Then, I reviewed that page in order to reverse-engineer whatever model attributes I might be able to use (in a Backbone model) as exposed by in a simplistic GET request on page load for initial state.

I then modeled that simplistic endpoint using the Swagger Editor

Next, I dumped the YAML of that endpoint and leveraged Swagger code gen tools to create an initial version of the endpoint in Node.js (and Ruby and Java) and fired up that Node.js for serving HTTP requests.

At that point, having proved to myself the utility of Swagger for spinning-up some simple Node.js services, I turned to building out a placeholder SPA using React that would consume a Node.js service. I opted to stay within the Rails paradigm (instead of adopting an approach of statically hosting assets elswhere) and first used react_on_rails to incorporate React and then the react-rails-hot-loader for HMR.

I wound up needing to patch the latter locally in order to get Web Sockets working correctly in my environment.

Having put the Big Rocks in place, I could hand off the SPA POC to the F2E consultant for further refinement and could focus on building more of a case for the overall approach which the VP ENGR then gave his blessing to.

Building the API

During this phase (Weeks Two and Three,) I implemented GET, POST, and PUT JSON-serving routes in Rails (not to have to worry about CORS) while also developing in the context of Amazon’s Lambda and API Gateway, taking the Node.js server stub above and dropping it in as an HTTP Proxy to collate information from existing API endpoints (as microservices.)

I also worked with five backend specialists and my work guided the conversation around establishing Best Practices for API development.

Results

  • Championed bottoms-up approach to decouple microservices, influenced VPE/Team Lead/F2E to adopt, and prototyped using React / Hot Module Reloading
Categories
demand-side eCommerce Frontend Innovation OOJS Process Prototyping

Better NUX

(Bluxome Labs : 6/16-6/16)

Towards improving the New User Experience, Design came up with the idea to use Callouts around page elements whose affordance wasn’t intuitive.

Given the mockup, I set about implementing it pixel-perfectly.

For the first pass, I simply crafted the markup based on Bootstrap’s Alert and hid it by default, revealing it with JS if logic was met.

Then, realizing that the Bootstrap Alert wasn’t sufficient for Design’s needs and that the Bootstrap Popover was, as well as that there would be opportunity to re-use the code elsewhere in the platform, I created a JS Class for the NUX (a.k.a. “Callout”) and subclassed (example) accordingly, modifying the markup accordingly.

Results

  • Established team habit around refactoring and improving OOJS.
Categories
Architecture Building buy-in Collaboration demand-side eCommerce Frontend Leadership Performance Engineering Process

UI Tech Debt

(Bluxome Labs : 3/16-6/16)

A remnant of the legacy codebase from the company’s origins eight years ago, the two most important routes on the platform for quality assurance had never been moved from the company’s original Merb app to its companion (upgraded) Rails experience (back when a first movement towards SOA happened three years prior.)

They were rightly regarded with trepidation given their dependence on MooTools when the rest of the platform had been moved to jQuery, especially as the Jasmine suite for their coverage had been mothballed about 18 months before and those same MooTools libs were tightly-coupled between two platform applications.

Towards a future of less frontend tech debt, I seized on the opportunity to champion and shepherd the project (as a Q2 engineering goal) through to completion.

Over the course of three months, I led the effort around project scoping, weekly communication around engineering effort, and architecting and leading the implementation, interfacing with Product and Design to ensure quality in light of the absent test coverage.

Results

  • Delivered on decoupling strategy for static asset management / Webpack’d bundles while collabratively iterating with VPE/VP PROD and Sr. Engineers
Categories
Building buy-in Frontend Optimization Process

Shifting Mindset

(Bluxome Labs : 4/16-6/16)

Prior to Q2 2016, the team had supported Product’s goals for delivering feature-value without ever considering engineering goals (better code quality/maintainability, page performance, workflow improvement, etc.) I took initiative to flesh out high-level deliverables for the quarter.

Below is an example of a set of performance metrics around the most-highly-trafficked page on the platform.

Though we didn’t meet this particular goal for the quarter – mostly because of a move to Webpack from RequireJS in late-April and then the introduction of React on the page in mid-May – the simple fact that the data was being tracked represented a major paradigm shift towards that of being a data-driven team, whether around page performance OR engineering deliverables.

Results

  • Introduced quarterly, data-driven, engineering KPIs.