Thread by @thiagoghisi

After my article about Behavioral Interviews last week, many folks asked me for examples.

Today, have left that world, I'll be vulnerable and share the essay that landed me three $650k+ job offers at BigTechs last year.

Question: What is the most innovative thing you have done?

> My Answer (from Jan 2021).

During my first year as an Engineering Manager on the Mobile Engineering Team at American Express, my team and I struggled to deliver two important features on the Amex Mobile App, doing only two “Big Bang” releases throughout the year.

After realizing that our dev. approach wasn’t working well, I switched to a lean development approach that has since helped us slice dozens of large business initiatives into small incremental releases, increase our team productivity by 12% and reduce our cycle time by half.

One of the biggest challenges I faced when I joined Amex was how to find a way to deliver large initiatives in our global app in small pieces, reducing risk and allowing us to collect feedback and change directions along the way.

There was a big push for Agile company-wide, but many elements of the culture were still waterfall.

To make the company more comfortable with Agile, I decided to:

1. First, gain credibility to reduce resistance,

2. Then, focus on small wins to gain momentum and find supporters,

3. Finally, work through the problems, one project at a time.

The first thing I did was to find an area of opportunity where I could make small improvements.

I chose user stories.

I created a template for the structure with multiple examples to make things more straightforward.

I came up with a list of items for our shared "definition of ready" checklist for stories, so we all knew the expectations when writing or reviewing.

Finally, I decided to experiment with a new format for our use cases.

To introduce it, I rewrote multiple pieces of requirements and acceptance criteria to the Gherkin Language (Given…When…Then).

I would rewrite them during or after meetings and propose them to the original authors (usually Product Managers) in private, saying something along the lines of:

> "What do you think?"

> "Does it capture the requirement?"

It was up to them to adopt my format.

Still, many co-workers noticed how much more readable and easier it was to communicate and collaborate across roles using Gherkin scenarios.

After this, Product Managers started to come to me before our grooming sessions to review their stories before presenting them to the team.

Testers who liked the format would collaborate with the Product Manager to convert the remaining stories to the new format.

This helped me gain trust and build relationships with the team, especially with folks sympathetic to my philosophy who saw my efforts to implement my suggestions.

The second thing I did was identify a few simple tools and practices I had used in the past (mostly at ThoughtWorks) that could provide some direct benefits for the problems I was seeing.

For instance, we were not using any tool to visualize our backlog;

We were using a "Flat Backlog" directly from JIRA, where it was almost impossible to find connections.

I proposed creating a hierarchical visual of the scope.

This was similar to User Story Mapping, a way to visualize the project's scope that would allow everyone to see the big picture, quickly identify dependencies and connections, and ultimately sequence the work more effectively.

I researched a tool, prepared a template, proposed a structure, presented it to the team, and fine-tuned it.

As we started to put the high-level features on a virtual whiteboard following the user journey, we found multiple product, design, and engineering issues that we would have only discovered much later in the development process using the Flat Backlog approach.

When we presented this to the team before going deep on the requirements, we had many more questions and participation from the broader group of engineers, testers, and designers.

We started to use visual story mapping for the first 10 minutes of each weekly backlog grooming session to zoom out and see the project's big picture before we zoomed in on specific requirements.

Again, we saw more engagement in the meeting, more collaboration happening during and after the meeting, and many more creative ideas on moving past blockers or dependencies.

Suddenly, we saw ourselves showing the project Story Mapping to VPs and other senior leaders in the company to give updates or make sure they understood the initiative's complexity or size.

With the entire backlog of the project in a single visual, allowing us to see dependencies, identify groups of related requirements, and sequence work, the next task was to do incremental releases.

One of the big problems I saw was that we would receive close to pixel perfect designs for entire brand-new flows of many large initiatives.

By the time Engineering received the designs, most had already gone to multiple rounds of approvals by VPs and Legal.

I knew we would need to change this process if we wanted to enable incremental releases.

On the first project that I had the opportunity, I decided to adopt the visual strategy again.

On a single visual, I put the entire flow of screens of the feature as it was in the app at the time side by side with the proposed flow of pixel-perfect screens' designs.

When the team saw that image with too many things changing at once, it was not hard to convince them that we had to break down our projects into smaller releasable increments.

Otherwise, we would keep having the problems we were having with the Big Bang releases in similar projects.

With most of the team onboarded, instead of breaking down the six months of the project into six monthly releasable chunks, I asked the product and design team to come up with three.

It was still not ideal for incremental releases but would be moving us in the right direction, and I was confident we would start to experience many of the benefits.

So, we began by breaking down the full scope of the project into three potential releasable chunks.

With our designers' help, we quickly modified the designs and saw how the entire feature journey would look to the customer in each of the releasable stages.

That allowed us to have a clear focus, get approvals, mitigate risks, and learn by releasing twice before the final release.

Suddenly, a well-known pattern seen in the industry started to happen to us; in multiple projects, we reached most of the business goals after the second release and, in some cases, after the first release increment.

🎉 (this was not on the original. 😂)

Planning our incremental releases upfront made a significant shift in how we built software.

It made us analyze the dependencies and the impact of every single feature more closely.

After smoothly releasing two complex initiatives using this new approach, I gave a talk to the entire Mobile department at Amex to share some of the practices working well for us.

Soon after that, my VP started to ask me to present the same idea in meetings and provide guidance for large projects about to start.

Today, more than one year later, many of the practices that my team and I pioneered are being used across our 14 cross-functional teams in 4 different time zones, resulting in record productivity.

We went from shipping 125 new features in the app in 2019 to, even with the COVID-19 pandemic, shipping a total of 140 new features in 2020.

We also made our delivery a lot more predictable. The P85 (85th percentile) of our cycle time (from Discovery to Release) went from 96 calendar days in 2018 to 59 days in 2020.

An early release can help capture market share, generate an early return on investment, and reduce money risked on software development.

In our case, it helped us win the J.D. Power award for the Best Credit Card Mobile App in the U.S.

We went from number #7 (2019) to number #1 (2020) in overall app performance in less than a year.

<END.>

Question to my followers:

1. Was this helpful?

2. Would you like to have access to all my 50+ notes that I took while doing pretty much all online programs such as IK, Mock Interviews, etc. And that ultimately landed me three Sr. Eng. Manager offers at FAANGs last year?

DM me.

BTW, here is the link to my initial article that triggered this thread:

https://twitter.com/thiagoghisi/status/1487478725381873669?s=20&t=e3FkZKkNTxHezgL8OPAZNg

Getting a lot of questions about tooling:

Initially we used a confluence plugin called Gliffy for diagrams because that was the only things approved by InfoSec.

Later we tried mural, but ended up using InVision Freehand as our design team was already using in InVision.

Side note 1;

This article by @jamesshore - Change Your Organization (For Peons) - was a massive inspiration for me and helped me a lot on my journey at Amex.

Every time I would get demotivated to overcome a challenge, I would reread it.

https://twitter.com/thiagoghisi/status/1313107468063571968