How I learned to embrace the unknown and manage a team without direct experience

When I began managing teams, I started with the team I developed software on. This meant that I knew the domain well, and was intimately familiar with the actual software and systems. Later, I moved to a team where I had limited experience with the actual code, but it still supported my old team and used a similar stack, so I was able to adapt quickly and understand it well. Recently, I jumped to a new team in a completely different domain with very different software, making it impossible to fully understand it quickly. As my first experience managing a team without hands-on expertise, I learned a lot about managing without hands on knowledge.

For years, I worked on software at Audible including the website, services, and later, iOS and Android applications. All of this work supported direct customer experience features, running in real-time. The software I worked on executed millions of requests as customers interacted with the features, and if something broke, it was easy to detect as it would either mean high latency or high errors. As a regular user of Audible on my daily commute and while running, I knew the product well and could rationalize decisions as a user based on what I wanted to see or have the ability to do. Moving around between teams involved a slightly different area of focus, but in general the technology was similar and the domain was related.

Moving to Amazon’s supply chain optimization technology forecasting meant a huge shift for me. Not only was the technology different, the entire domain was a huge shift from anything I’d done before. I now managed a team that included research and applied scientists developing statistical and machine learned models built upon years of academic research and learning as well as business intelligence engineers, involving another entirely different skillset. Beyond that, my work now supported decisions made about the supply chain, a field with tremendous amounts of research and study on that I have never focused on. Additionally, the customers are internal stakeholders within various areas of the supply chain, so the systems support a variety of their needs, but I will never be a direct user.

All of these changes precipitated a shift in my management style. No longer could I rely on my own hands on experience with the product or the software, nor could I rely on my own familiarity with the features and customer experience. I also knew I would never know as much about the science, data, analytics, and business domain of the supply chain as those around me who dedicated years of study to these, so I had to rely on building up my own high level knowledge enough to understand decisions, but had to rely on those around me to utilize their knowledge to make and defend those decisions.

One approach I quickly learned was to ask questions, a lot of them. As a new member of the team, it was easy to jump in with questions about nearly everything I heard early on to dig into these areas I didn’t know. I worried that asking so many questions might make me appear stupid, but I quickly realized that it actually made me appear interested and engaged in what the team was doing, making members feel appreciated. It was also a great way to fill in the gaps in my knowledge.

I also worked offline and outside of the office to fill in some of these gaps with resources from the team including documents and old recorded talks as well as online resources in these fields. I found Coursera very helpful in learning the basics of machine learning. I also found several great talks on Youtube about some of the statistical models and even some of the basics of supply chain logistics. Videos of some of the meetings the team members previously ran provided great insight into context of decisions and why certain choices were made. Documents, while sometimes out of date, at least gave a foundation to understanding some of the problems and challenges users had with the tools and begin to develop some thoughts on how to improve them on their behalf.

Another approach I found successful was conducting individual interviews and one-on-ones with users and stakeholders to get their perspectives on what worked well and what could be improved. I also asked about their workflows and what their responsibilities were, rather than just asking for feedback on the systems, believing that this would more likely lead to understanding of what they really needed, rather than just small improvements to what already existed. In the end, this approach of curiosity and question-asking didn’t just begin to fill in my knowledge, it also built trust with stakeholders that my team cared about them and led to some valuable conversations around how to enhance the systems.

In terms of the technology, another huge shift occurred in moving from a real-time web application stack to a more backend system where the data pipeline was perhaps even more important than the services. Having never worked on data pipelines, lakes, or ETL jobs, my knowledge in these fields was rudimentary at best. I still struggle mightily with the differences in this type of software, but one huge help was utilizing my network and learning from some of my former colleagues who worked in the data-warehousing space to give me some pointers. Establishing this network in the first place earlier in my career ended up paying large dividends during this transition.

Perhaps most importantly, I had to adjust my management style to accommodate these changes. I knew I couldn’t implicitly earn the trust of the team through in depth knowledge of everything. The rest of the team would be more actively engaged in the systems, and would hence know them far better than I ever could. Instead, I needed to demonstrate curiosity, learn as much as I could to make good high level decisions, and empower my team to use their knowledge to make the most important ones. The scientists would always know more about the science than me. I could never synthesize or compress multiple years of PHD research. Learning to step back and trust team members to make the kinds of decisions I was used to making wasn’t easy, but it has resulted in a much better ability for me to scale myself and for the individuals to grow. This additional trust encourages risk taking and experimentation, and I see better results from it.

I believe it likely goes against almost every manager’s instincts to cede control in this manner. Managers become managers because they are inherently knowledgeable and are comfortable making decisions. They are used to knowing their field deeply and making decisions with fairly complete knowledge. However, jumping outside of their comfort zone into a completely different domain is a great way to push boundaries and stretch, which encourages and allows for growth as a manager. The trick is to know enough that individuals trust their manager, and not rely so heavily on others that a manager becomes someone the individuals don’t believe could actually do the work if needed. Trust is probably the most critical aspect of a manager’s relationship with their team members.

I worried, and still continue to worry about the knowledge I have in my new domain. However, making the leap to such a different team has without question been the best growth opportunity I’ve had since becoming a manager and I believe I’m a better manager today because of it. While the unknown can be frightening, embracing it can actually be a powerful way to learn to manage without direct experience and knowledge, and done well, managers will earn far more trust and results from their teams. While there are still many days I feel like an idiot for now knowing my domain better, I’m learning constantly and growing in large strides as a result. I think every manager should take a similar leap at some point, probably when they are feeling most comfortable, in their career.