The holistic effect of team structure | Technology Radar Nov'16

Over the past few years,
more and more organizations

are realizing that
technology needs to be

at the core of their business.

And time to market
has become crucial.

The world now runs on
software, and we've

known for a long time that
creating good software that

is actually mostly a
people problem rather

than a technology problem.

So one of the things that
we're seeing much more

within our clients is a move
away from a silo'd development

organization, into
one where you have

teams that represent all
of the different skills

that they need working very
closely with the business.

This actually is absolutely
the one or two pizza team model

popularized by Silicon
Valley companies.

And we're now seeing it
move beyond the Valley

and into the enterprise as a
strategy for organizing teams.

For quite some time
actually, there

has been this idea that
IT is a cost center.

We should think
of IT cost like we

think of our electricity bill.

Building domain centric teams
that are cost functional

means that you cut
down on coordination

across silos for the most
common kinds of change

that you have on projects.

And you get much
more interaction

between people who have a deep
understanding of the domain,

and the technologists
that are supporting

that differentiation.

And the closer you can get those
two groups working together,

the more opportunities you
have for creative ideas

that neither group could really
come up with in isolation.

When you have a group of humans
designing some technical thing

like software, the communication
structures between humans

end up getting replicated in
the software, which has now come

to be known as Conway's law.

We're seeing more
and more emphasis

on what we're calling domain
centric architectures.

Where teams are
really focusing on,

what is the common unit
of change on projects?

We're seeing this
team structure effect

has a huge impact on
productivity, mostly because

of coordination cost.

There are technological
underpinnings

that allow us to have a much
more holistic team structure.

Some of those underpinnings
include things like,

self-service cloud platforms,
and architectural patents

such as microservices that
allow much greater autonomy

between teams.

Well our experience
of introducing

particularly new
structures or new processes

into organizations is
you need to start small.

You need to find a pilot.

Treating that as a
product, figuring out

who your internal customers are,
or even your external customers

for that product, and
then really giving

those teams autonomy over
how they build and run them.

By getting people around
you to buy into this

and starting to demonstrate what
the possibilities are for this,

that's a terrific
way of demonstrating

the value of something
on a very small scale.

And doing that well means
that you can cut down on a lot

of incidental friction
that you've created within

your organization because
of increased coordination ,

and actually get down to the
business of just building

software.

[MUSIC PLAYING]