"So Jo, tell me what it was like in the Mothership?" said Ian.
"Great, yeah. You know, like the 'one company' slogan, it was great." said Jo.
"Right, yes, 'one company.' Look, I want you to be frank, don't hold back, I need to understand what it was really like, off the record." Ian replied.
"My impressions?"
"Your impression of the differences between the two sites, between the groups in Dublin and the Mothership, how things really work."
"Ok, since you've asked" Jo said. "So you're familiar with the organisational structure here in Dublin..."Jo started to draw a sketch of Nordic’s organisational hierarchies in Dublin and at Mothership in Scandinavia (Figure 1 below).
Ian started: "In Dublin the feature set (FS) teams report into one of the the SysArch committees who report into the Release Div (Unified Systems Release Division) and Subsystem Group."
It's a bit flatter at HQ" Jo continued. "SubSys (Subystem) teams report into the local Subsystem Group, the Release Div there seems to work more like a service group. The Product Architecture Board sits at the top of it all of course, same as here."
Figure 1 Organisational arrangements at Mothership and Dublin
Once she had started talking Jo found she had a lot to say about the differences, between working in Dublin and at Mothership.
(design)
Something I didn't expect while I was there; the SubSys teams, although they're like our FS teams, they manage whole code blocks rather than just down to feature level. Mothership's SubSys teams manage the feature deltas so they also manage old versions within the team. My experience of the approach in Dublin couldn't have been more different. In Dublin SysArch keep the feature design deltas to themselves, SysArch hand down design documents with feature work specified from 'soup to nuts', engineers have nothing to do, SysArch have done it all - "here's how you prep, here's how you deliver, here's how you pass the exam!" Let me put it this way... On my team at the Mothership, the design document might be a 'use case' diagram and a flow chart, a picture and two sentences. I had to talk to the others to get anything done, there was so little detail to the design documents it was scary! Contrast this with Dublin, a design document for feature deltas is massive, 300 pages. One of Dublin's SysArch told me "I'm proud of our design docs, I really am," but 300 pages for one subsystem? You can't read it!
(support and bug tracking)
In Dublin some FS teams can avoid getting involved in supporting old versions at all, Support chase down the engineer who touched the code, who then hands over to the build group and then Test; the process is managed by Support using the issue tracking system. Mothership use the same issue tracking system but SubSys engineers rotate on bug fixing and the assigned engineer follows a problem through to its resolution. In Mothership the bug 'stays on you,' but of course the SubSys team is there to back you up because it's ultimately the team's responsibility. The way it goes in Dublin - the bug bounces from one person to the next, from one team to the next - Dublin's strength is the strength of the system process.
(test and support engineers)
What I thought worked well at Mothership was having a test engineer and a support engineer working on rotation in the SubSys team. In Dublin the support and test groups maintain an almost clinical separation between themselves and the engineering teams; it leads to a bit of finger-pointing at times. In contrast at Mothership the rotation gives the engineering team a 'tame' tester and support person, there's no delay in getting feedback. I also heard from the test and support guys that they learnt more this way, about new features, or if there were problems later on they'd have a direct line into the engineering group.
(release)
There's no appreciable difference between the sites in how product is released. To me it felt like the exact same process globally.
(overall)
Overall I think Mothership's SubSys teams have a lot more autonomy, that's not to say it's better. Sometimes it's just plain scary, it feels like you've got complete authority but the responsibility can be daunting. They relied on you going out and figuring it out for yourself. On the other hand, Dublin's FS teams often don't have a lot to do because the guys in SysArch have done all the design thinking for you. I think it's this way because we hire so many graduates straight out of college, inexperienced. At Mothership the teams are definitely older, more mature; a team of 20 might have 5 junior or graduate engineers whereas in Dublin it would be 10 or more. Sharing information, but also learning, is always the problem. In smaller groups I think it works better, knowledge growth. In Scandinavia we had set it up, that mix of senior and newbie, smaller groups to learn in.(the 'Ask')
Jo paused, surprised at how much she had to say on the topic and at how different the two sites were in spite of them being the same company; 'one company' as the corporate vision described it.
"So Ian, why the interest?" asked Jo.
"Well... this is just a 'heads-up' as they say Jo but next quarter expect to hear head office announce that your team's code block at Mothership, plus a few others, will be relocated here, to Dublin." said Ian.
"Outsourcing to Dublin?"
"In as many words."
"But the teams at Mothership, what'll happen to them, they'll think I knew all along? And how's it going to work in Dublin?" asked Jo.
"Don't you worry about Scandinavia," said Ian, "but as for Dublin, you're going to be in charge!"
"Me? Responsible for bringing a large complex feature set from head office to Dublin?"
Notes:
*1. To illustrate the growth of data services over mobile consider Vodafone's 2010 Q3 mobile data revenue figures which exceeded SMS/MMS for the first time (article on The Register)
Nordic's global operations employ anywhere between 100,000 to 150,000 people around the world.
Questions/problems:
Transferring knowledge, how?
Is it necessary to reconcile the very different styles of working at the two sites?
Will the Scandinavian style of working translate to other sites?
How should they organise transplantation of product team/responsibility/activity from one site to another?
How should they manage transition?
Is cultural distance a serious issue or just a background characteristic or something else?
Are other sites viable?
Why Dublin?
Is this a near-shore sourcing arrangement?
The transfer seems to have high operation risk. Is this a fair statement?
What is the benefit of going from Scan to Dub
The transfer has low/moderate structural risk - non-codifiable process but same organisational family.
Are these really in fact complex and problematic business process? Or not? Justify...
Does identity affiliation and professional standards make transfer easier?
What skills, attitudes, structural, cultural aspects work to enable the process?
Problem of practices (culture 500 pgs) use radical exasketch?
Knowledge transfer problem may be overcome through tacit transfer occurring through interchanging team members.
The differences between Dub/Scan aren't between right/wrong; both work well in their context.
Does code need people?
Is the process model excessive?
Should the company consider open source approach?
Is the painting by numbers approach a misconception or a brilliant method for deconstructing difficult technical work?
