Boost your digitalization: cross-functional teams
Image by Gert Altmann from Pixabay

Boost your digitalization: cross-functional teams

When I was 14, I started to work in a local supermarket. That was actually not legal, but family connections and some creative managing of practicalities caused me to stomp around there anyway. The guy who got me introduced to the secrets of filling shelves, pricing goods and unloading trucks had the habit of not just telling me what to do but also how to do it. For the first few hours, that was OK, but it rapidly started to rub the wrong way. Although I thought I was unique, it didn’t take long until I figured out that nobody likes to be told how to do their job.

The funny thing with traditional organizations is that telling people how to do their job is at the heart of how these companies work. This goes back all the way to Henry T. Ford, who managed to build a highly productive, scaling car factory largely using uneducated labor. The innovation was to slice the end-to-end work task into small pieces so that each individual could do their little part without needing to understand the whole. The idea was that the intelligence was deployed elsewhere.

Even if most modern companies would claim that they’ve left that kind of thinking behind, in practice quite a few of the basic principles stay the same in functional organizations. Even in R&D, the notion of mechanics, electronics and software doing their respective things with a governance layer of systems engineering still is the norm in many organizations.

For highly repeatable work, the separation into small slices that can be performed by an individual remains a very efficient way of accomplishing outcomes. With one caveat: we’ve become very good at automating anything repetitive. This means that if work is repetitive, it has almost certainly been taken out of the hands of humans and given to a machine of some kind.??

Once you digitalize as a company, the work that isn’t automated and remains in the hands of humans is work that’s not repetitive but rather creative. And of course, it doesn’t exist in isolation but needs to integrate into whatever already exists, requiring a holistic view. This is where cross-functional teams shine. A cross-functional team, either project-based or permanent, is asked to focus on achieving a specific outcome but isn’t told how to arrive there. Instead, it has all the skills and capabilities inside the team to hypothesize, plan and execute to achieve the intended outcome.

In digitalized companies, everything that can be automated is automated to minimize human involvement in anything repetitive. This is of course great for humans as we hate repetitive activities but also good for the company as the risk of human error is reduced as well. It allows us to instrument and measure the automated processes so that we have a complete and quantitative overview of the performance of the business. This overview can be used to identify the improvement areas with the highest potential.

Cross-functional teams are then asked to “move the needle” on one of these high-priority areas (while avoiding significant negative effects elsewhere). Rather than telling the team how to do their job, we trust it to have the skills and capabilities to figure out by itself how to proceed. The evaluation of the team is then no longer a qualitative and often rather random sample of the way it’s working but rather a quantitative one as the team either moved the needle or it didn’t.

Some may feel that giving teams that much freedom causes a “free for all”, “let a thousand flowers bloom” kind of situation, but in practice, teams are focused on the highest-priority areas for the business and evaluated on accomplishing tangible, measurable results in their area of responsibility. The concept should be that the team owns its own outcome and is unable to hide behind excuses outside its control.

Digital companies automate everything repetitive and use humans for creative tasks. By instrumenting the business and measuring performance quantitatively, teams can be asked to move the needle on specific KPIs. To be successful, they need all the skills and capabilities to accomplish the intended outcome without relying on others, hence these teams are cross-functional. Due to the quantitative nature of goal setting, they’re highly accountable and incentivized to deliver on the indicated outcomes. As the saying goes, activity isn’t the same as progress. And many traditional companies reward activity, whereas digital companies tend to reward progress. What are you rewarding?

Like what you read? Sign up for my newsletter at?[email protected] or follow me on janbosch.com/blog , LinkedIn (linkedin.com/in/janbosch ), Medium or Twitter (@JanBosch ).

Baldvin Gislason Bern

Cybersecurity for embedded products

2 年

Love your reference to Henry T. Ford and the story of telling people what to do versus how to do it. A few years back I was talking with an academic about the lack of requirements and processes at the company I work for. He asked sincerely: "Doesn't that make you reliant on your employees?" I looked at him amazed at the question and finally answered: "Yes".

Jos Voskuil

PLM Coach, Blogger & Lecturer - passionate advocate for a digital and sustainable future. Connecting the dots.

2 年

In many situations companies reward visible activity. As you write: "As the saying goes, activity isn’t the same as progress" this is very true - and it should be extended by visibility. Therefore the home office can be bad for you carreer.

Markus Nordstrand

Systems Engineer at Kongsberg Automotive

2 年

The system layer is part of the physical architecture of the product, it is not neccecarily an organisational entity filled with people telling the engineering disciplines what to do. Every scaled agile framework I have seen uses SE "above" the team level though (even if some frameworks magically removes the SE role and allocates those WP's to a Chief Product Owner, usually with no SE skills. SAFe at least have the sense to include System Architect/Engineer at the ART level. Question: How do you perform creative work that requires several engineering disciplines and speciality engineering? This team will be too big to fit a scrum team and therefore must be scaled. How do you avoid reinventing the wheel in every project/product with regards to how to document these system level WP's if you do not have control over HOW the work is conducted?

要查看或添加评论,请登录

Jan Bosch的更多文章

社区洞察

其他会员也浏览了