Professionals: The silent assassins in cross-functional teams

Anders Haugeto
5 min readOct 3, 2018

Let go of your work methods. Keep your skills. See where it takes you.

Coders, designers, business developers and other professionals all bring “native” work methods to a cross-functional team. Such methods create major obstacles:

  1. They create fake progress
  2. They create bottlenecks for progress
  3. They induce groupthink

Fake progress is when team members are getting a lot of work done, but the work they do doesn’t benefit the product. It may even do harm to the product. Bottlenecks come when we wait for each other to finish something of value. The more protective we are of our individual contributions, the more likely we are to become bottlenecks. Groupthink is when we stop learning as a group. We may have progress in what we build, but not in how we think.

In my experience with cross-functional teams, different work methods are behind many of these problems. I've been puzzled by how professionals, even when they realise what's happening, persist in their way of work. I think we see this behaviour because we shuffle work method and skills on to the pedestal we know as professionalism.

Most occupations have an inherent business model. It's designed to benefit the occupation in itself, not to collaborate effectively with other professionals. To take an example: A musician builds a repertoire, and then travels the world to perform it, over and over again, because learning the music takes a lot of effort, but the same audience doesn’t want to come back and listen to the music they just heard. Hence, the business model of the musician is the tour. We can do similar analysis for most professions, including coders, designers and business developers.

Coders learn to define the requirements before they start coding, because we don’t want them to waste their precious (read: expensive) time on things that don’t matter. Designers learn to work through phases and build up knowledge before they actually design anything — for the same reason. Business developers learn to validate the business model before they start executing, because, despite their title, they’re first and foremost deployed as risk mitigators.

The business model of coders, designers and business developers is to minimise efforts. This where their professional work methods have evolved from, and they are all built on the same ideal: Get it right as soon as possible — preferably, the first time. (Most of us don’t, however, so a patch has been invented. It’s very misleadingly called to iterate).

Hence, the “professional” work method becomes some variation of:

  1. Understand the task
  2. Do your work (as fast as possible)
  3. Get the hell out of there

Even in the age of agile, we’re sub-optimising individual resources. We're letting obsolete ideals get the better of us. This is our silent assassin.

We get fake progress. It drives us to value form (how we work) over substance (what we produce). We favour things, even the wrong things, because they have been made in the right way. (And even worse: We become against even valuable things, because they haven’t been made in the right way.)

We get bottlenecks. It makes us downplay the importance of exploration and learning, and instead value the way of the professional. Example: With the micro-services trend, coders may feel compelled to rewrite the server and start scaling, even if what they have today still could serve thousands of more users. Their effort is demanding and delays other features, ironically even the killer features that could make the product take off (and hopefully create a need for micro-services). But what people oriented leader would want to overrun what seems like responsible professionals arguing their case, using proof from what other, more successful companies are doing? The coders have their rationale. They have their licence to become a bottleneck. (But the coders are not the bad guys. There are equally many examples of the same dynamics happening with designers and business developers).

We get groupthink. We downplay our mission, and favour a general, compromise-driven way of thinking and acting. If someone gets a crazy idea, the professional discards it because it’s not in his or her professional character to do something like that (other professionals may even make fun of them for trying). We place less emphasis on customer discovery, market experiments, active users, and so on. We become more oblivious to new perspectives and ideas that emerge in the team. Discovery disappears and groupthink ensues. We stop sharing insights, we drift towards selfish agendas, and we get continuously increasing misalignment. “In the beginning we were united around this compelling mission, but now, as things have turned out, I’m just here to code / design / execute a plan, and then get the hell out of there”.

Work methods are about planning and organising, skills are about seeing and acting. Work methods tell your skills: “Hold your horses, we’re not ready for that yet”. Like the myths we’ve learned to write a disposition before we start writing, to read the manual before we start playing, to get married before we have sex, to feel ready before we have a baby.

The beast we must defeat is practices, habits and rules that serve our profession, that aim to control our skills, that we unconsciously have inherited from peers and authorities in our fields.

Skills is becoming inspired. Skills is coming up with great ideas. Skills is knowing how to engage users. Skills is knowing how to visualise and prototype. Skills is knowing how to code, test and deploy a feature. Skills is knowing how to keep a product growing and keep delighting customers. Skills is seeing opportunities. Skills is making money. Skills is getting things done.

Great teams go beyond professional. They develop a style of work that is anchored their vision. They invite everyone in the team to invent their way of pursuing that vision. They’re uncompromising where they need to be, and flexible everywhere else. They’re confident, but open to impact. They’re adapting without loosing themselves. They’re teaching everyone who is interested. They’re honouring what they’re good at, and what everybody else is good at, while staying deeply humble to the learning they have in front of them. They’re always developing their deep, raw, awesome skills.

The “cross” keeps the assassin alive. Perhaps we don’t need it any longer. Perhaps the next step away from silo thinking, waterfall and wasted efforts is to go beyond cross-functional.

Let’s have a go with team and style and _____________ (fill in your vision).

Let’s see where that takes us.

Thanks to Charles Michelson for valuable feedback on this post (and thanks to everyone at Iterate for being so unprofessionally cool and creative).

--

--

Anders Haugeto

Founder of Iterate, Norway. A venture builder for platform and software companies.