We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

What I Learned From A Huge Automation Initiative

Sharing the vision
Convincing
Productivity
Different Skillsets

24 July, 2020

Venkat Venkataraman, Sr. Director of Engineering @ Gracenote, shares a story about learning from what happens during a company wide initiative that has tons of potential.

Problem

In my current company, there was a huge automation initiative kicked off over a year ago that could save millions of dollars per year for the company, while also improving efficiencies. Even though this was handled by a talented Tech Lead who has a team of capable engineers and a very experienced Product team that had run projects of this scale before, it did not really take off, leading to frustration for Product and Business teams.

Actions taken

This project involved not just regular Software Development, but also Machine Learning. The software implementation was handled by one team, whereas the ML implementation was handled by another, and both teams did not fully understand the work of the other. Also, the ML team's approach was more research-oriented, whereas what we really needed was something production-worthy in a quarter.

The first step was to have an engineering leader that understands both worlds - Machine Learning and Software Development, which happened to be me in this case. I have Directors reporting into me, who have Engineering Managers reporting into them, and Tech Leads/Tech team reporting into the managers. But in this case, I had to cut through the layers and interact directly with the engineering teams.

The next step was to make ML teams shift their focus from research-oriented to production-oriented development. Contrary to common wisdom, we made a large scale announcement about this effort even before we dabbled with a Proof of Concept. We also set the expectation from the get-go that even if we failed in "this" effort, we will be taking away valuable learnings for our "next" effort. This created a sense of urgency and accountability within the different teams while creating a safe environment to learn from failure. After this, we adopted what we call the "Rapid Prototyping" model - move from PoC to Phase 1 to Phase 2 in a quick and efficient manner. Get all teams (including non-engineering) on board, time-box the effort, fail fast, iterate fast, and deliver increasing value over time. In other words, don't overthink - commit to action and plan around it. I had to make them think and plan on how a model will be deployed into production, monitored, and get feedback to improve the model further from the beginning as opposed to just a theoretical approach to modeling.

The third step was all about execution and process. With Machine Learning projects, we do not even know what the possible outcomes can be, and it's even harder to explain the outcomes to higher-level executives. The teams need to make progress, and the CXOs need to "know" that progress is being made without needing to fully understand the details.

Lessons learned

  • Failure is a great teacher and creating a safe environment to fail and "learn" valuable lessons resulted in more accountability and less risk aversion. But fail-fast, put guardrails to prevent the same mistakes, and know when to cut your losses.
  • Good enough is good enough, so committing to action and creating a good product in a reasonable timeframe is much more valuable than creating a great product, but much later.
  • Cut through management layers when needed. One might be the manager of managers (or an executive), but if you are the best person for the job, feel free to cut through the bureaucracy and directly lead the effort. You will also learn as much as you contribute to this process.

Related stories

How to Introduce a New Technology to Your Organization
27 September

Pete Murray, Principal Software Engineer at Electronic Arts, recalls his efforts to introduce a cutting edge technology of that time and how that was intrinsically connected with his personal growth as an engineer.

Dev Processes
Impact
Internal Communication
Convincing
Pete Murray

Pete Murray

Principal Software Engineer at Electronic Arts

Getting From What to Why
27 September

Pete Murray, Principal Software Engineer at Electronic Arts, explains how he successfully solved a long-troubling problem by applying a root cause analysis.

Dev Processes
Productivity
Impact
Pete Murray

Pete Murray

Principal Software Engineer at Electronic Arts

Setting Guardrails and Containing an Increase in Cloud Costs
21 September

Michael Mac-Vicar, CTO at Wildlife Studios, dissects how to set guardrails that would contain the exponential increase in cloud costs.

Dev Processes
Productivity
Michael Mac-Vicar

Michael Mac-Vicar

CTO at Wildlife Studios

Outcomes Before Outputs: Measuring Engineering Performance
14 September

Marian Kamenistak, VP of Engineering at Mews, explains why EMs shouldn’t be measuring the output of a team or individual engineers, but the outcome of the whole team.

Impact
Productivity
Marian Kamenistak

Marian Kamenistak

VP of Engineering at Mews

Get More Done by Working Less
14 September

David La France, VP of Engineering at Kenna Security, explains how managers can level up their skills and scale in their roles by learning to work less, but smarter.

Personal growth
Delegate
Impact
Productivity
David La France

David La France

VP Engineering at Synack

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.