Subscribe

Receive the latest articles directly in your inbox by subscribing here. You can unsubscribe at any time.

Subscribe Now

About

Here you will find articles on an ambitious plan to travel from Singapore to Morocco overland, i.e. without flying.

I will use buses and trains to travel through South East Asia, China, Mongolia, Russia, and Europe.

Read about The Plan So Far.

Life as a Product Growth Tech Lead

Written by Joshua Fuglsang on .

Growth Team meeting at rooftop co-working space in Sydney
Growth Team meeting at rooftop co-working space in Sydney - Copy­right © Joshua Fuglsang

Overview

From 2015 to 2017 I was for­tu­nate to be in­volved in the for­ma­tion of a Prod­uct Growth team at a suc­cess­ful Aus­tralian start­up. While work­ing on the Growth team I was giv­en the op­por­tu­ni­ty to work as the team’s tech­ni­cal lead. In Au­gust 2017 I re­signed from this po­si­tion to pur­sue oth­er goals, which you can read about here. This is an ar­ti­cle about my role as a Growth En­gi­neer and a Tech Lead.

Experiment Execution

One of the unique traits of work­ing in a Growth Team is the ex­per­i­ment driv­en work­flow. At a high lev­el, the ex­per­i­ment work­flow looks like so:

  1. Ideate: gen­er­ate ideas that can re­sult in growth.
  2. Val­i­date: val­i­date the ideas by re­search; most typ­i­cal­ly this meant val­i­dat­ing through quan­ti­ta­tive anal­y­sis of an­a­lyt­ics da­ta, but could al­so in­volve qual­i­ta­tive anal­y­sis through us­er re­search.
  3. De­sign: de­sign the UI of the ex­per­i­ment for in­clu­sion in the prod­uct.
  4. Im­ple­ment: build the soft­ware so­lu­tion.
  5. An­a­lyse: build an­a­lyt­ics dash­boards and graphs to ver­i­fy if the ex­per­i­ment was a suc­cess.
  6. Re­port: re­port on the out­come of the ex­per­i­ment and doc­u­ment learn­ings to feed in to fu­ture ex­per­i­ments.

Project Management

A big part of the rea­son why I re­ceived my pro­mo­tion was due to my abil­i­ty to man­age projects. In the ear­ly days of our Growth team we had no ded­i­cat­ed project man­ag­er for the larg­er ex­per­i­ments; hav­ing a de­sire to ex­pand my skill set I took the op­por­tu­ni­ty be the project man­ag­er on a few oc­ca­sions. Two such projects in­volved sev­er­al en­gi­neers, a de­sign­er, and an an­a­lyst; and both of these projects were for my own unique ideas and have since be­come fix­tures of the prod­uct. In the fi­nal few months of my term I was man­ag­ing the work­load for three iOS en­gi­neers, in­clud­ing my­self. On top of this I ran dozens of end-to-end ex­per­i­ments with a wide range of com­plex­i­ties.

Issue Accountability

As the Growth team was ex­pand­ing and the com­pa­ny was ma­tur­ing it was be­com­ing more and more im­por­tant that the team didn’t in­tro­duce any crit­i­cal re­gres­sions; this was one of the big rea­sons for the cre­ation of the tech­ni­cal lead role.

First­ly this task re­quired that ad­di­tion­al pro­cess­es be put in place to en­sure that code was re­li­able when shipped. For us this pri­mar­i­ly meant:

  1. Run­ning blitz tests on the ma­jor projects,
  2. En­sur­ing that code had a high lev­el of unit test cov­er­age,
  3. Dis­cussing and doc­u­ment­ing code changes that had risk. Ad­di­tion­al risk could be at­trib­uted to the tech­ni­cal debt in­her­ent in some of the old­er sys­tems as well as sys­tems that had a large num­ber of de­pen­den­cies / de­pen­dent sys­tems.

