Andy Wynn discusses 'Organizational Structure and the Importance of Functional Interfaces in Driving Innovation', one of the many themes explored in his latest book ‘Cracking the Innovation Code’, published last month, and available on the Routledge website with a 20% discount using code SSM20, and from all good book stores.
Organizational Structure and the Importance of Functional Interfaces in Driving Innovation
One key aspect people need to appreciate in any business if they are to be effective in delivering successful innovation is how their role fits in with the wider organization. In other words, they need to know which cog they are in the machine of the business. When you appreciate what your role is there to do, and what it is not there to do, you can more effectively play your part. Yes, people understand there are R&D departments, there are sales departments, there is operations and finance, etc., but people rarely appreciate how all these interconnect, where ownership lies and where they need to support each other, and most importantly, where shared ownership is required, because that’s where the magic happens. Job descriptions are a good starting point for this, but we all know that the boundaries of job descriptions and role responsibilities can get quite fuzzy. In smaller organizations, it is normal that people take on a wider set of responsibilities than in larger organizations. This is great for personal growth and learning but can make it more challenging to know where one person’s job ends and another begins. This can lead to the classic problem of things ‘falling between the cracks’ if no one takes responsibility for an action because they thought it was some else’s job.
A culture of taking on several roles at once can be a good opportunity for a young ambitious person to take on more of the action, but can lead to conflict if they start overlapping activities with someone else in the organization. A similar challenge occurs when moving between businesses and between business cultures in your career. I found exactly this situation part way through my career, when I moved from a smaller ($60m turnover) business to a larger ($350m turnover) business. In the smaller business, I was used to having multiple responsibilities, and constantly taking on more as a way to further my career. I took this same attitude into my new role in the bigger company and almost from day one I found myself treading on people’s toes around the organization. After several weeks of observing some quite negative reactions, I discovered how unpopular this was making me with some of my new colleagues and so I quickly changed my approach to focusing more on the boundaries inherent within my job description. By not appreciating my part in the new organization, I was generating negative attitudes and affecting progress on several fronts. This is when I learnt that you need to understand your place in the business if you want the process of innovation to run as effectively as possible.
Application Engineering – the Technology / Sales & Marketing Interface
If we focus first on the interface between the Technology and Sales & Marketing functions, this is what is known as ‘Application Engineering’. Application Engineering encompasses all the activities that Technology and Sales & Marketing teams naturally work together on. Some of these activities tend to be technology driven exercises (e.g. non-standard product tailoring, reformulations of existing products, new designs) and some tend to be sales driven (e.g. product selection for customer applications, designs with existing products), and to help effective management of this interface function (and not let things fall between the cracks), it is important that the right person takes the lead, and the ownership, in these activities. Such roles can be assigned in projects by the project manager or by functional heads. I have seen first-hand what a critical role an Application Engineer plays in interpreting customer needs and acting as an effective liaison between technology, sales departments and customers. In the past, technology and sales teams would attempt to handle this function between them (or let it fall between the cracks in some cases), but in recent years the role of Application Engineer has become a standalone one in its own right and I believe this represents a pivotal change in our organizations, in orienting them towards more successful new product development and commercialization.
Process Engineering – the Technology / Operations Interface
The second interface area that has a big influence on successful innovation is the interface between the Technology and Operations functions, this is ‘Process Engineering.’ It depends how your organization is structured, but process engineering as a function tends to come under Manufacturing or wider operations line management, but is an area that requires special focus because I have seen on occasion how the process engineering function can head off in their own direction, in their quest for improving process efficiencies, sometimes in conflict with technology and R&D priorities. The function of Process Engineering, encompasses all the activities that technology and operations teams naturally work together on, such as new process developments to create new products, improvements in product quality, cost reduction initiatives through product reformulation or raw material changes etc., and process efficiency improvements. Things do not tend to fall between the cracks in this interface because the operations team tends to lead historically on all these types of activities, but the danger I have observed is when operations start leading projects on new process development (because they have the engineering skills), when the project is intended to deliver a fundamentally new product or new functionality or delivers a fundamental change to an existing product. This is dangerous because the project becomes process led (i.e. internally focused), instead of customer led (i.e. externally focused), and project meetings can get almost entirely taken over by discussions on the nuts and bolts of the engineering design, with the effect it is going to have on the product and functionality almost taking a back seat. I have witnessed in the past such projects splitting teams into opposing factions, with meetings becoming arguments about ‘my design is better than your design’. Once again, as with the other functional interfaces, if you want a successful outcome on these shared activities, you need to appreciate what is happening in the dynamics of your organization, look outward to put your customers first, and assign the correct functional leadership to such projects such that they do not get side-tracked by internal views of the world. Projects focused on delivering operational and quality improvements should remain operationally led, but projects that utilize new process developments to deliver new product developments should be led by someone who can keep the product functionality, the customer and the end user right at the top of their agenda.
Product Management – the Operations / Sales & Marketing Interface
To complete the picture, let’s look at the interface between the Operations and Sales & Marketing functions, which is Product Management. I have seen the role of Product Manager used in a variety of ways in different businesses, with the role being pitched at differing levels of seniority. Organizationally, the role is generally under the Sales or Marketing function and can be reporting into Sales management or vice versa. In some organizations, I have seen the Product Manager effectively be the business unit manager for the product range they are responsible for, with end of line responsibility for pricing, and at the other extreme I have seen them used as technical support roles for sales people, with no pricing responsibility at all. The Product Management function tends to be focused on managing existing products and their day to day delivery to customers, encompassing aspects of supply chain. Ideally, the Product Manager should have a broad understanding of the industry and markets they are serving, and is normally the best person to represent the customer in your new product development portfolio.
You may have noticed that there is another functional interface region in the simple model above that we have not yet mentioned. This is the area right in the center, where all of the three key business functions of Technology, Operations and Sales & Marketing overlap, but not only that, all the three interface regions we have already discussed overlap here as well. This is the sweet spot, this is where the magic happens. If you can get all of these functions working truly in harmony, all pulling together in the same direction, then you will be delivering new business growth. This central region is where innovation truly happens, and so I like to call this region ‘Transforming Technology into Profit’, which is where the title of my first book came from and the basis of the branding for our global consulting group, TTIP.
The functional business model described above, can be applied to any scale of business, whether it is a small single site company, a multi-site national company, or a large multi-national with multiple divisions. The basic structure of this functional model will always be present in any of these scales and complexity of business, but the split of resources present between each of the functions and functional interfaces will vary as different business decisions are made by senior management in relation to driving the organization towards delivering the business strategy, or a change in business strategy.
I hope this simple functional interface model and the examples I have raised on how things can go wrong, helps you appreciate that understanding and management of the functional overlap areas are absolutely crucial in delivering effective collaboration between departments and between teams when working together to deliver projects. Having an appreciation of the range of activities that are shared and knowing when to take ownership or hand it over are high level management skills that will stand you in good stead in your career.
This article is based on an extract from my book ‘Transforming Technology into Profit’, Book 1 in the ‘Innovation for Business Leaders’ Series.
These principles are extended further in my new book ‘Cracking the Innovation Code’, available for order now through Routledge (20% discount with code SSM20), Amazon and all good book stores
Dr Andy Wynn
Transforming science and technology into products and delivering them to customers requires effective management of the functional interfaces within our business to clarify ownership of each stage of the process and facilitate collaboration. And so, not only does a person need to understand their position in their department and in their wider organization, they also need to understand the part their departmental function plays within the business, and most importantly, how their business function interfaces with others. To help people appreciate this, I have developed a simple model of how business functions interact and overlap with each other, as shown right.
Many businesses build great competences in their underlying business functions, yet still fail to get their business to work effectively. This is because not only do we need good functional skills, we also need those functions to work effectively together for the whole business to work. In the context of innovation in terms of creating new products and services, for simplicity, let’s just look at the three middle functions in the model, as shown in the diagram left; Operations, Technology and Sales & Marketing. These three are all critical business functions, but success will only come if they work effectively and efficiently together in those areas where their responsibilities overlap. This is essentially about managing collaboration, and these interfaces between the functions are critical to making collaboration effective. The first step to getting the three functions to work together effectively is for those with functional responsibilities to understand and accept that these interfaces represent areas of shared responsibilities and that different functions need to take leadership on different aspects of the processes involved.