Back to resources

Introducing the Agile Mindset

Company Culture
Agile / Scrum

13 August, 2021

Joseph Gefroh
Joseph Gefroh

Director of Engineering at HealthSherpa

Joseph Gefroh, Director of Engineering at HealthSherpa, uncovers how he helped introduce the agile mindset that places a key emphasis on adaptiveness and the ability to operate in ambiguity.

Problem

One company I joined came out from a hyper-growth phase during which we grew in a single year from 50 to 350 people. I was hired at the tail end of that phase to lead the engineering team, which was formally under the Product organization. It didn’t take me long to learn that most engineers had a rigid mindset that would impede their performance. They expected that they would be given detailed, explicit, precise requirements, and if any of these requirements changed or were incomplete, they would start complaining to any and all who would listen.

That gave rise to a worrying animosity between the product and the engineering team. Some of it also spilled over into our interaction with the design team because our engineers would demand strict requirements and would only deliver on them exactly as written. When there would be flaws in the system or technology or unaddressed gaps, the product roadmap would move to the next item leaving those things unaddressed. We ended up with significant tech and design debt, and products below even the standards of an MVP. Consequently, most of our products failed in the market upon initial release.

Actions taken

I could tell that the mindset of engineers on my team would seriously hinder our progress. They didn’t understand nor embrace agility - a mindset that was iterative and incremental. Moreover, they didn’t view changes as something to welcome but something to oppose.

Another thing that was perpetuating the situation was that Engineering didn’t have its own identity. At the same time, they had no say on the product roadmap or what they would be working on next; they were commanded what to do by Product and not invited to collaborate.

I started by focusing on creating an engineering identity that was separate. I secured buy-in to separate Engineering from Product into its own department with its own reporting lines and budget. Once we were a team on our own, Product suddenly started to collaborate more - they had to, as they no longer had formal authority over engineers.

With great power came great responsibility. I had to undo the rigid mindset that had built up over the years in the engineering organization.

I coached the engineering team, noting that we couldn’t demand perfection of requirements and complete information when we operated in a complex environment of ‘we don’t know what we don’t know.’ The only way to learn what we needed to know was to act, deliver, collect information, and iterate. Therefore, I established a set of values that would lead to the behavioral change I wanted to see. The foundational value that ultimately drove our performance was continuous improvement. It was tied to believing that we were not perfect and we shouldn’t expect anything to be perfect - requires, process, people, or product. The only expectation we should have would be to change and improve over time. Any change entails a risk of failure, and I had to re-state that failures were good as long as we could learn something from them.

I also emphasized the need to adapt. We would not get complete information, we would encounter problems we never saw before, and we would have to be creative. We needed to build systems that would be easy, simple, and maintainable to use, and we had to deliver fast, which wouldn’t allow us to think too much about what would be the perfect solution. Establishing those values was critical in helping people shift their mindset.

We also altered our Career Ladders and had these new core values incorporated in the skills matrix and role descriptions, whereas previously, we were much more focused on technical skills. Creating new values and holding people accountable to them sent a strong signal to everyone on the team that we established a new standard.

When you define a culture, some people will opt in and some people will opt out. Some people decided to opt out, and we wished them the best.

The ones that remained were bought in; they embraced our values and wanted to succeed and thrive within the new value system. As a result, we got significantly faster in spite of losing 30 to 40 percent of our engineers over a period of six to nine months. We sped up our product development by 300 to 400 percent and reduced costs by over 40%, all due to the profound mindset shift our engineers underwent. We were able to fairly compensate the engineers that remained because of this, thanks to higher performance and more available budget.

Lessons learned

  • If you don’t give your team clarity and set transparent expectations of what good looks like and what it means to be successful in one’s role, you will end up hiring the wrong people. Hiring wrong people creates a number of follow-on problems relating to coordination, execution, interpersonal conflicts, etc.
  • Sometimes it’s better to add or multiply through subtraction by removing elements of the team that don’t want to change their mindset and don’t see value in adaptability. You will move faster with fewer people, and the team will be happier because they will not be held back by people who do not want to embrace change.
  • Identity is critically important for any team. The tension between Engineering and Product is necessary for both teams to operate effectively. When Product has formal authority over Engineering, it gives rise to an unhealthy relationship that benefits no one. Product is all about direction and will be focused on outcomes. Their lack of focus on execution and execution quality will make it difficult for your people. Product and Engineering should be equal partners but with distinct identities.

Discover Plato

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


Related stories

Managing remote first organization

4 January

I was hired at HUMAN in 2021 to manage a team that went from hybrid to completely remote working environment because of COVID.

Building A Team
Company Culture
Ahsan Habib

Ahsan Habib

VP Software Engineering at human

Facebook vs. Google: 10 Contrasts for Engineering Careers

7 December

This is a brief comparison and contrast of Google and Facebook, as a place for one’s software engineering career. Both can be amazingly good places for engineering careers. But both places can be misfits for otherwise excellent engineers. This is a short differential guide. [Originally on LinkedIn]

Company Culture
Michael McNally

Michael McNally

Chief Technology Officeer at GraphStax

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

High Performance Team in Action

13 October

A high performance team refers to “ a group of goal-focused individuals with specialized expertise and complementary skills who collaborate, innovate and produce consistently superior results.”

Managing Expectations
Building A Team
Company Culture
Feedback
Coaching / Training / Mentorship
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan