Mike Schubert

I have spent a lot of time over the past year (really over the last 20 years) looking at the keys to success and failure that have been experienced by certain technologies and platforms. Many product organizations take a kitchen sink approach to delivering features in their product. This can lead to a "jack of all trades, master of none" perception in the marketplace. It can also confuse users as to exactly a product should do. On the flip side, you have groups that release products that seem to be incomplete.

Right now I am a fan of Apple and its approach over the past decade to personal electronics. They seem to have taken the approach of delivering a chunk of value, letting people adjust to it, and then have the customers say "it would be really nice if this thing did x."  iPhone OS 3 gave us the ability to cut / copy / paste. This function point has been ubiquitous in computing for the past 2 decades, and yet Apple decided not to include it in the original release. The same is true with multitasking - even the Palm platform in the mid 90's allowed a form of multi-tasking (such as it was) and yet Apple it's waiting to the 4th generation of it's OS to make it available.

When you first look at this, you may think "Gee, they just wanted to lock in a monetary stream of upgrades." But if you think further, they have really been delivering fully baked features at the time they really become needed. When the iPhone app store first opened, there weren't enough apps with functionality that would make you want to multitask. Who knew how quickly apps would catch on that people would want to copy / paste? Apple has done a great job of delivering features at a pace that allows the ecosystem to adjust, and the customers to understand how to use it.

Hopefully, on the next generation of our intranet platform, we can duplicate this success. For now, I'm calling it reductive feature design and I think that it can be viewed through the lens of technical and organizational readiness. If either of those two factors truly aren't ready to introduce the feature, it should be removed from the version stream and placed into the backlog. Now to pitch it to the rest of the folks and see if it flies...

3d person and globe
Originally uploaded by 姒儿喵喵

Over the last decade, many lessons have been learned about sending software development work overseas. These lessons have been documented in books, magazines and blogs the world over. Many lessons are similar to those that you would face if you chose a consultancy down the street from you. Others are simply lessons of doing business with cultures foreign to your own.

For those who have been working with offshore partners for a number of years, what I write here on the subject will be a "no duh" moment. Others looking to embark on a pilot of sending work overseas may think "this won't happen to me." Regardless - what I write over the coming weeks and years will be my observations and a sort of record of my experiences.

My thought for today is this -> It can be more challenging than it might appear. On the surface, the idea sounds great. You do the customer interactions, the requirements definition and design work - then turn it over to your partners to implement. But what if there are issues? When the work is done within 3 timezones of yourself, getting people together to discuss the issue is very straightforward. Even emailing back and forth is possible when the timezones are close.

But the problem with sending work 12 timezones away is the lag in time. If there is an issue that impacts delivery dates, resolving it via email is a guaranteed way to miss your deadline. One model that has worked well is to use an "onshore coordinator" - a technical individual that works for your offshore partner whose job is to interface with you and the offshore team and work across time boundaries to get issues resolved. 

One final thought on this matter is this -> no matter which of the above options you take, whether you have an onshore coordinator or you are up at midnight on the phone - YOU are the bottleneck. It may be that the team overseas is incompetent, but it's your job to make them competent (or take some other action). If systems are unreachable, requirements are unclear, or deliverables are of poor quality it is your responsibility to remove the obstacles and rectify the situation. If you execute well, your chances for a successful program are higher.

MARTIN COOPER - Inventor of the Mobile Phone
Originally uploaded by Mark Berry - Photographer & Graphic Designer

Over the past several years, mobile computing has exploded on palm sized devices. The most obvious of these is the iPhone, but numerous other providers (HTC, Motorola, etc) are hot on the trail as Google and Microsoft also provide app stores. For individual developers, the choice of platform is usually a personal decision and one that is clear cut. For the enterprise developer, this choice is usually dictated by external factors as well as management.

In sizing the requests for next year's initiatives, there was a separate project request to enable mobile access to some core resources on our intranet. Mind you, there are some heavy initiatives that will be changing the information architecture of the site, as well as potentially the content management system. When you are making those kinds of changes, it would be nice to design in mobility from the start.

My dilemma is this - it is more expensive to design in mobility considerations than to ignore them completely. Produce too high of a price tag and the project won't make it past the budget review (or will get slashed in the process). With the separate mobility project, I have to make assumptions about the current state of the platform - so I have to pretend that I didn't size in mobility considerations into the other request.

Whatever the case, I will have to design for mobility regardless on whether that particular feature gets funded. That's just the right way to do it in my mind. You can only go into Best Buy and look at those fancy High Definition television sets for so long until you bring it into your house. And if you aren't set up with the baseline infrastructure to support it (HD programming, HDMI cables, mounting hardware, etc) it will end up costing you considerably more than the price tag on the TV indicated.

Surely there must be an art form to the pre-meeting because some people get it, and others clearly don't. Deep down, I know they serve their place. They can

1. Serve as a means to unify a team and present a common front to your customers or a large audience
2. Provide a forum to agree on an agenda for a high stakes (execs, expensive consultants) audience
3. Give a voice to team members that may not raise issues with 'outsiders' around

Unfortunately, I feel like these things are being abused. Over the past few weeks, I have been invited to several ONE HOUR pre-meetings or pre-calls. If it's going to take an hour for these people to figure out what I am asking for, either I have gone way off base or I did not call the right person. This seems particularly true for sales calls. Am I wrong to think that a couple of emails could handle this? I have some other scenarios that I will hide to protect the guilty.

There was a terrific article written a few weeks ago called Maker's Schedule, Manager's Schedule, and it summed up nicely how meetings are necessary and detrimental all in the same vein. For me, I am part maker and part manager and I try to be cognizant of the detriment I bring to the makers with my meetings. Mondays are my status days, where 3-4 different groups are assembled for various projects, status is discussed and issues are raised. This is a burden on the technical staff that performs project delivery, but it's predictable and gets blown out all in one day. There are 4 days left for them to "make" stuff. 

During a recent software launch, we added a screen that presents an updated technology agreement and put accept/decline buttons on it. After you decline a certain number of times, your manager starts to get an email. The agreement is not actually optional - all users must accept it just like they must accept the email policy, the technology usage policy, etc. By displaying a "decline" button, we inadvertently made it appear optional.

Perhaps we should have given them a "Defer" button and allow them some number of grace logins before they had to accept. This would've given them time to print out the agreement and review it so they understood what they were reading. However, just like the shirnk wrapped EULAs that come with software, this agreement is mandatory and should have been positioned as such.