CTO Straight Talk - Issue 2 - 49

to mention they all speak the same

in ways I never would have done,

tension. But what I ended up saying

language really well. Facilitating

using job titles that never would have

to the project guys was, "It's your

brainstorming at the local level

crossed my mind. They will work

project, so you decide for us what

often leads to great ideas that I can

different hours, and in different ways.

is the best way to achieve it" - and

then gather, share, and put forth for

They will rise to the challenge, and

that's what they came up with and we

evaluation by the larger group. As a

they will implement their own ideas.

supported it.

One example that comes to mind

Situations like this popped up during

immediately is our recent rollout of a

my time in China, too, such as when

cloud-based radio access controller in

we were developing heads for the top

the Middle East. We primarily built

of wireless radio towers. When you

the product in North America, and

deliver a product in North America,

my expectation had been that the

your customers expect that product

rollout would follow along the lines

to work, plain and simple. They

we traditionally use there - build,

do not expect you to deliver patch

Think globally, customize

deliver, and put a team of experts

loads and fixes and corrections and

locally: Establish a clear ownership

on the ground to help with the

versions 2, 3, and 4. But in China, the

for product development so

implementation. But our Middle East

expectation is almost the opposite.

everybody everywhere is moving

team said, "No, no, no, that's not how

in the same global direction. This

we're going to work."

result, we're able to pick the best of
the best ideas. People will speak up
if they're in a comfortable
environment, which very often isn't
a corporate conference room. I often
find just sitting around the table and
saying, "Who's got a good idea?" just
doesn't do it.

means coming up with a baseline
product and then allowing local
customizations for different markets.
With this approach, you can apply
ideas where they make the most
sense and speed time to market
by eliminating back-and-forth
discussions about overall product
direction. If you have too many
diverse ideas and no clear decision
makers, you can spend an awful lot of
time just talking.

wobbles a bit. They'll try it out, see

deployment chose instead to bring

what they like and what they don't

in the developers and assigned them

like. They do this so that they can go

to work together with customers

as fast as possible, and sometimes

on customizing the product to

even before we're at the point where

their specific needs. That was a

we think the product is ready they

very different model for a product

say, "OK, we're going to go ahead

introduction than what we'd

and deploy it, and you can fix it

established in North America, but

later." And you have to go along with

it proved an absolute success. But

this different approach to product

that's not to say we would achieve the

development because if you don't

same level of success if we put it into

you'll be too slow for your customers.

play elsewhere. If I were to try that

Sometimes the best thing to do is

approach in, say, Germany, customers

tell people what result you want and

would say, "What is this mishmash

let them decide how they're going to

of people that you're placing in my

achieve it. If you pick the right people

offices? I want to see people who

and you give them that freedom,

are experts in field support and

they will work in ways that you

implementation, not a bunch of

never expected. I definitely saw this


India, as well, where I also do a lot
of work. When given flexibility, I've
seen people will organize themselves

give them a product even if it's still

The local guy in charge of the

Give local teams autonomy:

happen in China, and I've seen it in

Chinese customers demand that we

Generation Gaps
While we can support a lot of
customization when we introduce
new products into a market, where
we can't do it - and where it can
lead to conflict sometimes - is in

I admit that I was hesitant at first.

the core development process. We're

After all, putting developers with

stringent about how our developers

customers has the potential to create

write code, inspect the code, and run

CTO Straight Talk | 49


Table of Contents for the Digital Edition of CTO Straight Talk - Issue 2


CTO Straight Talk - Issue 2