This helped to mit­i­gate po­ten­tial prob­lems, but the oth­er as­pect of this re­spon­si­bil­i­ty was to be ac­count­able for when prob­lem­at­ic code was shipped. For this the were sev­er­al re­spon­si­bil­i­ties:

  1. Be avail­able: when things in­evitably went wrong you would need to be avail­able to see the is­sue through to its res­o­lu­tion.
  2. Have con­tin­gen­cies: this one was quite easy for us as ev­ery fea­ture we re­leased was con­trol­lable via a serv­er vari­able. There­fore if any­thing ev­er went wrong we could turn off the ex­per­i­ment ei­ther for the in­di­vid­u­al who re­port­ed the is­sue or for ev­ery­one en­rolled in the ex­per­i­ment. For­tu­nate­ly the lat­ter nev­er hap­pened.
  3. Doc­u­ment learn­in­gs: once an is­sue had been iden­ti­fied a doc­u­ment was cre­at­ed so that we could record crit­i­cal in­for­ma­tion such as the cause of the bug and how we would pre­vent this sit­u­a­tion from aris­ing again.

Idea Research

A big part of be­ing a Growth en­gi­neer was con­tribut­ing ideas to the team’s back­log. There were sev­er­al tech­niques em­ployed to gen­er­ate ideas:

  1. Tear­down apps and ser­vices with­in dif­fer­ent in­dus­try ver­ti­cals and with­in the same in­dus­try,
  2. Read cus­tomer feed­back from sup­port chan­nels,
  3. Run us­er test­ing ses­sions on the var­i­ous sys­tems with­in the app, in par­tic­u­lar on the on­board­ing flow,
  4. Do self-di­rect­ed ex­plorato­ry work of the an­a­lyt­ics da­ta,
  5. Build feed­back col­lec­tion mech­a­nisms in to large-scale ex­per­i­ments. Re­view feed­back as it was ar­riv­ing,
  6. Quiz fel­low en­gi­neers on what en­hance­ments they think can be made in to the app,
  7. Par­tic­i­pate in cre­ative off-sites,
  8. Per­form self di­rect­ed brain­storm­ing and con­sid­er­a­tion of the apps fea­tures and de­sign.

One achieve­ment I had re­gard­ing this was re­ceiv­ing the com­pa­ny’s quar­ter­ly “Bring Ideas” award. In ad­di­tion I led two teams to vic­to­ry in com­pa­ny wide hackathons. At the time of re­sign­ing there had been on­ly 5 such events.

Engineering

As a Growth en­gi­neer I was re­spon­si­ble for build­ing ex­per­i­ments for the iOS plat­form. En­gi­neer­ing tasks would in­clude:

  1. Im­ple­ment­ing ex­per­i­men­tal fea­tures,
  2. Ar­chi­tect­ing frame­works to sup­port ex­per­i­ments,
  3. Main­tain­ing the an­a­lyt­ics in­fra­struc­ture,
  4. De­sign­ing and im­ple­ment­ing event track­ing for ac­cu­rate anal­y­sis of ex­per­i­ments.

Experiment Monitoring

A big com­po­nent a Growth en­gi­neer­ing is mon­i­tor­ing ex­per­i­ments. This in­volves:

  1. Build­ing graphs and dash­boards in an­a­lyt­ics plat­forms,
  2. Build­ing in mech­a­nisms to col­lect qual­i­ta­tive us­er feed­back,
  3. Dis­sect­ing an­a­lyt­ics events,
  4. Re­port­ing on find­ings.

In ad­di­tion to this be­ing so close to the an­a­lyt­ics da­ta, I would pe­ri­od­i­cal­ly check oth­er app events such as:

  1. Crash rates by plat­form,
  2. Core met­rics re­lat­ed to gen­er­al ap­pli­ca­tion us­age and health,
  3. App rat­ing trends.

Stakeholder Communication

On the Growth team our work of­ten spanned the full breadth of the prod­uct. This meant we had to do a lot of com­mu­ni­ca­tion over what we were chang­ing as we weren’t nec­es­sar­i­ly the cus­to­di­ans of the sys­tems we were ex­per­i­ment­ing on.

