Behind the Scenes at Global-Roam

.

Had to chuckle one night last week when I saw (in one of the many books I am reading at present) the following passage:

When I was studying [about software] at [uni], it was common to talk to professors and students about new products.  We’d focus on what components these new software products used and how they compared against what could have been.  Value was … how much of the latest technologies they used.

Generally, we thought everything sucked.  Very few products survived our critiques.  We wondered why the marketplace was packed with mediocrity and disappointment.

We’d even invented geek conspiracy theories to explain the evil decisions, which we thought were made against engineering purity and thus made little or no sense to us.

Often, we’d focus blame on the marketing departments of these companies (not that many of us understood what marketers did).

Even in my first few years in the industry, the same kinds of conversations took place again and again.

Actually, it was more of a liberal dose of belly-laughter than just a chuckle, which brought a look of consternation from my wife.

I had to check the cover of the book to see if it had been written by one of the guys in our office, as it certainly sums up the core of many conversations I’ve heard internally over the past 10 years.

This is understandable, as our guys are (like the author) trained in IT and relatively inexperienced.  Hence they view the world through a “technology perspective”.

A paragraph later, we see the author’s Mea Culpa:

I was able to see my view for what it was only after I’d listened to some smart marketers and some talented product designers.

There is a bias toward the building of things, instead of understanding how, once created, those things will help the business or the customer.

This chapter of the book (Chapter 3 – How to figure out what to do) encapsulated much of the paradigm that I have been trying to impart on our development team over the past couple of years.

It was my failure to do this successfully, and the (lack of) results that followed that led to us completing Autopsy 1.

As the author notes (p51):

A project manager, who uses only one perspective and fails, might never understand what really went wrong.  His tendency will be to work harder within the same perspective instead of widening the view.

We are certainly guilty of this!

It was one of the reasons, for instance, that I needed to post (internally) about “What really happened with NEM-Watch 8”.

It was the fact that our team has taken only small steps, and too slowly, towards really embracing the “three perspectives” that has led us into the Autopsy 2 process – and has necessitated our search for a Chief Software Engineer (which will begin, in earnest, in early 2010).

.

1)  What are the Three Perspectives?

Whilst we could quibble about where the author has drawn the boundaries between the three perspectives, and the fact that he has ascribed only 3 – there is more value to be gained for us in understanding what he has to say.

(a)  Technology Perspective

The perspective quoted above is labelled the “technology perspective”.

Picture the stereotypical technologist (or beginner-engineer), and this will be the perspective conjured up.

Now, take a look at reality and you will realise that there are many “real engineers” who have a much broader view than just the technology perspective.

Indeed, it will often be these (more balanced?) engineers who deliver far greater value, as discussed below.

[Insert story about your favourite geek turned rich entrepreneurial company owner here]

Note that the book is very strong on making the point that there is nothing necessarily wrong with this perspective, just that it is only one part of what must be a bigger picture.

In particular, the book notes that.

…many important questions come from the technology view only:

• What does it (the project) need to do?
• How will it work?  How will each of the components in it work?
• How will we build it?
• …

---

(b)  Business Perspective

The author notes that:

When … teams are unaware of how their business works, many decisions made by management will appear illogical or stupid:

In particular, the book notes (p49) that.

…A good business perspective means that the team has answers for the following questions:

• …
• What will it cost (people/resources)?  Over what time period?
• What potential for revenue (or reduced operating costs) does it have?  Over what time period?
• What won’t we build so that we can build this? (i.e. the concept of “Opportunity Cost”)
• …

---

(c)  Customer Perspective

The author notes (p52) that:

This is the most important of all three perspectives.

Because the project is made to serve the customer (and perhaps serve the business, but only through serving the customers), it follows that the greatest energy should be spent on understanding who those customers are

I wholeheartedly agree!

It was for this reason in particular that I was very disappointed to hear conversations internally that flowed along the lines of the 3-stage Success Delusion back when we received some good customer feedback following from a beta release of NEM-Review v6 back in September 2009.

In particular, the book notes (p53) that.

The important questions from the customer view include:

• What do people actually do? (Note what we think they do, or what they say they do).
• What problems do they have trying to do these things?
• What do they need or want to do but aren’t able to do at all?

---

2)  Where Real Value is Delivered

The value delivered to customers comes from our ability to satisfy all three perspectives, simultaneously.

We have done a reasonable job at this with some of our products (like NEM-Watch), whilst others have been flops (basically because one-or-two of the perspectives has not been properly covered).

To date, the Customer and Business perspectives have largely come from me – and that’s just not scalable, nor sustainable.

It follows then that the value of any individual person increases non-linearly for each perspective that that individual can lay claim to “own”.

Rather than being a matter of 2+2+2 = 6 (in terms of value) it’s probably truer to think of it as 2²² = 16.

Hence, the more “central” a person is within the company (in terms of their organisational responsibility, and value delivered), the more of these perspectives they will need to be a master of.

Hence:

1)  Our Chief Software Engineer will need to be someone who already has mastery in all three perspectives; and

2)  Who can also assist in coaching/training our aspiring Product Managers such that they can also be masters within the next 5 years, say.

---

3)  Another Paradox?

Being able to hold these three perspectives in your mind is just one more example of how the most successful professionals can deal with paradox.  This is essentially a two-step process:

Step 1)  For most graduates when they arrive out of university, their view will be firmly in the “technology perspective”.  They first need to build up their ability to think with both “business perspective” and “customer perspective”.

For some of our people (those whose roles need it most), fostering these 3 perspectives needs to be one of the primary drivers for their Guru Plans.

Step 2) Once some real understanding (i.e. learning by doing) has been developed, then the challenge shifts to being able to think through all three perspectives simultaneously.

As noted by Ted Scott & Phil Harker, this type of ability generally comes much more easily with increased experience, and maturity.

One of the roles of our Chief Software Engineer will be to assist me in speeding our aspiring Product Managers up this learning curve.

---

4)  About the book

The book’s called “Making things Happen – Mastering Project Management” by Scott Berkun.

---

Tags: 10000 hour rule, Chief Software Engineer, growing pains, management of software company, personal development, strategic planning

This entry was posted on Sunday, December 6th, 2009 at 8:00 pm and is filed under Book Review, Management, Personal Development, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.