Back to resources

Building a DevOps Team and Re-Architecting the Product: A Matter of Priority

Dev Processes
Convincing
Team Processes

26 March, 2021

Sankar Nair
Sankar Nair

Vice President of Engineering at Novantas

Sankar Nair, VP of Engineering at Novantas, shares how he built a DevOps team and helped architecture the product when the business didn’t consider it a priority.

Problem

As an engineering team, we wanted to reduce the complexity of our code and deliveries and be able to deliver faster. We wanted to switch over our architecture to Microservices from the monolithic architecture. This needed us to have a completely redesigned infrastructure for our build and deploy process. As a B2B product company, our product usage patterns and loads were deterministic and were handled by the current architecture. Our systems were stable and did not have any client-facing problems. Product owners and senior leadership were happy with our release cadence and pace of delivery. The challenge, however, was to make others understand the value of investing in DevOps and re-architecture and making sure the transition is successful.

Actions taken

Rather than seeing things from a technology perspective, I presented the need for change from a business perspective. It was important for Product Owners and senior leadership to understand what they were gaining/losing by staying in the current architecture. Therefore, I focused the communications around the importance of attracting and retaining highly talented resources.

It was essential for us to come up with a multi-year execution plan with easily trackable and measurable milestones to let everyone know how we plan to make changes in a gradual and controlled manner to avoid business disruptions. I was particularly transparent that we were trying to make a lot of changes, but with the best interest of the organization in mind. It took many repeated meetings and significant convincing for us to have the budget allocated for these efforts.

Execution-specific actions

Starting small and not being overambitious in settings goals helped us start with the minimal budget and consistently show progress. We initially started with deployment strategies that were more suited for a B2C organization, but those were slowly getting very complicated for the use cases that we had. We were doing a transition to DevOps for the first time; so, pausing, thinking through, reflecting, and coming with a detailed action plan, and setting milestones helped with our execution.

As we understood things, they seemed to be getting more complex. We were open to admitting mistakes and taking corrective actions, which meant owning and announcing the setbacks to the wider group.

Lessons learned

  • Be transparent. We made a lot of mistakes in the process of setting up DevOps and rolling out our new infrastructure. When we did wrong, we were quick to admit it.
  • It is easier to sell your ideas when you focus on how they will benefit your stakeholders and the business.
  • Your strategic roadmap should have clearly trackable and measurable short-term milestones.
  • Don't be scared to admit mistakes and ask for help.
  • Be agile on your strategic roadmap and make improvements on the end state as we learn/progress more.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

Why You Should Take Technology Risks in Product Development

25 April

Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.

Innovation / Experiment
Product
Scaling Team
Dev Processes
Matias Pizarro

Matias Pizarro

CTO and VP of Residents at ComunidadFeliz

Why Documentation Is the Key to Success

6 April

Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.

Alignment
Collaboration
Productivity
Hiring
Team Processes
Henning Muszynski

Henning Muszynski

Head of Frontend at Doist

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.