Stake­hold­er com­mu­ni­ca­tion in­volved:

  1. Writ­ing con­sis­tent doc­u­men­ta­tion for ex­per­i­ments. Doc­u­ments in­clud­ed: ex­per­i­ment goals, tar­get­ed us­er co­horts, suc­cess and fail­ure met­rics, screen­shots of changes, ex­per­i­ment run­time, and an­a­lyt­ics re­sults.
  2. At­tend­ing tech­ni­cal lead­er­ship meet­ings to dis­cuss changes be­ing made.
  3. An­nounc­ing when ex­per­i­ments were go­ing live, when split sizes were chang­ing, and no­ti­fy­ing sup­port of change im­pli­ca­tions.
  4. Re­port­ing on ex­per­i­ment re­sults in team meet­ings and prod­uct lead­er­ship meet­ings for larg­er projects.

Technical Leadership

An­oth­er im­por­tant as­pect of my po­si­tion was to pro­vide tech­ni­cal lead­er­ship and men­tor­ship to oth­er en­gi­neers. This in­volved:

  1. Scop­ing ma­jor projects,
  2. Pro­vid­ing es­ti­mates for the amount time re­quired to com­plete pieces of work,
  3. Ad­vis­ing on en­gi­neer­ing best prac­tices,
  4. Ed­u­cat­ing and as­sist­ing non-growth team mem­bers to run their own ex­per­i­ments.

In ad­di­tion to be­ing the Growth Tech Lead I was al­so a Se­nior iOS En­gi­neer. As a part of this I would pro­vide tech­ni­cal lead­er­ship to oth­er iOS en­gi­neers. This in­clud­ed:

  1. Par­tic­i­pat­ing in dis­cus­sions on plat­form best prac­tices,
  2. Per­form­ing code demon­stra­tions to the iOS guild,
  3. Re­search­ing and ad­vo­cat­ing al­ter­na­tive ar­chi­tec­tures for iOS apps,
  4. Re­leas­ing new iOS ver­sions to the App Store,
  5. Be­ing pri­ma­ry in­ter­view­er when ex­pand­ing the iOS en­gi­neer­ing team,
  6. On­board­ing new­ly hired iOS de­vel­op­ers.

Conclusion

You can see that it was quite an in­volved role that re­quired a lot of du­ties be­yond the scope of a “nor­mal” en­gi­neer­ing role. I need­ed to:

  1. Be able to think lat­er­al­ly to come up with new ideas,
  2. Be a good com­mu­ni­ca­tor in or­der to be able to pitch your ideas and to doc­u­ment your learn­ings ef­fec­tive­ly,
  3. Be able to use an­a­lyt­ics plat­forms in or­der to an­a­lyse ex­per­i­ment re­sults and to do ex­plorato­ry re­search,
  4. Have some de­sign skill in or­der to cre­ate vi­su­al­i­sa­tions of your ideas,
  5. Be an ef­fi­cient en­gi­neer as ex­per­i­men­ta­tion should have a high ca­dence in or­der to learn as much as quick­ly as pos­si­ble.

I don’t claim to be an ex­pert in all of these ar­eas, but over the course of two years I went from hav­ing a T-shaped skill set of an en­gi­neer to hav­ing the V-shaped skill set nec­es­sary for self-suf­fi­cient­ly run­ning end-to-end ex­per­i­ments.

Thanks for read­ing this ar­ti­cle. A lot of ex­tra de­tail could be added to all points in here. If you have any ques­tions then please feel free to com­ment be­low or email me di­rect­ly.

Please see the rest of my Growth Ar­ti­cles for more.

About

Here you will find articles on an ambitious plan to travel from Singapore to Morocco overland, i.e. without flying.

I will use buses and trains to travel through South East Asia, China, Mongolia, Russia, and Europe.

Read about The Plan So Far.