Category: Building buy-in

Categories
Building buy-in Distributed Teams Performance Engineering Process Roadmapping Strategy

Leveling Up

(Bluxome Labs : 6/18-7/18)

During the course of June and July 2018, I supported leadership (CTO/VP ENGR/Head of Platform/VP PROD/CEO) around engineering topics such at Brazilian-startup Pipefy around the codebase, Product Engineering, SDLC process, culture, and roadmap(s,) transitioning from a monolith to Service Oriented Architecture, platform strategy, scalability, maintainability, and uptime.

Among other contributions, I:

  • Coached CTO and VP ENGR around operational excellence, particularly thinking in terms of AS-IS versus TO-BE.
  • Introduced idea of maturing IT processes towards forecasting, in particular via a Capacity Plan.
  • Provided thought-leadership around managing remote teams, partly out of own experience, partly as informed by Best Practices.

Results

  • Identified strategies and tactics to qualitatively improve processes.

 

Categories
Building buy-in Distributed Teams Growth SOA SWOT Analysis

Beginnings of a Platform Strategy

(Bluxome Labs : 5/18-5/18)

After reviewing the company’s developer docs and Platform Roadmap, I addressed low-hanging fruit around improving readability and structure while working with key stakeholders (Head of Platform, VP PROD) to organize growth priorities regarding platform adoption over timeframes of 1, 1-3, 3-6, and 6-12 months.

Upon further iterations around growth KPIs while learning about constraints of the platform engineering team, I advocated for the creation of a separate Developer Relations team of a minimum of a Lead, Partner Engineer, Developer Advocate, and a Product Manager (and provided the basic job descriptions for each.)

Also, upon discovering that the Hello World experience of integrating with the platform was less-than-intuitive, crafted the following How-To in one take without a script and using QuickTime:

Result

  • Laid foundation for Developer Relations.
Categories
Building buy-in Distributed Teams Frontend Optimization Performance Engineering

Making an Operations Excellence Frontend Excellent

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

For the client, I probed their UX using multiple tools to determine low-hanging fruit, worked with the CTO and VP PROD to understand resourcing constraints given the product roadmap, and enumerate several tactics in a (prioritized) phased approach towards improving performance.

Heuristic discoveries included FE perf bottlenecks such as:

  • multiple inline JS snippets causing slowdowns
  • un-optimized JS libs, including of React components
  • multiple 3rd party JS libs that were no longer necessary
  • JS libs that loaded neither async nor defer
  • retrieval of multiple styling resources

I found that the greatest opportunity to optimize existed for two key user experiences at ~6s avg page load and ~4.5s average page load respectively.

During one iteration, changes lead to a 52% reduction in the Webpack bundle of React components, improving page speed by 10% or better across four key user experiences.

During another iteration, one key UX was sped up by 39.4% without Cache, 53.8% with Cache.

During a final iteration, changes lead to a 20% page speed improvement on one key user experience and 10% or better on two others.

Results

  • Introduced Performance Engineering mindset leading to 20% page-load speedup.
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.
Categories
Architecture Building buy-in Collaboration demand-side eCommerce Management Process

Overhauling Quality

Bluxome Labs : 4/16-4/16)

Test Questions have long been the quality assurance mechanism of the CrowdFlower platform.

The interactivity behind them was created around 2008 in MooTools as part of a Merb application; that interactivity was never ported, even as the company increasingly adopted Rails and jQuery. For over three years, discussion has been of porting the Test Question interface out of Merb (the last presentation-layer in that app) and into a company-standard Rails app. Given the expected amount of effort with little user-benefitting ROI to be realized for simply a straight port, it’s easy to understand why it had only ever remained a discussion.

Finally, in April, 2016, the stars aligned when the VP of Product expressed a desire to spend time on improving Test Questions usability while the VP of Engineering decided the time was right for moving forward on a micro-service architecture, dividing “frontend” and “backend” responsibilities accordingly. I seized on the opportunity (without being mandated to do so) because I saw that we could kill two birds with one stone

Following is an inventory (I created the initial format for) of JS libs across three different routes (completed by a junior engineer)

I then used this inventory in conjunction with a Jira report to help scope the effort and parcel out work to likely candidates, an example of which can be seen below

Finally, I tracked progress in a wiki page, providing status updates to key stakeholders.

Results

  • Laid groudwork for complete FE overhaul, including success criteria and risks, after shopping technical ideas around with Lead engineers, VP PROD, VP ENGR.
Categories
Building buy-in Frontend Growth NUX supply-side

Landing Page Experimenation

(Bluxome Labs : 5/14-5/14)

Following is a representative control version of the landing page

I whiteboarded several concepts gaining buy-in from the chief product stakeholder and then implemented same, using Optimizely to set the parameter to determine which variation a user saw; below you will see the iterations.

Unfortunately, none performed better than control.

Results

  • Tracked performance of inbound traffic from Facebook, Twitter, Google AdWords, and StumbleUpon and designed/implemented various landing pages to improve signup rates.
Categories
Analytics APIs Building buy-in Collaboration Full-Stack Process Prototyping supply-side

The Portal for Nuclear Information

(IAEA : 8/05-8/05)

At the end of 2004, the IAEA had well over 200 scientific and technical information resources (e.g. databases, websites, applications, etc.)

In order to reduce the effort to maintain these (saving time for graphic designers, software engineers, DBAs, and resource custodians alike,) a single portal was conceived and made a priority deliverable for the IT and MIS sections.

As the Lead Information Architect, I was responsible for gathering technical details about the resources, supporting the technical architect, and driving the design behind the user experience.

Results

  • led requirements gathering and implemented modular components for the authoritative web resource on scientific and technical nuclear information
  • Met with and built buy-in among information stakeholders
  • Abstracted the business processes of the organization to the 50,000 ft view
  • Utilized user-centered methods to inform the design of the portal
  • Implemented the beta version using OpenText, LiveLink, and Java APIs for each