Context

Considering the latest developments in technology like generative AI (GenAI), neural networks, cloud computing and complex data, the strategy for organizing teams in tech projects must go hand in hand with these latest advancements.

There is little discussion about this topic which we consider as important as other factors that are well discussed by managers and present in the current literature, like best tools or AI models.

Although many can consider the execution of a product development as part of “product management[1]”, this strategy goes further than that as it changes more than processes, but the internal operating model itself and this strategic approach should be considered not only by product owners but also by any executive or manager trying to set teams up for success and have better leadership.

This strategy contemplates a wide spectrum of projects, ranging from innovation to operational, which depending on the case an organization might have radical differences when implementing.

The problem

One angle that has been overlooked for years is team deployment. Many organizations hire highly capable individuals and top talent but sometimes they set them up for failure due to inertia from organizations and culture; examples are “this is the way we have been doing this in this company, so why would we change it” so these high-profile individuals are set to work in environments that make their jobs difficult and projects unattainable.

Our approach and methodology is especially effective with inclusive teams, as it brings together different ways to solve problems and integrates intellectual and skills diversity in teams; so we cannot stress enough the fact that we need to plan how the team will interact in a project before starting the project.

One of the main reasons of project failure is mainly due to lack of consistency between the business model[2] and the way we deploy teams involving new technologies, and hence a number of initiatives can be delayed or never completed. Hence the strategy around deploying teams is a must for efficiency and success as well as the type of execution e.g. agile or waterfall.

Some areas are very conscious about the business’s potential as well as individual employees’ capabilities, but it is necessary to connect both in an efficient way.

One of the signs of a product manager is the ability to identify the right person for the right job; however, some managers and especially managers in technology think that people and organizations are naturally suited for any job and just by being in the team everything will work. This is never the case.

Our LIGHT Methodology

As the scholar Bruno Latour [Latour, 1988] sustains, the sociology of associations is a major component in science and engineering works. We propose that this concept applied to scientific work, can be perfectly extrapolated to a business environment and especially technical projects.

As put by [Christensen, 2000], “one could put two sets of identically capable people to work in different organizations, and what they accomplished would be significantly different”; this is due to the lack of a-priori strategy on the execution management.

A way to solve this problem is -what Latour calls- the sociology of associations; so, we took this concept and modified it so it is suited tech projects in business contexts, we call our methodology “Logic Innovation Groups and Heavyweight Teams” or “LIGHT”.

In order to thrive consistently in any kind of project, managers need to know their staff capabilities, but also, they need to know how to optimize those capabilities in teams and address the organization’s disabilities by deploying teams strategically; that is why we call this implementation management and we have observed that organizations would benefit hugely out of an “implementation manager”, which goes further than product management as it creates strategy.

In this article, we show some guidelines on how to do this, which we call LIGHT implementation.

In classic strategy theory, there are four main ways to organize teams to successfully land different kinds of tech projects see [Clark, 1992], [Christensen, 2000] and [Patanakul, 2012]. Where communication lines and reporting lines can change depending on the type of development or project, and according to this we can lay out teams as:

• functional,
• lightweight,
• heavyweight
• autonomous

The problem with the classic theory arises when we deal with new technologies that merge different teams and shape organizations and processes differently. To tackle this, our LIGHT implementation methodology contemplates 2 steps: 1) a general guideline using the classic strategic approach illustrated in the table below and 2) a hybrid approach that combines teams and individuals according to their specialization.

As a rule of thumb and general strategic guideline there are two main factors to take into consideration while deploying teams:

1) the type of project and

2) the interdependencies within the business processes.

Hybrid teams. Case study:

Consulting a major international fashion retailer on the implementation of a brand-new data system while developing models for product development at the same time, we started noticing major issues and delays. In addition, team members started antagonizing each other creating a non-friendly atmosphere.

Conversation with all levels of staff from scrum master, team members, and the main engineer, to product owners and other business stakeholders, led us to realize that it was not the system or individual capabilities of team members to blame, but the structure in which the team operated.

The team layout was a traditional scrum where the scrum master followed an agile methodology; however, business stakeholders worked under a waterfall scheme, the data science team was mainly researching, and expert engineers were fiddling with new technologies. Traditional ways clearly did not work.

The best approach was to create a hybrid structure adding elements of a heavyweight layout and autonomous design to our original lightweight team. The diagram below illustrates the hybrid layout.

The dotted lines and solid lines for some members and technical experts were integrated as consultants reporting to the EM, while data scientists still reported to the respective VP area but they were taken out of the normal scrum not to disrupt the lightweight engineering team. In this way we also merged Agile and Waterfall methodologies and made it work to our advantage.

These changes proved to be successful and not only did the goals were achieved but also the members got along really well.

And one more important factor was to marry up waterfall and Agile methodologies as one or the other would have fallen short for complex projects like this one.

Conclusions:

A strategic tech implementation manager covers 1) a traditional project manager, who knows how to deploy projects and 2) a product manager who also creates processes and 3) goes further than product owners and creates a new internal operating model which agrees with the business strategy and organization’s capability.

A strategic implementation manager oversees designing teams’ layout and merges Agile and Waterfall techniques to manage the execution. They must be aware of interdependencies and types of projects and be able to gather up these elements to adapt new hybrid operating structures within organizations.

• LIGHT methodology is an efficient way to set teams for success in a fast-changing environment
•  There is a need for a leveled-up manager above the project and product responsibilities: The implementation manager
• We must integrate a “strategic tech implementation manager” in the technical design of projects and product development
• For innovation projects and R&D it is necessary to reevaluate some of the business’s culture and ways of working, hence LIGHT method is most convenient
•  A key player to strategically change internal operating is the implementation manager

References:

Clark Kim B., Wheelwright Steven C., Organizing and Leading “Heavyweight” Development Teams, California Management Review, Volume 34, Issue 3, 1992

Christensen C. M. , Andrews K.R..Bower J. L., Hammermesh G. and Porter M.E. Business Policy, Text and Cases, 5th Edition, Homewood, IL, Irwin, 1982

Christensen C. M., Overdorf M., Meeting the Challenge of Disruptive Change, Harvard Business Review, March 2000

Johnson , M.W., Christensen C.M., Kagermann H., Reinventing Your Business Model, Harvard Business Review, December 2008

Latour B. Science in Action: How to Follow Scientists and Engineers through Society, Harvard University Press, Cambridge Ma., 1998

Patanakul, P., Chen J., Lynn, G., Autonomous Teams and New Product Development, Journal of Product Innovation Management, Sep 2012,, pp 734-750

[1] We consider a wider definition of product management, which includes ownership with tasks like envisioning, prioritizing and even changing or designing processes. Project management can be seen as a subset of product management, in which we can have several projects under the same product development.
[2] We are using the Johnson-Christensen business model definition, see [Johnson, 2008]