Author: Anthony Bull

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
Hiring Management

Attracting Talent

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

In the absence of a dedicated internal HR resource for technical recruiting, I led the initiative to attract Senior and Lead full-stack software engineers while carrying my multiple other responsbilities.

I turned to Hired, Indeed Prime, Hacker News, LinkedIn, Workable and third-party recruiters to source 100s of candidates. Given the sheer volume, I developed a keen eye to quickly screen and asess candidates for possible tech and culture fit (e.g. current/former titles, size of current org, number of years of experience, tech stack, etc.)

I developed code challenges for the roles, emphasizing frontend or full-stack skills as appropriate, and performed the initial phone screen (partly cultural fit, partly technical.) I then handed off to a Senior engineer for a further technical phone screen and if the candidate passed that, s/he was brought in for a full-day onsite with the team.

I coordinated the day’s pre-brief (who would ask about which topic area) and the de-brief (where the team would vote to move forward or not.) If there was consenus, I would begin the background check process while also working with HR and the CTO to determine the apporopriate amount of compensation and equity and get an offer letter drafted.

Lastly, I faciliated the team’s continual improvement around the interview process.

Results

  • Morphed generic job reqs into team-specific roles to attract candidates fitting tech stack and company culture; got to offer with six, closed one Sr. and one Lead Rails engineer, and kept team’s morale high when candidates declined.
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
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