Tag: Rails

Categories
Integration Process Prototyping

Single Source of Product Truth

Challenge

Given numerous silos of product information, each with varying degrees of accuracy, evaluate and move towards reliable source-of-truth for driving intra-brand sales.

Action

Phase 1
  • Discovered sister brand developing real-time product DB (in Rails)
  • Evaluated pros and cons of approach with CEO around relying on that DB/dependency
  • Reached out to Prod Mgr for repo access and to facilitate intro to India dev team
  • Dusted off Rails skills / dug into codebase not having any documentation
  • Applied light-touch getting to know key parts of system (e.g. product ingestion, Solr-based search)
  • Worked backwards from UI to determine schema of API
  • Used Postman to prove out ability to programmatically upload products (and introduced the use of Postman Collections for knowledge sharing)

Phase 2
  • After CEO stepped down and interim leadership stepped in, reviewed previous progress, gaining buy-in.
  • Discovered a dust-collecting daily job of 10GB of product data sFTP’d to us.
  • Identified risks of reliance on product repo and charted a parallel path forward.
  • Prototyped Lambda for parsing and processing that data, ingesting into our our product DB.

 

Results

  • Delivered Lambda to process 10GB of product data daily to keep assortment fresh.
Categories
Distributed Teams eCommerce Management Mobile

Managing @ TRR

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

Execution

Provided research support around pre-IPO due diligence of SDLC metrics, teams’ productivity, and intellectual property

Shepherded months-long-overdue supply-side user acquisition feature into production (which had been built by third party vendor but then mothballed) by delegating to senior engineer for verification

Evaluated dev work towards long-term financial capitalization

Made introductions leading to offers for data science intern and candidate for Director of Estate Sales

Supported business’s most-important monthly accounting processes

Participated in Erlang and Elixir Factory 2017 and Google I/O 2017

Performed requirements analysis/discovery around 3rd party video chat solutions as a tactical way to increase supply-side engagement/retention

Proposed and shepherded build-out of Rules Engine POC (using Wongi) to simplify item pricing; abandoned because of time constraints

Hiring, Retaining

Led 21 Software and QA Engineers across seven web/mobile engineering teams (incl. in Russia, Canada, Central America) for:

  • web : Rails/vanilla JS/Resque/MySQL/ElasticSearch on Heroku
  • mobile: iOS and Android

Filled capacities of: Release Manager, (acting) Lead Engineer, Technical Recruiter, Scrum Master, Software Architect, Senior Engineering Representative (C-suite,) and Manager.

Partnered with HR to:

  • identify ways to plan direct reports’ performance improvements while effectively managing reports through direct communication and engagement when issues arise; crafting Performance Improvement Plans as necessary
  • start the engineering internship program in a bid to recruit highly-engaged, motivated potential future junior engineers; bringing on and coaching a female CS major from Columbia
  • to ensure diligence around off-boarding consultancy in favor of a more performant agency

Increased capacity by:

  • collaboratively establishing and tracking against 2017 objectives while engaging direct reports through periodic 1:1s as well as yearly performance reviews, including providing feedback as part of peripheral teams’ review processes
  • making introduction to highly-performant near- (Canada) and offshore (Russia) teams to augment local web teams while organizing and managing engineers and deliverables
  • fielding request to procure more resources on a Tuesday, re-established communication to previously-contacted near-shore agency immediately thereafter, and by Friday of that week, had a contract signed for two engineers to start two weeks later
  • facilitated Agile SDLC through leading standups, backlog grooming, commitment-based sprint planning, and retrospectives

Increased engagement by:

  • mentoring junior engineer in taking on time-sensitive accounting change having major impact to business and shepherded that effort to complete without bugs while meeting the deadline
  • organizing company-culture events for promoting team spirit (holiday party, cocktail contests, bowling, bocce, Exploratorium)
  • doing daily code reviews of teams’ PRs
  • drafted leveling plan

Continued search after multiple Lead engineer candidates ghosted/fell off the radar after offer; including the time after a candidate accepted job offer only then to inform us the day before he was to start that he had accepted another offer

