How To Effectively Engage Engineering Principals

On Principals

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.

Situation

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.

Choosing projects to mentor

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.

Roles

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:

• The Motivator – Sometimes a team simply needs motivation. Maybe the team is suffering from burn out, have been working extra hours, had a recent failure, or had a liked person leave. Motivating can be a very difficult task and challenging for a sitting manager to achieve. Motivation is about people and to motivate a team, you are going to spend time with the people, as a group and individually. Share the project vision with each member, when everyone shares a common important goal, they build their own motivation. Listen and support new ideas and encourage creativity within team and individual meetings. Provide the team with the opportunity to own their project. Assign challenging tasks and provide teammates the opportunity to grow. And, of course, celebrate successes!
• The Technical Lead – The technical lead sets the strategy, tactics, and plans the project. This role also decides what methodology and technology is appropriate for the project. This role relies on the principal’s leadership skills and experience executing complex data science projects. This role requires system thinking and the ability to think in multiple scales from the big picture to the minute details and, of course, the principal’s expertise in the data science solutions, algorithms, and software.
• The Director - The director acts as an intermediary between the project and all of its stakeholders and dependencies. The director relieves the pressure on a manager by handling aspects away from day-to-day management, allowing the manager to focus on getting the project done. A director creates and sends out weekly updates and gives status updates to senior management. They also communicate with upstream and downstream supporting teams; doing things like removing upstream blockers and ensuring that the final data science solutions will work in the production systems. This role leverages the principal’s ability to communicate technical details with multiple teams and understand how complex systems work together.
• The Trainer – The trainer makes sure the team is ready and has the skills it needs to succeed at the project. A trainer might train an entire team in specific solutions, architecture, or skills or mentor individuals on the team. Because the trainer is mentoring a project toward success, learning while doing is the best strategy. The lesson should not be a theoretical treatise on the subject but a practical instruction on how to get the project done.
• The Scrum Master – Any principal should be an accomplished scrum master.
• The Individual Contributor – The individual contributor joins the team as a senior Data Scientist. This role is often the most fun; someone else must make the difficult decisions, they tell you what to do and you do it. When I am an IC, I often volunteer to do the boring, tedious stuff. But this is not always a good strategy. As with selecting a role, assess and decide where you can have the biggest impact.
  

Why this works

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.

‍