Cross functional leadership in product development

I’d like to take a moment and discuss cross functional leadership in product development. Let’s say we are working on the same product example I used before in my process post:

For the purpose of this discussion, let’s assume we are working on a hypothetical consumer electronics device, to be sold in the US. Let’s assume the product is a battery powered connected device, involving custom sensors and custom printed circuit boards (PCBs) inside custom plastic housings, has a cost of goods below $50 USD, and is targeting an annual volume of 10,000 to 50,000 units per year for the first 12 months of production.

The goal is to staff the program for success and maximize the performance of the project team.

In this example, we will need the following talents to bring the product to fruition:

Qualitative researchers

Industrial designers

Mechanical engineers

Electrical engineers

Firmware developers

Web and mobile software developers

Information architects

Interactive designers

Graphic designers

Data scientists

Database administrators

Software Quality Assurance engineers

Manufacturing engineers

Manufacturing test engineers

Sourcing professionals

Supply chain management professionals

Purchasing professionals

Logistics professionals

Production quality control engineers

Packaging engineers

Electromechanical technicians

… etc

In this type of environment, a silo mindset, where everybody stays in their comfort zone within their own functional discipline, will guarantee project delays and budget overruns. It is critical that we evolve a team structure, culture and dynamic that makes the team identify first with the broader team and the shared holy grail, instead of identifying first with their functional discipline and their daily tasks at work.

There are a few things to consider when organizing such a diverse group of people.

If you are the chief technical kahuna of this effort, the first thing to keep in mind is that you don’t need to know everything about every discipline. In fact it is not possible. You simply need to know how to find great people, provide a solid framework to coordinate work and trust each person to pull their weight. But you must know how to delegate work and gauge progress

It is paramount that the team is culturally set up to work fluidly across functional disciplines. For example, the mechanical part designer needs to have access to, and be comfortable talking to, the software engineer who will be writing the code to control the mechanism. The engineering disciplines need to be tightly coupled with the manufacturing disciplines from the get-go. This needs to be addressed at the top level – expectations need to be set about open communications channels by senior management.

Set up governance structures that fosters and enforces cross functional collaboration. For instance, consider generating a “scrum of scrums” standup meeting for leaders of individual areas to coordinate work at a higher level than the regular scrums with the troops.

Define goals and success metrics in terms of the overall program, not in terms of the individual team’s deadlines and deliverables. For instance, design release to manufacturing out of engineering is one measure of success for engineering, but the true measure of success is arriving at Mass Production with a good quality product. Avoid defining too many small goals that are specific to each functional discipline that may cause folks to optimize locally, but cause the program suffer globally.

Communicate broad program goals and context frequently to all team members to keep everybody in sync

When doing customer research, create an “observer” spot and rotate everybody through, so everybody gets contact with the customer and gets to see the end goal

Make it easy for people from different backgrounds build relationships. Some ideas:

Make project teams sit together regardless of discipline – co-locate designers, product managers and different types of engineers who work on site

Manufacture events where people will hear from somebody they don’t work with on a regular basis – e.g. organize a lunch-and-learn series and get different people to give a talk each time

Assign a project manager to create, maintain and continually publish an overall schedule with key milestones so that everybody, from the intern to the principal software engineer, knows where things stand and whether things are happening according to plan. This can either be a team member, a dedicated project manager, or the engineering lead (my preference).

Everybody does not need to be a full time employee. To stay lean, you can outsource large chunks of the work to experienced external contractors – however I would suggest you identify your core competencies and key differentiators, and keep those functions in house.

I have more thoughts and considerations regarding building, organizing and nurturing a product development organization that will be a topic for another day.