Quality

Took over QA when QAE suddenly left; picking up Ghost Inspector, Runscope, and TestPad

Led eval efforts around Rainforest QA/on-boarding seasoned QAE replacement

Results

  • Led diverse co-located and remote web and mobile teams to deliver the user-facing experience for the premier luxury reseller.
Categories
crm documenting eCommerce Innovation Leadership supply-side

Increased Leads

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

Late Q3/2016

Upon joining, I inherited a lead-gen project that had gone deeply awry. Earlier in the year (March,) Product and Design had come up with an alternative lead-gen flow. An offshore company was procured to follow-through with implementation. The consultancy tackled the project but their implementation sat on a feature branch gathering dust (six months!) and lacking documentation until I arrived.

In order to get the feature into production, I tasked a Senior Engineer with soup-to-nuts verifying the feature branch. When he failed, I marshalled other engineers (at yet another near-shore company) to do the verification. They succeeded and we were able to roll out the new user experience, meeting a company objective to have it in production by the end of the year.

Mid-Summer 2017

Another executive decision was made to revisit the (same) flow and try yet another alternative, this time, in the new Phoenix environment. I spent time running point to assess the basics of the necessary (information) architecture in the new framework and then forumulating a project plan to implement. In October, the new user experience went live.

Results

  • Championed way-over-schedule experimental lead-gen flow into production, improving quantity/quality of sales leads.
Categories
APIs Collaboration Emails Management

Improving Deliverability

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

In a bid to

  1. improve deliverability of our email campaigns (by sending from same IP) and
  2. free Engineering resources (by shifting email template management to Marketing)

… a(n under-resourced) team1 I was head of was tasked with further migrating from SendGrid templates to ExactTarget.

Given competing priorities, resource availability, and trying to support the engineer’s professional development around further full-stack experience, I tasked the Sr. Frontend Engineer (newest member of the team and who had never done email marketing before) with the port.

For some further context, by the time I had arrived in Q3/16, approximately 10% of system-generated transactional emails had already been ported (such as the demand-side signup confirmation email,) so there was already some precedent and knowledge in the team on how to do such ports.

Scope Change

Working with Product and Marketing, we identified the accounting email sent monthly to supply-side users (30K recipients, arguably the most important email in the system) as the next candidate for porting. According to what we could deduce from the documentation and making certain assumptions about implementation based on similar (previous) endeavors, it seemed like the port would be a slam-dunk in two weeks.

As the engineer got into implementation, I realized that the scope was much larger than originally anticipated. Instead of a one-off API call like had previously been the case (e.g. for the demand-side signup confirmation email,) we were looking at a fundamentally different business process – not of a one-off send but a batch send of 30K emails as part of the monthly payout managed by the Director of Accounting (as kicked-off by a single admin button-push.)

Furthermore: if a demand-side signup confirmation email did not land in a user’s inbox, certainly that was problematic, but if a supply-side user’s monthly accounting email (or, worst case, multiple 1000s of them) did not arrive, that would cause an exponential increase in Customer Service requests and – much worse – violate the company’s contractual SLA with supply-side customers around informing them what their monthly payout would be.

We (all of us – me, the engineer, Marketing, Design, the Product Manager) had wandered into uncharted territory by tackling a template that was blasted out at such volume. We had to revisit our assumptions about how to build out the feature.

Feature Diligence

To emulate a send at a user level was fairly trivial; simply invoke a method call from a console. To truly emulate the batch blast on staging proved much more complicated, as two conditions were necessary: a block of 30K test users and integration with (and kick-off of) the monthly payout (which took four hours to finish.)

Though I assumed the engineer would be able to navigate an unfamiliar domain because he had some full-stack abilities and had been able to reason systematically about architecture in other circumstances, he had difficulties iterating at a unit and functional level to get a local (development) email send working. I coached him on the first tactic – providing guidance to test code at various levels (unit, integration) to mitigate risk – focusing on a method call as it would SMTP email from a local dev environment and then the invoke the ExactTarget API. Then, I coached him to deploy a feature branch integrating with the payout onto staging (where users had already been anonymized) and setup a test blast of 200.

