January 12, 2021
Pip Courbois, VP at BLEND360
Principals in Engineering are high-ranking individual contributors (IC) who divide their time between developing enterprise-wide strategy and architecture, and coding for a team. They are authorities in their field and are looked upon as technical leaders. Typically, Principals are at the Director or Senior Director level and don’t manage people. I served as a Principal twice in my career in Business Intelligence and most recently, in Data Science.
In this article, I describe an agile approach to Principal Data “Scientisting.” Instead of sitting with a team long-term, my strategy was to provide guidance and oversight to projects. I joined teams short-term, at pivotal times during their lifecycle, and helped them navigate difficult decision points. The objective was to help where I could have the biggest impact enterprise-wide. I denoted this approach project-mentoring because, although I was facilitating a team toward success, I used a lot of the same tactics that are employed in a mentor-mentee relationship.
This approach is a powerful way to leverage a principal’s experience and expertise across an organization. CAOs or other senior executives with large data science teams should consider organizing their teams and using their principals in this agile way. Principals should consider building up a diversity of skills that enables them to approach their jobs in this way.
The agile-IC model I am describing isn’t for every situation and you should determine whether it will work within your organization, depending on the organizational structure, your culture, and your products. In my company, the second Principal Data Scientist sat with a team long-term and assumed a much more traditional Principal IC working model. That team included a complex piece of software that required deeper understanding and long-term engagement.
Choose high impact projects with a high degree of technicality. Initially I envisioned the agile model as finding fires and putting them out: identifying projects at risk and turning them around. However, it quickly became apparent that this was not a good idea. Projects at risk are difficult to turn around and working with them rarely paid off. After a few dead ends, I changed direction and focused on big impact projects. That is not to say I did not engage with at-risk projects, but I took a different strategy with them. I found that I could have a larger impact by helping big projects move faster, have even a bigger impact, and gain adoption throughout the organization.
Mentoring projects follows the same general guidelines as recommended for mentoring people. Before you begin you should define and understand what you and the mentee want to accomplish, define what success looks like, create a timeline, and an exit strategy. This section describes the many different roles a principal can take when helping a project.
Before jumping in, assess where can you have the biggest impact. Talk to the manager, talk to their manager, talk to the senior team members, talk to product managers and other people familiar with the team and the project. Identify the best role (or roles) you can fill to help the team succeed. This assessment should be a team effort, you should be transparent and get consensus about how and where you are going to help. Make sure that everyone understands what success looks like and you have an exit strategy and dates. And then, get to work.
Here are some of the roles I have filled in project mentoring:
I found this agile approach to suit data sciences well. In data sciences, the methodology and technology are constantly changing making it difficult for teams to keep up. Data science is often project-based, and teams are working on multiple projects concurrently. Data science projects are often high impact but owned by small teams. Data science projects also have a lot of dependencies: data dependencies upstream, technology dependencies, and integration dependencies downstream. And finally, rarely do data science projects include product-managers, technical project managers, and other organizational roles that engineering teams rely on.