Introducing the Agile Mindset

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.