With that blast, we ran into a race-condition around data extensions – which no one in either Engineering or Marketing had complete mastery of – where emails were being delivered empty (simply explained: because no sequential dependency existed between data population and emailing.) Over the following weeks, we tried to determine the best way forward while interacting with our ExactTarget sales representative and then their engineers. We experienced suboptimal support/delays in her getting back with answers to our questions.

Result

After two months of development effort, back-and-forths with Product and Marketing, and several back-and-forths with ExactTarget sales reps and engineers, in a meeting shortly before production go-live of the port (involving the VP PROD, CTO, and VP Marketing,) given the potential risk to the business of such important emails not being delivered, an executive decision was made to abandon the port.

Takeaways

If I had the opportunity to manage it again, I would have:

  1. found a way to free up time for the more experienced Full-stack engineer – who had had some experience with ExactTarget but was overcommitted at that point on other priorities – to initially pair with the Sr. Frontend Engineer. That would have exposed the initial underestimation in scope earlier, leading to a better cost-benefit analysis (for all stakeholders) given the information we had.
  2. advocated for refactoring, given what I learned about the state of the code, architecture, and process, and how tightly-coupled the mailing code was with the payout code (making even a semblance of proxy integration testing arduous.) Refactoring would have allowed us the opportunity to identify business critical functions and ensure we had reliable automated testing around them.

In reflecting on what we could take away around process improvements, I have learned to leverage these ideas:

  1. kick off any new project with a technical design review
  2. understand the typical load of a feature before making a change
  3. identify system changes affecting user experience as one-off or batch (which impacts scope accordingly)
  4. for anything involving a 3rd party, scope work at 3X as a rule-of-thumb (this heuristic is informed not only by this project but by others that involved 3rd party APIs)

I hope that one further follow-on highlighted by the experience for Product and Engineering executives was that, given not only the difficulties in this project but others involving Salesforce/ExactTarget, smaller vendors with less confusing/better/easier technical documentation could be more cost-effective in the long run.

[1] : a Jr. Full-stack Engineer (2 yrs. exp.,) a Full-stack Engineer (7 yrs. exp.,) and a Sr. Frontend Engineer (7 yrs. exp.)

Results

  • Led engineering effort to improve email deliverability (which we ultimately had to abandon.)
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
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
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 Backend demand-side eCommerce Frontend Full-Stack Innovation SPAs

Demand-side UX Refresh

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

In a unique position given my previous experience with the UX, I took an opportunity when tasked by Product and Design to not only reskin the Listing but also to upgrade it.

Given that no one besides me really knew how RequireJS was working in the application and given its falling-out-of-favor in the general community as a module-loading solution, it was time to upgrade it to Webpack.

Here’s what the Task Listing looked like before

Here’s the mock from Design

In chronological order, here’s what I did

  1. Upgraded DataTables from 1.9 to 1.10
  2. Refactored JavaScript towards more of an OO paradigm
  3. Applied new skin
  4. Ported JavaScript for RequireJS to CoffeeScript for Webpack
  5. Deployed

…and here’s what I delievered

with modal

Results

  • Successfully advocated for adoption of Webpack to replace RequireJS and then ported most-trafficked page, while achieveing near-pixel-perfect re-skinning.

 

Categories
Collaboration Frontend Full-Stack Innovation Machine Learning SPAs supply-side

ML Workflow UX

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

After focusing on other priorities, I was pulled into a revision of an interface (I had also created) as delievered for the Rich Data Summit allowing customers to send any model predictions under a certain threshold to the crowd.

I took the following (revised UX) static mock from Design

and iterated to deliver the following

Results

  • Crafted SPA as lynchpin connecting platform’s Machine Learning (Python) and human-in-the-loop (Ruby) systems after convincing team SPA was optimal approach.