There are many issues facing entrepreneurs in the Silicon Valley today. I've been living and breathing these issues ever since I founded my new company here in the late spring of 2004. To talk about all of them in one blog posting would be too lofty a goal, so in this posting, I'm just going to focus on what I consider to be the top two issues based on my experiences. I'll ruminate on the rest of them in future postings, as they come to mind or happen to me in real time. That's what's so great about blogging - I can write as little or as much as I want, whenever I want. The freedom to do so is liberating and quite energizing, I must say......
Sorry for going off-tangent, getting back to the issues facing entrepreneurs in the Silicon Valley today, I would have to say that money is hands-down the single most important issue. So Issue One is Money, or really, the lack thereof. All the entrepreneurs I meet don't have enough of it, and all of them are trying to find creative ways to get more of it. I'm not talking about finding investment money, because each entrepreneur has their own "special" approach for getting funding, either from family & friends, angel investors, or from the last resort, vulture capitalists.... I mean venture capitalists. I'm referring to money from deal flow, money for work performed or expected to be performed. I've talked to entrepreneurs at conferences and seminars, at networking events, at private lunches and dinners, at CEO forums, and in business meetings and phone calls, and the one thread that never fails to pop up in the same vein is the paucity, scarcity, and downright absence of money. I've had clients say to me "Zero budget, Jeff. Can we pay you after we've made our money?". This, after I'd worked on their account for six weeks. And I've heard clients offer "Money is tight. We'd like to pay you with a percentage stake in our company." That's great, but you can't put butter on it and stick it in a sandwich to feed your kids, can you? One of the best ones I've heard is "We'll give you a success fee." Okay, I'm game. From my Junior Birdman Decoder Ring that I pulled out of my kid's cereal box one day, I've learned that "success fee" is the 21st century way of saying "commission". Isn't that what vacuum cleaner salesman and used car dealers work from, a commission? I never heard of engineering professionals working solely on commissions, have you? Commissions are great, when added on top of other compensation like salaries, bonuses, or consulting rates, but commissions-only compensation make monthly cash-flow difficult in my business niche environment, where sales lead times are often six-to-twelve months. So money has got to be the number issue facing entrepreneurs in Silicon Valley today. Lack of it, and how to get more. Lesson learned? Always ask if there is a budget before spending any time with a prospective client! Don't invest too much of your valuable time with someone who has no intention of compensating you for it until too far out in the future.....
In my estimation, the second most important issue facing entrepreneurs in Silicon Valley today is gathering momentum for their start-up company. Going from a stand-still to 100mph in nothing flat is quite a feat, and you have to have the panache of a leader and the stomach for it. So Issue Two is Gathering Momentum. One minute, your company doesn't exist, and the next minute, you breathe life into it, and you naturally need to spread the word about it. First of all, how do you get people to take you and your business idea seriously? With hundreds of new companies coming on line, how do you make yours stand out above the crowd? How do you gather enough momentum to make your website attract eyeballs? With money in short supply, how can you get some visibility, ally yourself with strategic partners that won't ask for your first-born, and build deal flow to create a consistently recurring revenue stream? All good questions, I would venture you'd agree with me here. So what are the answers? Well, in my experience, I've found that gathering momentum is a function of the business relationships you build and the quality of the people you surround yourself with. As an entrepreneur and the CEO of my own company, I make the decisions about who I'd like to hire, about whether or not to join boards or associations, and even whether or not to go to certain conferences, seminars, or networking events. Early on, I found out about a business incubator and venture accelerator called TEN - The Enterprise Network of Silicon Valley. After meeting with their CEO, I was convinced he had the integrity and ethics for the kind of business relationships I find successful. I subsequently established business relationships with him and his staff, and even joined TEN. This has proven to be a good decision, resulting in solid business relationships with even more future potential. I also established business relationships with other CEOs and entrepreneurs in Silicon Valley that met my high standards of ethics, integrity, and relevance. I don't suffer fools gladly, and I give short shrift to "flies" masquerading as entrepreneurs just waiting to take advantage of neophytes. Then, too, instead of going out and incurring debt by hiring too many people and leasing plush office space before we had real revenue, I decided to bring on board a leadership team of three people to help me in their areas of expertise. Namely, product marketing & sales, business law, and web marketing technologies. I've known these folks for many years, and I trust them implicitly to do the right things for my company. So I've surrounded myself with three people who's opinions I respect and who aren't afraid to give me bad news when necessary. Lesson learned? Creating a compelling website, talking about your company to everyone you see all the time, and proactively spending 110% of your time doggedly pursuing clients and customers - all these are extremely important and contribute to gathering momentum. But IMHO, the business relationships you establish and the quality of the people you surround yourself with are the key for gathering momentum for your start-up company.
Sunday, December 19, 2004
Saturday, December 11, 2004
Starting out as an Entrepreneur in the Silicon Valley
If you've read previous postings in this blog, then you know by now that I spent 19 years working for AT&T Bell Labs, NEC, Sony, and Microsoft, and a couple of startups, where I developed hardware platforms and software systems such as the NEC PowerMate personal computers, the Sony VAIO laptop and desktop computers, and Microsoft interactive television middleware. As a developer, I have a passion for engineering prototypes and developing systems. With this in mind, I founded TransformTec in the late spring of 2004. I saw an opportunity in my years at large corporations and small startups to capitalize on the fact that sometimes, really good ideas never make it to market. Some of these innovative ideas are emergent, while others are almost ready to launch. But in all cases, the idea generators cannot or will not bring these to market. I founded TransformTec to convert these intellectual property assets into cash. TransformTec is a product development company and a technology broker. We've identified 41 acquiring companies in the telecommunications, multimedia, and consumer electronics space to which we want to market and sell. We analyze these acquiring companies’ strategic product roadmap needs, and fulfill them with client’s prototypes. In essence, TransformTec is all about converting intellectual property into cash.
That’s the summary of why I decided to become an entrepreneur. But if you’ll bear with me, I can tell you a little more below. Let me tell you 4 things about TransformTec. The leadership team we currently have in place, what TransformTec is, our paths to cash, and making money – what I like to refer to as “the TransformTec pipeline”.
From the get-go, I knew I could do all the engineering tasks myself - like architecture, design, development, and program management, at least in the beginning. But for the nascent company to be successful, I also figured I needed a web presence, some marketing savvy, and some legal guidance. First I brought Dennis Mesina onboard, he and I go way back, he’s been practicing law in the Bay Area for almost 20 years. Then I brought on board Jim Warholic, whose knowledge of crafting effective websites, and search engine secrets, has proven very helpful. Next I brought Chris Sanders onboard, who I’ve known for about 10 years (including at NEC and Sony), and his marketing and sales skills are invaluable. I am confident being associated with these great talents as we bring TransformTec to the next level.
I can think of no better way to describe my company than by simplifying its fundamental premise: Monetize intellectual property. At TransformTec, this is done in two ways: (1) by working with idea generators to develop their idea into a prototype and then selling that IP asset to an acquiring company, or else (2) by brokering a fully cooked idea between an idea generator and an acquiring company. For my company, there are two paths to cash. But in both cases, we need to understand the customers’ needs - in this context that’s the forty-one acquiring companies we are targeting. We need to engage with them and figure out how to take some technology under development over here, to fill a niche in their strategic product roadmap over there. One path to cash is through developing products with idea generators, and the other is through brokering technology. Then it’s simply a process of designing and developing a solution for the acquiring companies - preferably something that we’ve been working on with one of our idea generator clients! Regarding brokering technology, the path to cash there is through (1) cataloging intellectual property assets, (2) creating premium search services, and (3) offering topic sponsorships.
Finally, I’d like to explain the cash cow I’m building, My exit strategy is not to IPO or get merged or acquired. My exit strategy is to create a viable enterprise and lead that enterprise into the future, generating strong cash flow for stakeholders. I will stuff the TransformTec pipeline with projects every year. Projects go in on one end, and revenue comes out of the other end. Sounds pretty easy, doesn't it? Well, it is simple, but let me tell you, its definitely not easy! I intend to take on two projects the first year, with no sales activities or revenue generated. In the second year, I’ll sell off the first two project’s prototypes and intellectual property assets while simultaneously developing five more projects, and qualifying ten projects for year three. Ramping up staffing as needed and as appropriate is a skill refined from years of developing products. Conservatively guestimating each project to average $2.5m in revenues, by the time we get to year five I am projecting $50m in annual revenues. I expect to sustain twenty projects a year, with $50m in annual revenues, into perpetuity. Hence, a cash cow.
I’m very passionate about my work. Already in the past seven months I've learned so many new things as an entrepreneur in the Silicon Valley, things I never could have learned before. If any of this is interesting to you, I’d like to hear your comments. I would be interested in your feedback on my entrepreneurial ideas and my product development and technology broker company. I invite you to send us email at info@TransformTec.com. There are many issues facing entrepreneurs in the Silicon Valley today. I've been living and breathing them ever since I founded my new company here.....
That’s the summary of why I decided to become an entrepreneur. But if you’ll bear with me, I can tell you a little more below. Let me tell you 4 things about TransformTec. The leadership team we currently have in place, what TransformTec is, our paths to cash, and making money – what I like to refer to as “the TransformTec pipeline”.
From the get-go, I knew I could do all the engineering tasks myself - like architecture, design, development, and program management, at least in the beginning. But for the nascent company to be successful, I also figured I needed a web presence, some marketing savvy, and some legal guidance. First I brought Dennis Mesina onboard, he and I go way back, he’s been practicing law in the Bay Area for almost 20 years. Then I brought on board Jim Warholic, whose knowledge of crafting effective websites, and search engine secrets, has proven very helpful. Next I brought Chris Sanders onboard, who I’ve known for about 10 years (including at NEC and Sony), and his marketing and sales skills are invaluable. I am confident being associated with these great talents as we bring TransformTec to the next level.
I can think of no better way to describe my company than by simplifying its fundamental premise: Monetize intellectual property. At TransformTec, this is done in two ways: (1) by working with idea generators to develop their idea into a prototype and then selling that IP asset to an acquiring company, or else (2) by brokering a fully cooked idea between an idea generator and an acquiring company. For my company, there are two paths to cash. But in both cases, we need to understand the customers’ needs - in this context that’s the forty-one acquiring companies we are targeting. We need to engage with them and figure out how to take some technology under development over here, to fill a niche in their strategic product roadmap over there. One path to cash is through developing products with idea generators, and the other is through brokering technology. Then it’s simply a process of designing and developing a solution for the acquiring companies - preferably something that we’ve been working on with one of our idea generator clients! Regarding brokering technology, the path to cash there is through (1) cataloging intellectual property assets, (2) creating premium search services, and (3) offering topic sponsorships.
Finally, I’d like to explain the cash cow I’m building, My exit strategy is not to IPO or get merged or acquired. My exit strategy is to create a viable enterprise and lead that enterprise into the future, generating strong cash flow for stakeholders. I will stuff the TransformTec pipeline with projects every year. Projects go in on one end, and revenue comes out of the other end. Sounds pretty easy, doesn't it? Well, it is simple, but let me tell you, its definitely not easy! I intend to take on two projects the first year, with no sales activities or revenue generated. In the second year, I’ll sell off the first two project’s prototypes and intellectual property assets while simultaneously developing five more projects, and qualifying ten projects for year three. Ramping up staffing as needed and as appropriate is a skill refined from years of developing products. Conservatively guestimating each project to average $2.5m in revenues, by the time we get to year five I am projecting $50m in annual revenues. I expect to sustain twenty projects a year, with $50m in annual revenues, into perpetuity. Hence, a cash cow.
I’m very passionate about my work. Already in the past seven months I've learned so many new things as an entrepreneur in the Silicon Valley, things I never could have learned before. If any of this is interesting to you, I’d like to hear your comments. I would be interested in your feedback on my entrepreneurial ideas and my product development and technology broker company. I invite you to send us email at info@TransformTec.com. There are many issues facing entrepreneurs in the Silicon Valley today. I've been living and breathing them ever since I founded my new company here.....
Friday, December 10, 2004
Interlude and Transition #2
After four years of working at Microsoft, the challenges were fewer and the excitement grew dim. I soon found myself yearning for new challenges and exciting new technologies. But where does one go after Microsoft? Is there life after Microsoft? After working for four years with some of the best minds in the software industry, what does one do for an encore?
As I engaged in this navel gazing exercise of introspection, I came to the realization that no existing technology company could meet my high standards of excellence, commitment, and perseverance. So I began to formulate an idea for starting my own company. On my own time, during weekends and evenings, I started a thought process that eventually led to the founding of my own company. I first talked it over with my wife of 22 years, and got her buy-in and support. Next I spoke with my 3 kids - two teenagers and a tweener. They encouraged me, gave me their blessings, and were just great about the whole thing. Then I started socializing my ideas for a new company with long-time friends who were uninvolved in my profession. Getting positive feedback, I wrestled with whether or not I should stay at Microsoft until my new company got off the ground, or else break off the ties that bind and start afresh. This was the most difficult decision-making process yet, because at its most elemental form, this decision involved the security and well-being of my family......
When I think of a safety net, I often conjure up images of trapeze artists in a three-ring circus, doing amazing feats of agility and gravity-defying stunts to thrill and amaze a captivated audience. Although most don't notice it, there is usually some webbing device, referred to as a safety net, underneath the area where the trapeze artists are working, so in case they fall they don't actually plummet to a horrifying death in front of unsuspecting little children munching on popcorn and candy cotton. If they fall, they are safely cocooned into the webbing device, and emerge unscathed, ready to get back up there and join their fellow trapeze artists. So the safety net serves the dual purpose of saving the trapeze artist from a gruesome mangled death, as well as not creating a traumatic event in the minds of the viewers. Very smart, that.
Not to mix my metaphors too much, but there is also this concept of free-falling when parachute jumping. In this context, free-falling refers to the brief moments in time between leaping from the aircraft and pulling the ripcord to release the parachute. It's an exhilerating sensation...... To keep your orientation, you must remember the colors blue, green, and brown. Blue for sky, green for ocean, and brown for land. By remembering these colors, even in a moment of distraction or panic, you can always orient yourself correctly to land upright on land. Which of course is much better than landing upside down in water...... Anyway, before you pull your ripcord to open the parachute, you are free-falling towards earth at an alarmingly fast speed, which causes the sensation of exhileration. Its an exquisite feeling, a thrilling adrenaline rush of euphoria and pseudo-panic. Once you pull the ripcord and the parachute opens, you feel safer as you slowly float down to dry land. Your pulse returns to normal, you feel almost calm, compared to the previous sensation of free-falling......
As I mentioned before going off on a tangent about safety nets and free-falling, the most difficult decision-making process yet was whether or not to start my company before or after quitting Microsoft, because at its most elemental form, this decision involved the security and well-being of my family...... Do I free-fall without a safety net, or do I take the safe route and start my company in my spare time? What a fateful decision to grapple with! Greater minds than mine have struggled with this dilema, no doubt, and I'm sure each person decides what's true for themselves in their own circumstances.....
In my case, I decided I could not do anything half-baked. I could not start my company in my spare time. I had to work on it full-time. For I do things full-bore. When I decide to do something, I throw my passion, commitment, and energy into it completely. Was it risky? Sure! Was I apprehensive? You bet! Did my colleagues at Microsoft encourage me to stay? Of course! But in the final analysis, I listened to my deepest inner self. I went with my gut. I gave myself over to that undefinable construct of positive energy, threw caution to the winds, and just did it.....
I believed in myself. I thought to myself, "I can do this thing!" And so, I began free-falling without a safety net. I quit Microsoft, and founded TransformTec, a product development company and technology broker dedicated to converting intellectual property into cash. After 19 years of working at AT&T Bell Labs, NEC, Sony, Microsoft, and a couple of start-ups along the way, I took a leap of faith and jumped in feet first..... and became an entrepreneur - the founder, President, and CEO of TransformTec, Inc.
As I engaged in this navel gazing exercise of introspection, I came to the realization that no existing technology company could meet my high standards of excellence, commitment, and perseverance. So I began to formulate an idea for starting my own company. On my own time, during weekends and evenings, I started a thought process that eventually led to the founding of my own company. I first talked it over with my wife of 22 years, and got her buy-in and support. Next I spoke with my 3 kids - two teenagers and a tweener. They encouraged me, gave me their blessings, and were just great about the whole thing. Then I started socializing my ideas for a new company with long-time friends who were uninvolved in my profession. Getting positive feedback, I wrestled with whether or not I should stay at Microsoft until my new company got off the ground, or else break off the ties that bind and start afresh. This was the most difficult decision-making process yet, because at its most elemental form, this decision involved the security and well-being of my family......
When I think of a safety net, I often conjure up images of trapeze artists in a three-ring circus, doing amazing feats of agility and gravity-defying stunts to thrill and amaze a captivated audience. Although most don't notice it, there is usually some webbing device, referred to as a safety net, underneath the area where the trapeze artists are working, so in case they fall they don't actually plummet to a horrifying death in front of unsuspecting little children munching on popcorn and candy cotton. If they fall, they are safely cocooned into the webbing device, and emerge unscathed, ready to get back up there and join their fellow trapeze artists. So the safety net serves the dual purpose of saving the trapeze artist from a gruesome mangled death, as well as not creating a traumatic event in the minds of the viewers. Very smart, that.
Not to mix my metaphors too much, but there is also this concept of free-falling when parachute jumping. In this context, free-falling refers to the brief moments in time between leaping from the aircraft and pulling the ripcord to release the parachute. It's an exhilerating sensation...... To keep your orientation, you must remember the colors blue, green, and brown. Blue for sky, green for ocean, and brown for land. By remembering these colors, even in a moment of distraction or panic, you can always orient yourself correctly to land upright on land. Which of course is much better than landing upside down in water...... Anyway, before you pull your ripcord to open the parachute, you are free-falling towards earth at an alarmingly fast speed, which causes the sensation of exhileration. Its an exquisite feeling, a thrilling adrenaline rush of euphoria and pseudo-panic. Once you pull the ripcord and the parachute opens, you feel safer as you slowly float down to dry land. Your pulse returns to normal, you feel almost calm, compared to the previous sensation of free-falling......
As I mentioned before going off on a tangent about safety nets and free-falling, the most difficult decision-making process yet was whether or not to start my company before or after quitting Microsoft, because at its most elemental form, this decision involved the security and well-being of my family...... Do I free-fall without a safety net, or do I take the safe route and start my company in my spare time? What a fateful decision to grapple with! Greater minds than mine have struggled with this dilema, no doubt, and I'm sure each person decides what's true for themselves in their own circumstances.....
In my case, I decided I could not do anything half-baked. I could not start my company in my spare time. I had to work on it full-time. For I do things full-bore. When I decide to do something, I throw my passion, commitment, and energy into it completely. Was it risky? Sure! Was I apprehensive? You bet! Did my colleagues at Microsoft encourage me to stay? Of course! But in the final analysis, I listened to my deepest inner self. I went with my gut. I gave myself over to that undefinable construct of positive energy, threw caution to the winds, and just did it.....
I believed in myself. I thought to myself, "I can do this thing!" And so, I began free-falling without a safety net. I quit Microsoft, and founded TransformTec, a product development company and technology broker dedicated to converting intellectual property into cash. After 19 years of working at AT&T Bell Labs, NEC, Sony, Microsoft, and a couple of start-ups along the way, I took a leap of faith and jumped in feet first..... and became an entrepreneur - the founder, President, and CEO of TransformTec, Inc.
Friday, November 26, 2004
Customer Landscape
Developing and releasing a Version 1.0 product at Microsoft is a near herculean task. Many great minds representing different disciplines with differing perspectives and agendas need to come together and agree that the software code is production-worthy. Comparatively speaking, subsequent versions are much easier to get out the door. After releasing Version 1.0 on June 1, 2001, we hoped our "showcase" customers would welcome the product with open arms......
Alas and alack, the downward spiral in the economy was taking its toll on our "showcase" customers. Slowly but surely, as the fiscal angel of death descended on their houses, one by one they started backing out of their commitments to us. We used this time of uncertainty to refine our product, even enhance it with some new features, and tweak it into the best possible state. We released Version 1.5 at the end of October 2001, thinking surely that would entice our customers to sign on the dotted line. We were all proud of the little plaque to attach to our Ship-it Awards, but the victory still seemed a tad hollow without real paying customers using our product. We continued to refine, enhance, and tweak, adding what we thought were surefire customer pleasers like PVR (personal video recorder, also referred to as DVR, or digital video recorder) features, and VOD (video on demand) features. We all worked smarter and harder and long into the night, hoping against hope that the business development and sales staff would garner design wins and customer satisfaction. Sadly, by the time we released Version 2.0 on April 19, 2002, the writing was on the wall. Not a single shipping, paying, customer had been won. The few customers remaining wanted yet more tweaks before they would consider the product ready, and frankly speaking we were all quite worn down.
To turn things around, a new executive was brought in to lead the future vision. We focused Version 2.0 on the last remaining hopeful customers in Europe and Latin America. We ramped up the staff for a new thin-client product for North America, and soon we were fastly and furiously specifying new features and roadmaps.
Finally, after much customization work, we signed paying customers in Europe for Version 2.0. Soon after that, after a complete overhaul and even more customized engineering development, we signed paying customers in Latin America. At long last, we felt good about what we had accomplished - a real product into paying customers hands. Life was good...... And still fresh development continued on, for the new thin-client product. We had high hopes that would really capture the hearts and minds of a much larger customer base. Customers are, after all, the main reason why products are developed, are they not? At least that's what I'd like to think.....
I learned many lessons during these years. As engineers we often overlook the changing customer landscape, but we do so at our own peril. A great product without a customer base can not really be that great. Even if we create the most intricate, elegant, software solutions and provide compelling products and services, if we don't have the ability to market and sell them to real paying customers, our efforts are for naught. Ultimately, customer satisfaction is at the heart of a success - develop the right product for the right customer at the right cost and at the right time, and you'll have a winner, with many customers coming back for more. Develop a whizbang technology just to show you can, and it may be a minor footnote in the dusty annals of some arcane museum somewhere. "Build it and they will come" only works in the movies. At least that's my story, and I'm sticking to it.....
Alas and alack, the downward spiral in the economy was taking its toll on our "showcase" customers. Slowly but surely, as the fiscal angel of death descended on their houses, one by one they started backing out of their commitments to us. We used this time of uncertainty to refine our product, even enhance it with some new features, and tweak it into the best possible state. We released Version 1.5 at the end of October 2001, thinking surely that would entice our customers to sign on the dotted line. We were all proud of the little plaque to attach to our Ship-it Awards, but the victory still seemed a tad hollow without real paying customers using our product. We continued to refine, enhance, and tweak, adding what we thought were surefire customer pleasers like PVR (personal video recorder, also referred to as DVR, or digital video recorder) features, and VOD (video on demand) features. We all worked smarter and harder and long into the night, hoping against hope that the business development and sales staff would garner design wins and customer satisfaction. Sadly, by the time we released Version 2.0 on April 19, 2002, the writing was on the wall. Not a single shipping, paying, customer had been won. The few customers remaining wanted yet more tweaks before they would consider the product ready, and frankly speaking we were all quite worn down.
To turn things around, a new executive was brought in to lead the future vision. We focused Version 2.0 on the last remaining hopeful customers in Europe and Latin America. We ramped up the staff for a new thin-client product for North America, and soon we were fastly and furiously specifying new features and roadmaps.
Finally, after much customization work, we signed paying customers in Europe for Version 2.0. Soon after that, after a complete overhaul and even more customized engineering development, we signed paying customers in Latin America. At long last, we felt good about what we had accomplished - a real product into paying customers hands. Life was good...... And still fresh development continued on, for the new thin-client product. We had high hopes that would really capture the hearts and minds of a much larger customer base. Customers are, after all, the main reason why products are developed, are they not? At least that's what I'd like to think.....
I learned many lessons during these years. As engineers we often overlook the changing customer landscape, but we do so at our own peril. A great product without a customer base can not really be that great. Even if we create the most intricate, elegant, software solutions and provide compelling products and services, if we don't have the ability to market and sell them to real paying customers, our efforts are for naught. Ultimately, customer satisfaction is at the heart of a success - develop the right product for the right customer at the right cost and at the right time, and you'll have a winner, with many customers coming back for more. Develop a whizbang technology just to show you can, and it may be a minor footnote in the dusty annals of some arcane museum somewhere. "Build it and they will come" only works in the movies. At least that's my story, and I'm sticking to it.....
Ship-it Awards
When I was there, Microsoft had this really cool way of recognizing organizations that released **real** products to **real** customers. It was called a Ship-it Award. Maybe they still continue this practice, I hope so because it was a good one. Everyone who participated in the product development and market launch of a Microsoft product got one of these things. Mine has a nice grey marble base, with two black obelisks rising out from either side, with a glass etching in the center. The inscription on the glass reads like this:
"Every time a product ships, it takes us one step closer to the vision: empower people through great software - any time, any place, and on any device. Thanks for the lasting contribution you have made to Microsoft history."
Bill Gates' signature is below the inscription, and a small bronze plate with the employee name is under that. On each of the black obelisks, the employee is encouraged to put the 25mm-by-40mm aluminum plaque containing the name of the product, the version number, and the release date. I'm sure the Ship-it Award's verbiage and appearance evolve over time, but it is still an inspirational tool for employees. In fact, when people interview, they are often asked how many Ship-it Awards they have, an indication of how many development cycles they have worked through. I still keep my Ship-it Award on my desk, right next to the Sony plaques I alluded to in a prior blog posting. My Ship-it Award reminds me of the four years I spent working at Microsoft......
After Release B, we were on a good roll. The technical teams started gelling very well together, and everyone knew we were on to something good. The program managers spec'ed out all the features and APIs for the next release, getting buy-in from the software developers, test engineers, and marketing folks. The software developers coded the modules and subroutines necessary to support the marketing requirements. The test engineers performed quality assurance on the deliverables from the software developers, and when bugs were found everyone collaboratively resolved them one way or another. Some bugs need code modifications, others needed documentation changes, while still others were deemed not likely to occur in the real world, and yet others were left for future discussions.....
Finally, on June 1, 2001, we completed everything necessary and signed off on Version 1.0 of our product. True to form, just as we had hoped, the next release after Release B was production-worthy, so instead of calling it Release C we called it Version 1.0. We were so happy, ecstatic in fact! It had been a long haul - some of the engineers had been working on this product for a few years. It was very satisfying and gratifying for all of us in development. We only hoped our customers would be as ecstatic as we were. The customer landscape was changing, as the economy was diving deeper and deeper into recession, but we fervently hoped that our "showcase" customers would welcome our Version 1.0 product with open arms......
"Every time a product ships, it takes us one step closer to the vision: empower people through great software - any time, any place, and on any device. Thanks for the lasting contribution you have made to Microsoft history."
Bill Gates' signature is below the inscription, and a small bronze plate with the employee name is under that. On each of the black obelisks, the employee is encouraged to put the 25mm-by-40mm aluminum plaque containing the name of the product, the version number, and the release date. I'm sure the Ship-it Award's verbiage and appearance evolve over time, but it is still an inspirational tool for employees. In fact, when people interview, they are often asked how many Ship-it Awards they have, an indication of how many development cycles they have worked through. I still keep my Ship-it Award on my desk, right next to the Sony plaques I alluded to in a prior blog posting. My Ship-it Award reminds me of the four years I spent working at Microsoft......
After Release B, we were on a good roll. The technical teams started gelling very well together, and everyone knew we were on to something good. The program managers spec'ed out all the features and APIs for the next release, getting buy-in from the software developers, test engineers, and marketing folks. The software developers coded the modules and subroutines necessary to support the marketing requirements. The test engineers performed quality assurance on the deliverables from the software developers, and when bugs were found everyone collaboratively resolved them one way or another. Some bugs need code modifications, others needed documentation changes, while still others were deemed not likely to occur in the real world, and yet others were left for future discussions.....
Finally, on June 1, 2001, we completed everything necessary and signed off on Version 1.0 of our product. True to form, just as we had hoped, the next release after Release B was production-worthy, so instead of calling it Release C we called it Version 1.0. We were so happy, ecstatic in fact! It had been a long haul - some of the engineers had been working on this product for a few years. It was very satisfying and gratifying for all of us in development. We only hoped our customers would be as ecstatic as we were. The customer landscape was changing, as the economy was diving deeper and deeper into recession, but we fervently hoped that our "showcase" customers would welcome our Version 1.0 product with open arms......
Release B
During the summer of 2000 in Microsoft's interactive television group, things were abuzz with anticipation. Our main customers were impatiently waiting for the production version of our software for high end set top boxes. Some months before I arrived, the head of the organization had promised everyone a trip to Hawaii if they released the product on time. They didn't, and now the engineers and business development people were anxious to put the finishing touches on the product and proudly roll it out the door. Release B was a step in the right direction.
At first I was aghast at all the different versioning schemes the group had invented as the delays rolled way past the customers expectations. It seemed so patently transparent, who did they think they were fooling? They tried several flavors of Alpha and Beta to whet their customers appetites, but none were really ready for prime time. Then they tried Beta 1, Beta 2, Beta 3 to indicate they were getting very, very close to production-worthy code. When I arrived on the scene, they had just transitioned over to yet another new nomenclature - the alphabet - and had just released Release A and started working on Release B. I worked with the leadership to instill more engineering discipline into our processes, and create actual meaningful definitions for milestones. Up until now, there really wasn't great concurrence between the various technical disciplines (development, test, and program management) about crisp definitions on things like entrance requirements and exit criteria for milestones. The creative geniuses who held great sway over the organization felt that software code would just dribble out whenever it was ready to dribble out, and I felt that was a hell of a way to run a ship. So for Release B, I was determined to make milestones meaningful.
And so it was. Eventually, we were able to broker agreements between the disparate groups, and everyone worked long hours until finally, in November 2000, we happily signed off on Release B. We held release parties, and patted ourselves on the back- visible progress! We felt we finally were closing in on the last mile. We felt if we followed the same disciplined approach, the next release would be production-worthy. Finally, after so long, a product our customers could put into production use was just one more release away..... if only we could continue to agree with each other, stop internecine bickering, and all row the boat in the same direction...... we could see light at the end of the tunnel, and we hoped it wasn't an onrushing train.
At first I was aghast at all the different versioning schemes the group had invented as the delays rolled way past the customers expectations. It seemed so patently transparent, who did they think they were fooling? They tried several flavors of Alpha and Beta to whet their customers appetites, but none were really ready for prime time. Then they tried Beta 1, Beta 2, Beta 3 to indicate they were getting very, very close to production-worthy code. When I arrived on the scene, they had just transitioned over to yet another new nomenclature - the alphabet - and had just released Release A and started working on Release B. I worked with the leadership to instill more engineering discipline into our processes, and create actual meaningful definitions for milestones. Up until now, there really wasn't great concurrence between the various technical disciplines (development, test, and program management) about crisp definitions on things like entrance requirements and exit criteria for milestones. The creative geniuses who held great sway over the organization felt that software code would just dribble out whenever it was ready to dribble out, and I felt that was a hell of a way to run a ship. So for Release B, I was determined to make milestones meaningful.
And so it was. Eventually, we were able to broker agreements between the disparate groups, and everyone worked long hours until finally, in November 2000, we happily signed off on Release B. We held release parties, and patted ourselves on the back- visible progress! We felt we finally were closing in on the last mile. We felt if we followed the same disciplined approach, the next release would be production-worthy. Finally, after so long, a product our customers could put into production use was just one more release away..... if only we could continue to agree with each other, stop internecine bickering, and all row the boat in the same direction...... we could see light at the end of the tunnel, and we hoped it wasn't an onrushing train.
Sunday, October 24, 2004
Interlude and Transition #1
After a few years at Sony, things were really heating up in the high-tech field in general and in the Silicon Valley in particular. It was a boom time for the economy, too. I now had 15 years of experience at 3 major league players in the high-tech field. So I decided to be adventuresome, step out of my comfort zone and be a risk taker. Opportunities abounded for me. In fairly quick succession, I became a director of software engineering at a multinational company (made my first business trip to Paris, way cool!), then VP of product development at an internet music appliance startup company (precursor of the iTunes business, we were a five years ahead of the market), and finally VP of engineering at a B2B ecommerce startup company. With dizzying speed I had accomplished my career objective, and was having so much fun and hard work developing software, hardware, and systems products with talented staff at a breakneck pace.
Looking back in 20/20 hindsight, I guess I knew in the back of my mind that it couldn't last forever. What goes up, must come down as the Newtonian physicists always like to remind us. And so it was with the tech-fueled boom times at the turn of the last century. Everything seemed to fall like a house of cards - venture capital money dried up, the economy slowed into a recession, and hundreds of thousands of displaced engineers started showing up on the unemployment roles.....
So what did I do? I did what any self-respecting, experienced, degreed computer scientist would do in troubled economic times - I went to work for Microsoft! When I first arrived at Microsoft, it was an awesome place to work. Cool projects, cool people, and a cool work environment - life didn't get any better than this! I was on cloud nine, having the time of my life. For the first couple of years there, I kept wondering why I hadn't sought out Microsoft as an employer earlier in my career. Life was good.
Looking back in 20/20 hindsight, I guess I knew in the back of my mind that it couldn't last forever. What goes up, must come down as the Newtonian physicists always like to remind us. And so it was with the tech-fueled boom times at the turn of the last century. Everything seemed to fall like a house of cards - venture capital money dried up, the economy slowed into a recession, and hundreds of thousands of displaced engineers started showing up on the unemployment roles.....
So what did I do? I did what any self-respecting, experienced, degreed computer scientist would do in troubled economic times - I went to work for Microsoft! When I first arrived at Microsoft, it was an awesome place to work. Cool projects, cool people, and a cool work environment - life didn't get any better than this! I was on cloud nine, having the time of my life. For the first couple of years there, I kept wondering why I hadn't sought out Microsoft as an employer earlier in my career. Life was good.
Sunday, October 03, 2004
Tiger Team
Working at Sony was a lot of fun, and there was remarkable synergy between divisions. Nowhere was this more evident than during the time Sony Pictures Entertainment (SPE) was getting ready to release the latest Godzilla blockbuster movie, and my division, Sony Information Technologies of America (ITA) was getting ready to release the first generation of the VAIO 505 laptop computer. Many newer Sony movies have exceeded Godzilla's popularity and box-office appeal, and many newer computers have exceeded the original VAIO 505's technical specifications, performance and sex-appeal, but back in the day, this was an exquisite opportunity for cross-marketing and leveraging Sony properties.
Minds much greater than mine came up with the idea that linking Godzilla (BIG!) and the VAIO 505 (small!) would allow both Sony divisions to leverage the marketing muscle of each other. My division formed a Tiger Team to bring all the different disciplines together to pull this off. I was selected as the engineering representative on the Tiger Team. At this point in my career, I was managing a team of over twenty software engineers as well as personally functioning as the program manager for the VAIO 505's software development and integration in the U.S. I was so busy I rarely had time to sit at my desk and answer emails! But I was having the time of my life.....
The Tiger Team was headed up by an advisor to the division's president. He was a personable chap from India with over twenty years experience in the Silicon Valley at world-class technology companies in senior executive marketing roles. He and I hit it off very well, and during this project we became good friends. Other members of the Tiger Team included staff from product marketing, public relations, business development, sales, marketing communications, and operations. We met once a week for several months, and as we closed in on the launch date we started meeting more frequently......
As with most projects of this nature, where the pay-off is huge and the visibility is high, tempers would flare and disagreements would be hashed out, but it is a testament to the leader of this Tiger Team that everything was executed flawlessly. No scent-marking territoriality, ego-building pomposity, overwraught personality, overworked people, or just plain stress was going to get in the way of making this product launch the most successful in our division's short history. And so it was..... and so it came to be.....
On the engineering side my team executed flawlessly, and delivered a quality product on spec and on schedule. On the marketing side, they too executed flawlessly, and delivered one of the best marketing campaigns ever. All the other disciplines also came through with their deliverables - there were product placements, and advertisements, and commercials, cross-promotions with the movie, a favorable writeup in the Wall Street Journal by Walt Mossberg, and even a spot on some morning TV show in the gadget section. In fact, some of my favorite T-shirts still hanging in my closet are from this effort. On the front, the T-shirt has the big green Godzilla monster foot with the word "GODZILLA", and on the back the T-shirt has the dimunitive VAIO 505 laptop with the words "SIZE DOES MATTER"......
But my favorite memorabilia from the Tiger Team remains something very special. The Tiger Team leader had it made as a token of his gratitude for all the members, for the time we spent together realizing the vision, making it happen. The plaque looks something like this:
Sony
Tiger Team
Special Recognition
Jeff Phillips
Your trailblazing creativity, dedication and spirit of teamwork paved the way for an innovative U.S. launch of the VAIO 505 SuperSlim Notebook.
With sincere gratitude and appreciation,
K.Ando
President
Sony Information Technology Company
Kunitake Ando is currently President of Sony Corporation in Japan. I was invited to a dinner with him once, about a year later, and was happily surprised that he recognized and remembered my name. I felt honored yet humbled at the same time.....
I cherish these recollections, the T-shirts, the plaque..... they bring back fond memories of this time in my life, this project, the first generation of the VAIO 505 laptop computer, the Godzilla blockbuster movie, and the Tiger Team I served on..... I still keep the plaque on my desk, where I can be reminded of the experience everyday and it will bring a sparkle to my eye. It sits right next to my Microsoft Ship-It Award, with a Bill Gates inscription - but that's a different project and yet another anecdote or two.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
Minds much greater than mine came up with the idea that linking Godzilla (BIG!) and the VAIO 505 (small!) would allow both Sony divisions to leverage the marketing muscle of each other. My division formed a Tiger Team to bring all the different disciplines together to pull this off. I was selected as the engineering representative on the Tiger Team. At this point in my career, I was managing a team of over twenty software engineers as well as personally functioning as the program manager for the VAIO 505's software development and integration in the U.S. I was so busy I rarely had time to sit at my desk and answer emails! But I was having the time of my life.....
The Tiger Team was headed up by an advisor to the division's president. He was a personable chap from India with over twenty years experience in the Silicon Valley at world-class technology companies in senior executive marketing roles. He and I hit it off very well, and during this project we became good friends. Other members of the Tiger Team included staff from product marketing, public relations, business development, sales, marketing communications, and operations. We met once a week for several months, and as we closed in on the launch date we started meeting more frequently......
As with most projects of this nature, where the pay-off is huge and the visibility is high, tempers would flare and disagreements would be hashed out, but it is a testament to the leader of this Tiger Team that everything was executed flawlessly. No scent-marking territoriality, ego-building pomposity, overwraught personality, overworked people, or just plain stress was going to get in the way of making this product launch the most successful in our division's short history. And so it was..... and so it came to be.....
On the engineering side my team executed flawlessly, and delivered a quality product on spec and on schedule. On the marketing side, they too executed flawlessly, and delivered one of the best marketing campaigns ever. All the other disciplines also came through with their deliverables - there were product placements, and advertisements, and commercials, cross-promotions with the movie, a favorable writeup in the Wall Street Journal by Walt Mossberg, and even a spot on some morning TV show in the gadget section. In fact, some of my favorite T-shirts still hanging in my closet are from this effort. On the front, the T-shirt has the big green Godzilla monster foot with the word "GODZILLA", and on the back the T-shirt has the dimunitive VAIO 505 laptop with the words "SIZE DOES MATTER"......
But my favorite memorabilia from the Tiger Team remains something very special. The Tiger Team leader had it made as a token of his gratitude for all the members, for the time we spent together realizing the vision, making it happen. The plaque looks something like this:
Sony
Tiger Team
Special Recognition
Jeff Phillips
Your trailblazing creativity, dedication and spirit of teamwork paved the way for an innovative U.S. launch of the VAIO 505 SuperSlim Notebook.
With sincere gratitude and appreciation,
K.Ando
President
Sony Information Technology Company
Kunitake Ando is currently President of Sony Corporation in Japan. I was invited to a dinner with him once, about a year later, and was happily surprised that he recognized and remembered my name. I felt honored yet humbled at the same time.....
I cherish these recollections, the T-shirts, the plaque..... they bring back fond memories of this time in my life, this project, the first generation of the VAIO 505 laptop computer, the Godzilla blockbuster movie, and the Tiger Team I served on..... I still keep the plaque on my desk, where I can be reminded of the experience everyday and it will bring a sparkle to my eye. It sits right next to my Microsoft Ship-It Award, with a Bill Gates inscription - but that's a different project and yet another anecdote or two.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
Saturday, September 25, 2004
Seventh Generation Japanese
The Sony division I worked in was full of world-class engineers, marketeers, and salesman. I felt honored to be a part of that team. Creativity was in high supply, and encouraged at all levels and in all disciplines. The procurement and operations folks were also highly talented and fun to work with. Imagine that, what a concept - purchasing staff with graceful social skills that weren't numbers-oriented and boring - how refreshing! It was truly a pleasure working with everyone on both sides of the pond......
In particular, I remember the VP of Sales at one year's annual sales summit. The meeting was held in the middle of the desert (gasp!) of the American southwest, at some nice resort teeming with golfers and tourists in addition to the large contingent of Sony sales and marketing staff. All the engineering department managers were invited, but not all of us could attend, so I was asked to represent one of my colleagues who would be receiving an award. Oh, man, I remember this incident as if it were yesterday......
I confirmed with my engineering director beforehand that the awards presenters knew that I would be accepting the award for my colleague who couldn't be there. He reminded me not to say a word to anyone about this, because no-one was supposed to know my colleague was going to win this award until it happened. So I kept it on the QT, even from my colleagues who were coming to the event with me. On the day before leaving for the event, I again confirmed, this time with my engineering vice-president, that the awards presenters would know that I was going to be accepting the award for my colleague who couldn't be there. The awards ceremony was on the second night, after the big dinner, so leading up to it I was confident that everything would go smoothly. I practiced my 3 lines that I was going to say over and over, to make sure I had it memorized and wouldn't look like a deer caught in the headlights. After all, there were a few hundred people in the audience that night, not only sales staff from all over the US but also executives from the home office in Japan.....
The lights began to dim. The awards ceremony had begun. The VP of Sales would call out the award, explain the great sacrifice and/or accomplishment the awardee had done to earn it, and in the end call up the awardee to the stage. The protocol called for the awardee to say a brief thank you with a few words at the microphone, then shake the VP of Sales hand, then shake the President's hand, then get off the stage and return to their dinner table, glad-handing and receiving attaboys or attagirls all the way back to the table. I'm sure you've seen this scenario repeated at many such events.....
All of a sudden, I hear them call out my colleague's name. I bolt out of my chair with such suddenness that I appear to alarm my tablemates. I caught their perplexed looks in the corner of my eye as I strolled confidently toward the podium. Then I noticed the VP of Sales had this obviously perplexed look on his face as he saw me coming towards him, maybe he must have thought I was drunk or something, but I had a suspicion it was something far worse.....
You see, what I neglected to mention heretofore was that my colleague's name was a quite obviously Japanese-sounding name, and I was just as quite obviously not Japanese, having quite obviously non-Japanese facial features and physiology. As I approached the stage, the presenter made some wise-crack about me being a Seventh Generation Japanese in America, and everybody laughed at my expense. It was as this laughter was dying down that I reached the podium. Inside myself I was mortified, but I was determined to complete the task I had been directed no matter what the consequences. I got up on the stage, and took the trophy out of his hands as a stupefied HR director looked on dumbfounded. As I shook hands with the President, he smiled at me and said en sotto voce only he and I could hear "Jeff, what are you doing here?". It was one of those awkward prolonged moments in time, as I answered "Didn't they tell you? I'm supposed to accept this for him." The President smiled wisely and knowingly as we had one of those awkward longer-than-usual handshaking moments, as it was clear to me no-one had gotten the word to him. As I said my 3 sentences (which I had practiced over and over) at the microphone, the HR director and VP of Sales edged closer to me and whispered "That's enough, Jeff, now go sit down." Defiantly, I stayed at the microphone until I had squeezed out every last word I had so painstakingly practiced, then slowly turned around and gave them a dark, cold look that would stop a moose at mating time. I slowly sauntered off the stage and back to my table, vowing to have a little discussion with my engineering director and engineering vice-president about communications and follow-through.....
In particular, I remember the VP of Sales at one year's annual sales summit. The meeting was held in the middle of the desert (gasp!) of the American southwest, at some nice resort teeming with golfers and tourists in addition to the large contingent of Sony sales and marketing staff. All the engineering department managers were invited, but not all of us could attend, so I was asked to represent one of my colleagues who would be receiving an award. Oh, man, I remember this incident as if it were yesterday......
I confirmed with my engineering director beforehand that the awards presenters knew that I would be accepting the award for my colleague who couldn't be there. He reminded me not to say a word to anyone about this, because no-one was supposed to know my colleague was going to win this award until it happened. So I kept it on the QT, even from my colleagues who were coming to the event with me. On the day before leaving for the event, I again confirmed, this time with my engineering vice-president, that the awards presenters would know that I was going to be accepting the award for my colleague who couldn't be there. The awards ceremony was on the second night, after the big dinner, so leading up to it I was confident that everything would go smoothly. I practiced my 3 lines that I was going to say over and over, to make sure I had it memorized and wouldn't look like a deer caught in the headlights. After all, there were a few hundred people in the audience that night, not only sales staff from all over the US but also executives from the home office in Japan.....
The lights began to dim. The awards ceremony had begun. The VP of Sales would call out the award, explain the great sacrifice and/or accomplishment the awardee had done to earn it, and in the end call up the awardee to the stage. The protocol called for the awardee to say a brief thank you with a few words at the microphone, then shake the VP of Sales hand, then shake the President's hand, then get off the stage and return to their dinner table, glad-handing and receiving attaboys or attagirls all the way back to the table. I'm sure you've seen this scenario repeated at many such events.....
All of a sudden, I hear them call out my colleague's name. I bolt out of my chair with such suddenness that I appear to alarm my tablemates. I caught their perplexed looks in the corner of my eye as I strolled confidently toward the podium. Then I noticed the VP of Sales had this obviously perplexed look on his face as he saw me coming towards him, maybe he must have thought I was drunk or something, but I had a suspicion it was something far worse.....
You see, what I neglected to mention heretofore was that my colleague's name was a quite obviously Japanese-sounding name, and I was just as quite obviously not Japanese, having quite obviously non-Japanese facial features and physiology. As I approached the stage, the presenter made some wise-crack about me being a Seventh Generation Japanese in America, and everybody laughed at my expense. It was as this laughter was dying down that I reached the podium. Inside myself I was mortified, but I was determined to complete the task I had been directed no matter what the consequences. I got up on the stage, and took the trophy out of his hands as a stupefied HR director looked on dumbfounded. As I shook hands with the President, he smiled at me and said en sotto voce only he and I could hear "Jeff, what are you doing here?". It was one of those awkward prolonged moments in time, as I answered "Didn't they tell you? I'm supposed to accept this for him." The President smiled wisely and knowingly as we had one of those awkward longer-than-usual handshaking moments, as it was clear to me no-one had gotten the word to him. As I said my 3 sentences (which I had practiced over and over) at the microphone, the HR director and VP of Sales edged closer to me and whispered "That's enough, Jeff, now go sit down." Defiantly, I stayed at the microphone until I had squeezed out every last word I had so painstakingly practiced, then slowly turned around and gave them a dark, cold look that would stop a moose at mating time. I slowly sauntered off the stage and back to my table, vowing to have a little discussion with my engineering director and engineering vice-president about communications and follow-through.....
Friday, September 24, 2004
Hey, buddy, can ya spare me a dime?
When I arrived at Sony in 1997, I hit the deck with both feet running and was soon intimately integrated into the sprouting organization. Hiring was fast and furious as we went from a largely outsourced business model to bringing everything in house. It was a fun time to watch the organization grow. It was boom time in Silicon Valley, and everyone seemed to be enjoying their work, and their station in life......
I started out leading a small team of engineers from Japan who were on 2 year assignments in Silicon Valley. They were very dedicated and good software engineers. Within a short time I was managing a growing department with four sections, although my favorite section was software planning. In this role, I travelled to Japan frequently to dialogue with my counterparts in Tokyo. I usually brought one person with me, and usually this was an energetic and talented Ph.D. in computer science. We would hold detailed technical meetings with various groups in Sony's Shinagawa offices, and afterwards get on the subway system and go out to dinner. Note to self: things to do in Tokyo when you're not dead: see the sights and nightlife of Tokyo's various districts like Roppongi, Shinjuku, and Ginza; see the ancient temples at Asakusa; see the latest in gadgetry and technology at Akihabara.....
Sometimes it was formal business dinners, Japanese-style, and other times it was less formal and more casual. I remember this one time in the fall, when the Ph.D. and I arranged to take a bus tour of the city of Edo (Tokyo's ancient name) ending up with a dinner and watching a couple of hours of Kabuki theater. That was the best hundred bucks I ever spent (too bad I couldn't expense it!). I learned alot about Tokyo and its different districts, its rich cultural history, and I got to see many parts of the city I hadn't yet ventured into. It was an awesome cultural learning experience.
Another time, I had sent several of my software engineers to Tokyo to work on a joint collaborative project with our colleagues from Sony Europe and Sony Japan. I had come over for a few days of high-level meetings about the project, and wanted to let my staff know they were appreciated and their extended stay away from their families in California did not go unnoticed. So I invited them to go to dinner in the Ginza district, to one of those famed steakhouses..... Well, we were walking around, taking in the sites, window-shopping,and trying to choose the best place to go to. It was getting late, and many of the places were already getting crowded. So we ended up at this smallish, hole-in-the-wall kind of place and feasted on Kobe beef steaks with all the trimmings.... Just a few sakes and Kirin beers were imbibed that night.....
A couple of hours later, when it was time to pay the bill, I confidently whipped out my corporate credit card to settle accounts. Imagine my horror when the waiter indicated the restaurant didn't accept credit cards. Huh? No credit cards? How can that be? This was the turn of the century in an advanced city in a technologically astute country, how could a restaurant possibly not accept credit cards? My mind racing, I tried to think of alternatives short of trying to communicate between my broken non-existent Japanese language skills and the waiter's less-than-perfect English language skills. And of course the sake and the Kirin beer weren't helping matters, either. Luckily, one of my engineers had gone to the currency exchange that day, and still had alot of cash in yen to pay the bill......
Wow, close call. I honestly don't know what we would have done if he didn't have this cash hoarde. What were we going to do, walk the streets of the prim-and-proper Ginza district panhandling like gangsta wannabe's? Can you imagine several foreigners there with their hands out, plaintively braying to passers-by "Hey, buddy, can ya spare me a dime?" I don't even know how to say that in Japanese....... That night as I recounted the story to my long-suffering wife (see Me'n'the Missus posting) on the phone back in California, she couldn't believe it happened. She couldn't believe I was stupid enough not to double-verify that the restaurant accepted credit cards beforehand, nor could she believe how we escaped a painful panhandling experience in a foreign land. But the stars were smiling on us that night, and all was well with the world....
I started out leading a small team of engineers from Japan who were on 2 year assignments in Silicon Valley. They were very dedicated and good software engineers. Within a short time I was managing a growing department with four sections, although my favorite section was software planning. In this role, I travelled to Japan frequently to dialogue with my counterparts in Tokyo. I usually brought one person with me, and usually this was an energetic and talented Ph.D. in computer science. We would hold detailed technical meetings with various groups in Sony's Shinagawa offices, and afterwards get on the subway system and go out to dinner. Note to self: things to do in Tokyo when you're not dead: see the sights and nightlife of Tokyo's various districts like Roppongi, Shinjuku, and Ginza; see the ancient temples at Asakusa; see the latest in gadgetry and technology at Akihabara.....
Sometimes it was formal business dinners, Japanese-style, and other times it was less formal and more casual. I remember this one time in the fall, when the Ph.D. and I arranged to take a bus tour of the city of Edo (Tokyo's ancient name) ending up with a dinner and watching a couple of hours of Kabuki theater. That was the best hundred bucks I ever spent (too bad I couldn't expense it!). I learned alot about Tokyo and its different districts, its rich cultural history, and I got to see many parts of the city I hadn't yet ventured into. It was an awesome cultural learning experience.
Another time, I had sent several of my software engineers to Tokyo to work on a joint collaborative project with our colleagues from Sony Europe and Sony Japan. I had come over for a few days of high-level meetings about the project, and wanted to let my staff know they were appreciated and their extended stay away from their families in California did not go unnoticed. So I invited them to go to dinner in the Ginza district, to one of those famed steakhouses..... Well, we were walking around, taking in the sites, window-shopping,and trying to choose the best place to go to. It was getting late, and many of the places were already getting crowded. So we ended up at this smallish, hole-in-the-wall kind of place and feasted on Kobe beef steaks with all the trimmings.... Just a few sakes and Kirin beers were imbibed that night.....
A couple of hours later, when it was time to pay the bill, I confidently whipped out my corporate credit card to settle accounts. Imagine my horror when the waiter indicated the restaurant didn't accept credit cards. Huh? No credit cards? How can that be? This was the turn of the century in an advanced city in a technologically astute country, how could a restaurant possibly not accept credit cards? My mind racing, I tried to think of alternatives short of trying to communicate between my broken non-existent Japanese language skills and the waiter's less-than-perfect English language skills. And of course the sake and the Kirin beer weren't helping matters, either. Luckily, one of my engineers had gone to the currency exchange that day, and still had alot of cash in yen to pay the bill......
Wow, close call. I honestly don't know what we would have done if he didn't have this cash hoarde. What were we going to do, walk the streets of the prim-and-proper Ginza district panhandling like gangsta wannabe's? Can you imagine several foreigners there with their hands out, plaintively braying to passers-by "Hey, buddy, can ya spare me a dime?" I don't even know how to say that in Japanese....... That night as I recounted the story to my long-suffering wife (see Me'n'the Missus posting) on the phone back in California, she couldn't believe it happened. She couldn't believe I was stupid enough not to double-verify that the restaurant accepted credit cards beforehand, nor could she believe how we escaped a painful panhandling experience in a foreign land. But the stars were smiling on us that night, and all was well with the world....
Thursday, September 23, 2004
Westward ho! A California adventure
Nothing lasts for ever, and all good things eventually come to an end. And so it was for my time and youthful exuberance in the Product Planning and Management organization of NEC's U.S. computer division. NEC had premium product lines, but coveted the larger market share of other U.S. PC vendors. In Japan NEC ruled the roost in marketshare for PCs, but in the U.S. that goal always seemed out of grasp. So ultimately, the unthinkable happened..... after years of rolling lay-offs to trim the fat and cut the deadwood, our division was now going to merge with - gasp! - the value leader in the PC foodchain. Corporate chieftains back in Tokyo decided that combining Packard Bell's 37% market share with NEC's premium brand name and high quality products would result in larger market share and higher volume for all products. But no-one asked my opinion! No-one asked me what I thought of a merger between a value leader and a premium brand..... Of merging two corporate cultures so vastly different from each other any resemblence was pure coincidence.....
With the merger came redundancy in groups, and re-assignments to optimize human resources. In my case, over the years I had been promoted from product manager to senior product manager to product line manager heading up a staff of project managers and product planners for consumer PCs. The newly merged company didn't need two planning groups focused on consumer PCs, and since Packard Bell's strength was in consumer PCs, their group was chosen to stay in place. I was asked to go back to my roots in software engineering and lead a dozen engineers developing the software pre-loads for commercial and consumer desktop PCs. I accepted the new assignment, and went at it with gusto, refreshing my technical skills, leading my new team, and diving into Microsoft OEM Pre-Installation Kit (OPK) code with relish.....
Which was quite fortuitous, because about a year later I received a call from a Sony recruiter, offering me the moon and stars to come to California and help them ramp up their new PC division. Discussions with my wife and kids ensued, I finalized negotiations with my new employer, and we were ready to embark on a new adventure. Westward ho! My ten year career at NEC had come to an end, but a whole new career awaited me at Sony..... And moving from Boston, my hometown and where we had lived for the past fourteen years, to the Silicon Valley in California, was a exciting adventure just waiting to happen. Me, my wife and kids were all looking forward to having a California adventure..... little did we know all the peaks and valleys ahead of us.....
With the merger came redundancy in groups, and re-assignments to optimize human resources. In my case, over the years I had been promoted from product manager to senior product manager to product line manager heading up a staff of project managers and product planners for consumer PCs. The newly merged company didn't need two planning groups focused on consumer PCs, and since Packard Bell's strength was in consumer PCs, their group was chosen to stay in place. I was asked to go back to my roots in software engineering and lead a dozen engineers developing the software pre-loads for commercial and consumer desktop PCs. I accepted the new assignment, and went at it with gusto, refreshing my technical skills, leading my new team, and diving into Microsoft OEM Pre-Installation Kit (OPK) code with relish.....
Which was quite fortuitous, because about a year later I received a call from a Sony recruiter, offering me the moon and stars to come to California and help them ramp up their new PC division. Discussions with my wife and kids ensued, I finalized negotiations with my new employer, and we were ready to embark on a new adventure. Westward ho! My ten year career at NEC had come to an end, but a whole new career awaited me at Sony..... And moving from Boston, my hometown and where we had lived for the past fourteen years, to the Silicon Valley in California, was a exciting adventure just waiting to happen. Me, my wife and kids were all looking forward to having a California adventure..... little did we know all the peaks and valleys ahead of us.....
Let the good times roll
Working for five years in the Product Planning and Management organization of NEC's U.S. computer division was an awesome, exhilirating, and eye-opening experience. I learned so much about computer and networking technology, product planning, project management, and leadership. I had the most fun I'd ever had. The people I worked with were intelligent, collaborative, and really enjoyable to work with. Sure, there were exceptions to the rule, every so often a bad egg showed up, but they usually didn't last long and they were the exception rather than the rule..... I've lost track of how many generations of server, desktop, and consumer personal computers I developed during this time frame, but I sure enjoyed the work and the peope. It was exciting and rewarding. The good times had arrived....
The side benefits were great, too - many business trips to visit strategic technology partners, prospective vendors, hardware suppliers, and independent software vendors in California, Washington, Texas, Florida and other places. These road trips usually involved travelling with other team members from marketing and purchasing groups, and everyone had such a great team spirit. We all worked well together. I remember this one trip during the late fall or early winter, we were trying to confirm our selection of some specific components and manufacturers on the next generation of consumer desktop personal computers. Everybody wanted to get in on the action, all the different department heads wanted to have representation, nobody wanted to feel left out. So there we were, at some swank dinner restaurant by the marina in some nondescript seaside town in Southern California - fourteen NEC engineers, product planners, project managers, marketeers, and purchasers, and only two salesmen and a lone marketing guy from the vendor. Enjoying the warm weather, taking it all in after a busy day of non-stop meetings and negotiations. A few appetizers and pre-meals drinks later, I leaned over to my immediate supervision and whispered "We're picking up the tab, right? You're not going to stick them with a large bill like this, are you?" to which he replied "No problem, I'm sure our budget will cover it." So I guess maybe one or two engineers went overboard with extra appetizers (or something!), because the bill came out much higher than expected...... But we still picked up the tab, because we were ethical and didn't want the vendor to get stuck with an unfairly large restaurant tab just because we brought along "a few" extra experts to help close the deal.....
Another time I was flying between Boston and Huntsville, Alabama more times than I could keep track of. I was spinning up a contract manufacturing plant that would produce a a new generation of consumer PC. We were talking tens of thousands of units a month in volume, so it was important that everything was done in accordance with NEC's policies and procedures and all the technical specifications were met. I'd already had previous trips to Huntsville where there were no cars at the rental car lots, even though I had reservations. What good is a guaranteed reservation if it can't be fulfilled with a car? I even had one trip where I checked into a hotel late at night, was given my key, and as I opened to the door to what I thought was my hotel room I saw two baffled middle-aged women sitting in their pajamas watching television looking horrified at the stranger who just opened their door! I don't know who was scared worse, them or me. but nothing prepared me for the following exchange at hotel in Hunstville at about 11:00pm on a week night.
"I'd like to check in, please. Reservations for Phillips," I said matter-of-factly.
"Yes, one moment please..... Oh, I see it here. Here's your reservation. Sorry, we don't have any more rooms," the man behind the front desk said.
"But I have a guaranteed reservation," I said, "its guaranteed."
"Yes, well, I'm terribly sorry, but we don't have any more rooms," he replied.
"There must be some mistake, I have a guaranteed reservation that's guaranteed for late arrivals," I offered hopefully.
"I understand that, sir," the front desk clerk said, "but I'm afraid we can't honor it."
"Then what does having a guaranteed reservation mean around here?" now I was getting huffy.
"Well," he said, "it means you are guaranteed a reservation for a room, but I'm terribly sorry that we don't have a room to offer you, they are all taken."
"You have not a single room available in this whole wide big hotel?"
"No, sir."
"Not a single room? I find that hard to believe. What do you expect me to do? Its almost midnight, I just flew in after working all day, and I'd really like to get some sleep before my meetings in the morning," I suggested plaintively, figuring compassion was in order here.
"Well, actually, we have a conference room suite that has a sofa with a roll-away-bed. Would that work for you?" he offered.
"I'll take it. " I replied, and I was off to a fitful night of uneasy sleep in a huge conference room on a small sofa bed. Lucky for me it had a bathroom complete with shower.....
So aside from a few bumps along the road, everything was rather pleasant. Cool products, cool work environment, cool colleagues. What's not to like? Let the good times roll...... I can honestly say those five years working in the Product Planning and Management organization of NEC's U.S. computer division were the happiest five years of my professional life so far. Thanks for the memories, everyone, you know who you are.....
The side benefits were great, too - many business trips to visit strategic technology partners, prospective vendors, hardware suppliers, and independent software vendors in California, Washington, Texas, Florida and other places. These road trips usually involved travelling with other team members from marketing and purchasing groups, and everyone had such a great team spirit. We all worked well together. I remember this one trip during the late fall or early winter, we were trying to confirm our selection of some specific components and manufacturers on the next generation of consumer desktop personal computers. Everybody wanted to get in on the action, all the different department heads wanted to have representation, nobody wanted to feel left out. So there we were, at some swank dinner restaurant by the marina in some nondescript seaside town in Southern California - fourteen NEC engineers, product planners, project managers, marketeers, and purchasers, and only two salesmen and a lone marketing guy from the vendor. Enjoying the warm weather, taking it all in after a busy day of non-stop meetings and negotiations. A few appetizers and pre-meals drinks later, I leaned over to my immediate supervision and whispered "We're picking up the tab, right? You're not going to stick them with a large bill like this, are you?" to which he replied "No problem, I'm sure our budget will cover it." So I guess maybe one or two engineers went overboard with extra appetizers (or something!), because the bill came out much higher than expected...... But we still picked up the tab, because we were ethical and didn't want the vendor to get stuck with an unfairly large restaurant tab just because we brought along "a few" extra experts to help close the deal.....
Another time I was flying between Boston and Huntsville, Alabama more times than I could keep track of. I was spinning up a contract manufacturing plant that would produce a a new generation of consumer PC. We were talking tens of thousands of units a month in volume, so it was important that everything was done in accordance with NEC's policies and procedures and all the technical specifications were met. I'd already had previous trips to Huntsville where there were no cars at the rental car lots, even though I had reservations. What good is a guaranteed reservation if it can't be fulfilled with a car? I even had one trip where I checked into a hotel late at night, was given my key, and as I opened to the door to what I thought was my hotel room I saw two baffled middle-aged women sitting in their pajamas watching television looking horrified at the stranger who just opened their door! I don't know who was scared worse, them or me. but nothing prepared me for the following exchange at hotel in Hunstville at about 11:00pm on a week night.
"I'd like to check in, please. Reservations for Phillips," I said matter-of-factly.
"Yes, one moment please..... Oh, I see it here. Here's your reservation. Sorry, we don't have any more rooms," the man behind the front desk said.
"But I have a guaranteed reservation," I said, "its guaranteed."
"Yes, well, I'm terribly sorry, but we don't have any more rooms," he replied.
"There must be some mistake, I have a guaranteed reservation that's guaranteed for late arrivals," I offered hopefully.
"I understand that, sir," the front desk clerk said, "but I'm afraid we can't honor it."
"Then what does having a guaranteed reservation mean around here?" now I was getting huffy.
"Well," he said, "it means you are guaranteed a reservation for a room, but I'm terribly sorry that we don't have a room to offer you, they are all taken."
"You have not a single room available in this whole wide big hotel?"
"No, sir."
"Not a single room? I find that hard to believe. What do you expect me to do? Its almost midnight, I just flew in after working all day, and I'd really like to get some sleep before my meetings in the morning," I suggested plaintively, figuring compassion was in order here.
"Well, actually, we have a conference room suite that has a sofa with a roll-away-bed. Would that work for you?" he offered.
"I'll take it. " I replied, and I was off to a fitful night of uneasy sleep in a huge conference room on a small sofa bed. Lucky for me it had a bathroom complete with shower.....
So aside from a few bumps along the road, everything was rather pleasant. Cool products, cool work environment, cool colleagues. What's not to like? Let the good times roll...... I can honestly say those five years working in the Product Planning and Management organization of NEC's U.S. computer division were the happiest five years of my professional life so far. Thanks for the memories, everyone, you know who you are.....
Wednesday, September 22, 2004
Multiprocessor mumbo jumbo
I was having a great time in the System Software department, developing new boxes and customizing SCO Unix for NEC BusinessMate and PowerMate product lines. But fortunately or unfortunately the world was ordering more of these with other 32-bit operating systems on them. The customer demand for these boxes preloaded with SCO Unix was far less than that for preloads with Novell, Banyan or Windows. I saw this as a good opportunity to get some experience and exposure on the business side of the house, and for the next five years I worked in the company's Product Planning and Management organization....
My first projects in PP&M involved all 32-bit operating systems, system setup utilities, and EISA configuration utilities. This was new and different for me, getting to negotiate contracts and licensing agreements with ISVs and OEMs. Next I worked on large tower Intel boxes with the latest and greatest CPUs, graphics, and hard disks. This was great, because it combined my budding business acumen with my existing technical background. It was about at this time that the multiprocessor project came up..... By keeping my ear to the ground, taking a lay of the land, and understanding the intricate nature of the relationship between our marketing team in the US and the marketing team back at the parent corporation in Japan, I did not feel it would be successul. The US marketing team were focusing on products with volume, trying to get revenues up and business thriving. The Japanese marketing team were focused on building showcase products. In the Product Planning and Management team, we set the direction and tried to ameliorate any disagreements between our marketing colleagues on both sides of the pond. The multiprocessor project seemed doomed to failure because of a disconnect between these two entities, and therefore I didn't want any part of it..... I voiced my concerns to my immediate supervision, but we were under direction to complete the project from the technical perspective and let the marketing folks figure out the marketing plan.....
For the better part of nine months I watched this product get developed from the sidelines. A miserable, suffering colleague had the unfortunate displeasure of having to ride herd over its development and launch. Everytime the Japanese planning team came over to discuss, the US marketing team did their best to ignore this project and focus on better revenue generators. When the time came where all software and hardware development was completed and the product was ready for launch into the market place, there was a big blowup and disagreement..... I don't know how many millions were spent on this, but I sure felt sorry for the guys on both sides of the pond who had their career aspirations dashed because of its failure. I don't think even 20 units got sold..... At the end of the day, NEC's Intel multiprocessor PC running on SCO Corollary MPX operating system may have been a good showcase product, but it did not fair well in the marketplace.....
After all that time under development, all that multiprocessor mumbo jumbo and hot technology, and no compelling business arguments. No salesmen or marketeers could demonstrate to customers any software applications which took advantage of the multiprocessor capabilities..... oops. More than a few heads rolled at the next re-organization. I learned a big lesson then: better to work on products that actually get sold and generate revenue, than work on some cool new whiz bang product showcase with dubious prospects of making budget. Multiprocessor mumbo jumbo or not, at that time it was still the simplicity and elegance of uniprocessor personal computers networked in small workgroups that were being bought in large volumes, and that was, after all, what paid the bills.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
My first projects in PP&M involved all 32-bit operating systems, system setup utilities, and EISA configuration utilities. This was new and different for me, getting to negotiate contracts and licensing agreements with ISVs and OEMs. Next I worked on large tower Intel boxes with the latest and greatest CPUs, graphics, and hard disks. This was great, because it combined my budding business acumen with my existing technical background. It was about at this time that the multiprocessor project came up..... By keeping my ear to the ground, taking a lay of the land, and understanding the intricate nature of the relationship between our marketing team in the US and the marketing team back at the parent corporation in Japan, I did not feel it would be successul. The US marketing team were focusing on products with volume, trying to get revenues up and business thriving. The Japanese marketing team were focused on building showcase products. In the Product Planning and Management team, we set the direction and tried to ameliorate any disagreements between our marketing colleagues on both sides of the pond. The multiprocessor project seemed doomed to failure because of a disconnect between these two entities, and therefore I didn't want any part of it..... I voiced my concerns to my immediate supervision, but we were under direction to complete the project from the technical perspective and let the marketing folks figure out the marketing plan.....
For the better part of nine months I watched this product get developed from the sidelines. A miserable, suffering colleague had the unfortunate displeasure of having to ride herd over its development and launch. Everytime the Japanese planning team came over to discuss, the US marketing team did their best to ignore this project and focus on better revenue generators. When the time came where all software and hardware development was completed and the product was ready for launch into the market place, there was a big blowup and disagreement..... I don't know how many millions were spent on this, but I sure felt sorry for the guys on both sides of the pond who had their career aspirations dashed because of its failure. I don't think even 20 units got sold..... At the end of the day, NEC's Intel multiprocessor PC running on SCO Corollary MPX operating system may have been a good showcase product, but it did not fair well in the marketplace.....
After all that time under development, all that multiprocessor mumbo jumbo and hot technology, and no compelling business arguments. No salesmen or marketeers could demonstrate to customers any software applications which took advantage of the multiprocessor capabilities..... oops. More than a few heads rolled at the next re-organization. I learned a big lesson then: better to work on products that actually get sold and generate revenue, than work on some cool new whiz bang product showcase with dubious prospects of making budget. Multiprocessor mumbo jumbo or not, at that time it was still the simplicity and elegance of uniprocessor personal computers networked in small workgroups that were being bought in large volumes, and that was, after all, what paid the bills.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
Tuesday, September 21, 2004
Device Drivers: Polling or Interrupt Driven?
After a couple of years I was given a team, and led a half-dozen software development engineers in the System Software department on new BusinessMate and PowerMate product development initiatives. One of these projects involved a just-released version of the Intel 80486 microprocessor and NEC's customized flavor of SCO Unix. I helped some of my staff on writing device drivers for an OEM'd video display tube to replace the standard CRT, which used the serial port as /dev/tty01 instead of the video console port. Others I helped in the intricacies of the network drivers for TCP/IP and NFS and making sure the networking subsystem worked well on the new hardware platform. And one poor soul on my staff got the dubious distinction of figuring out why the system always crashed if loaded with more that 16MB of RAM - something to do with the memory software subsystem and a particular semiconductor chip we were using.....
But alas and alack, there are never enough software developers to go around when you need them, so I took on one task myself which caused more than a few all-nighters and many late evenings of diet cola and munchies from the vending machine. On this hardware platform that was still under development, the super i/o chip was integrated on the motherboard with some other glue logic, and for some unfathomable reason the damn thing would just freeze up and die everytime someone tried to send something out to the printer port. Normally in a PC the parallel port used for printing didn't cause much of a problem, but now it seemed on this particular puppy it was going to cause much wringing of hands and gnashing of teeth....
Slowly but surely, all the other product development issues were being finalized and achieving closure. The new OEM'd display, which the marketing folks called "The NEC Multiterm" (kinda catchy, eh? Not.) was ready for release, the BusinessMate 486/33E was ready to be launched, and one by one the technical software issues were being resolved. Except for the damn panic traps on the parallel port. I dived into the kernel to look for where the problems might lie. I checked the order in which all the system's different device drivers were booting up in the /etc/rc directory. I looked at the installation scripts for the some add-on desktop publishing packages. I tested the port using DOS and Windows commands, and I still couldn't find anything wrong. It was only under our flavor of SCO Unix that it didn't work..... None of my debugging and troubleshooting techniques seemed to be yielding any positive results.
The symptom was simple enough, easy to see. If you tried to print something, the system just shit the bed (that's a technical term, of course). It didn't matter what kind of printer was attached to the parallel port, there was an error message that spewed to /dev/console and the system froze up, accepting no further input, and had to be re-booted. So I started looking at the specific IRQ (I think it was number 9, but its too long ago to be sure) and how it was handled by the operating system's interrupt handler routine. The device driver written for IRQ9 was interrupt driven, and I noticed the state machine was fine up until it actually started receiving data. So I thought to myself, what if I changed the paradigm, mixed it up a bit, and caused the device driver to be polling rather than interrupt driven. There were some command line over-ride switches that could be thrown in the printer's application layer that called the device driver that could force it into a polling mode, so that it was waiting and expecting to receive data rather than sitting there doing something and getting interrupted. If I could make sure this would happen everytime someone tried to print something, then maybe I could get the system to stay up long enough to print a document.....
Sure enough, several code modifications and some brief validation cycles later, the problem was resolved. By changing the SCO Unix parallel port printer driver from interrupt driven mode to polling mode, the system no longer crashed when someone printed a document, and all was right with the world..... Who knew? Who would have thought that it would make a difference? Polling or interrupt driven? But it did. Device drivers. So compact, yet so complex. Go figure....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
But alas and alack, there are never enough software developers to go around when you need them, so I took on one task myself which caused more than a few all-nighters and many late evenings of diet cola and munchies from the vending machine. On this hardware platform that was still under development, the super i/o chip was integrated on the motherboard with some other glue logic, and for some unfathomable reason the damn thing would just freeze up and die everytime someone tried to send something out to the printer port. Normally in a PC the parallel port used for printing didn't cause much of a problem, but now it seemed on this particular puppy it was going to cause much wringing of hands and gnashing of teeth....
Slowly but surely, all the other product development issues were being finalized and achieving closure. The new OEM'd display, which the marketing folks called "The NEC Multiterm" (kinda catchy, eh? Not.) was ready for release, the BusinessMate 486/33E was ready to be launched, and one by one the technical software issues were being resolved. Except for the damn panic traps on the parallel port. I dived into the kernel to look for where the problems might lie. I checked the order in which all the system's different device drivers were booting up in the /etc/rc directory. I looked at the installation scripts for the some add-on desktop publishing packages. I tested the port using DOS and Windows commands, and I still couldn't find anything wrong. It was only under our flavor of SCO Unix that it didn't work..... None of my debugging and troubleshooting techniques seemed to be yielding any positive results.
The symptom was simple enough, easy to see. If you tried to print something, the system just shit the bed (that's a technical term, of course). It didn't matter what kind of printer was attached to the parallel port, there was an error message that spewed to /dev/console and the system froze up, accepting no further input, and had to be re-booted. So I started looking at the specific IRQ (I think it was number 9, but its too long ago to be sure) and how it was handled by the operating system's interrupt handler routine. The device driver written for IRQ9 was interrupt driven, and I noticed the state machine was fine up until it actually started receiving data. So I thought to myself, what if I changed the paradigm, mixed it up a bit, and caused the device driver to be polling rather than interrupt driven. There were some command line over-ride switches that could be thrown in the printer's application layer that called the device driver that could force it into a polling mode, so that it was waiting and expecting to receive data rather than sitting there doing something and getting interrupted. If I could make sure this would happen everytime someone tried to print something, then maybe I could get the system to stay up long enough to print a document.....
Sure enough, several code modifications and some brief validation cycles later, the problem was resolved. By changing the SCO Unix parallel port printer driver from interrupt driven mode to polling mode, the system no longer crashed when someone printed a document, and all was right with the world..... Who knew? Who would have thought that it would make a difference? Polling or interrupt driven? But it did. Device drivers. So compact, yet so complex. Go figure....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
Monday, September 20, 2004
What the hockey puck is a keiretsu?
During my ten years working at NEC, I learned so many things about Japanese business practices, the culture, the approach to problem solving, and the philosophies. Although I never became conversant in the language, I was happy with the way I was treated and grateful for the time and attention I was given. I don't think I was alone in this feeling - I believe many other non-Japanese have experienced the same kind of respect and professionalism working in world-class multinational corporations originating in Japan like NEC. At the American companies I've worked at, I've always felt like a number (as that old Bob Seger song) goes, but at NEC I felt like a valued individual. I think alot of this feeling had to do with the concept of the keiretsu (conglomorate), and the kandishoku (management class).....
The Sumitomo keiretsu emerged from the Sumitomo zaibatsu (monopoly) - all zaibatsu were banned in post-war Japan. At the core of a keiretsu is a bank and a trading company, and in NEC's case these were Sumitomo Bank, and the Sumitomo Trading (or was it Holding?) Company. The keiretsu counted on the loyalty of its employees and the cooperation of all its disparate business entities. The way it was explained to me by my immediate supervision, at any given point in time some of the keiretsu's businesses were profitable and some were struggling, so in synchronistic harmony the profitable ones always helped the struggling ones. This maintained balance and assured the continuing existence of the keiretsu as a whole. "Cool!", I thought, "Why didn't companies in the U.S. think that way?" I pondered rhetorically, "Why did U.S. companies always seem willing to eat their young in a short-sighted attempt to increase this quarter's numbers, instead of take a long-term, more collaborative viewpoint?".....
By now I was familiar with the different ranking systems and pecking orders in various and sundry American institutions. The military world had its various forms of ranks, whether it was the Army's private, corporal, sergeant, lieutenant, captain, major, colonel, general or the Navy's seaman, petty officer, chief petty officer, lieutenant, commander, captain, admiral and all the interspersed nuances of each level. The business world too had its various forms of rank, from assistant widgetmaker, associate widgetmaker, widgetmaker, senior widgetmaker, principal widgetmaker, staff widgetmaker, assistant manager, manager, director, VP, president and all the various layers within each management level. So I had a good frame of reference from which to learn the Japanese parlance, which I'd like to share with you. I hope you find it entertaining and interesting..... Below are the ascending order of the anglization of the Japanese words, and my understanding of their meanings. Any mistakes or misunderstandings are entirely my own fault - and any resemblence to reality is purely coincidental.
kan-di-shoku ---> management "class" (degreed professional)
ka-ka-richo ----> assistant manager (typically around 30 years old)
ka-cho ----> manager (typically 40 years old)
bu-cho ----> general manager (typically 45-55 years old, most employees don't attain it)
bu-mon-cho ----> senior general manager
tan-to-bu-cho ---> area vice president
fu-ku-sha-cho ---> VP, Senior VP, and Executive VP
sha-cho ---> President
so-dan-ya-ku ---> advisor, consultant (old, pre-retirement, but not a board member)
to-ri-shi-ma-ri-ya-ku ---> corporate board member, director
jo-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, managing director
sen-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, senior managing director
I suppose its possible that understanding a little bit more about Japanese business practices and culture may help you someday when dealing with international customers. Or maybe the big take-away is to be sensitive to all the different business practices and cultures extant in the business world today. When you are on a business trip to a far-away place, take the opportunity to understand and genuinely appreciate the people and their ways, and don't always assume that what you think something means in your culture may necessarily mean the same thing in another culture...... When you started reading this you probably thought a keiretsu was some kind of sport, I hope you now understand a little more about the concept and all that stands behind it.....
The Sumitomo keiretsu emerged from the Sumitomo zaibatsu (monopoly) - all zaibatsu were banned in post-war Japan. At the core of a keiretsu is a bank and a trading company, and in NEC's case these were Sumitomo Bank, and the Sumitomo Trading (or was it Holding?) Company. The keiretsu counted on the loyalty of its employees and the cooperation of all its disparate business entities. The way it was explained to me by my immediate supervision, at any given point in time some of the keiretsu's businesses were profitable and some were struggling, so in synchronistic harmony the profitable ones always helped the struggling ones. This maintained balance and assured the continuing existence of the keiretsu as a whole. "Cool!", I thought, "Why didn't companies in the U.S. think that way?" I pondered rhetorically, "Why did U.S. companies always seem willing to eat their young in a short-sighted attempt to increase this quarter's numbers, instead of take a long-term, more collaborative viewpoint?".....
By now I was familiar with the different ranking systems and pecking orders in various and sundry American institutions. The military world had its various forms of ranks, whether it was the Army's private, corporal, sergeant, lieutenant, captain, major, colonel, general or the Navy's seaman, petty officer, chief petty officer, lieutenant, commander, captain, admiral and all the interspersed nuances of each level. The business world too had its various forms of rank, from assistant widgetmaker, associate widgetmaker, widgetmaker, senior widgetmaker, principal widgetmaker, staff widgetmaker, assistant manager, manager, director, VP, president and all the various layers within each management level. So I had a good frame of reference from which to learn the Japanese parlance, which I'd like to share with you. I hope you find it entertaining and interesting..... Below are the ascending order of the anglization of the Japanese words, and my understanding of their meanings. Any mistakes or misunderstandings are entirely my own fault - and any resemblence to reality is purely coincidental.
kan-di-shoku ---> management "class" (degreed professional)
ka-ka-richo ----> assistant manager (typically around 30 years old)
ka-cho ----> manager (typically 40 years old)
bu-cho ----> general manager (typically 45-55 years old, most employees don't attain it)
bu-mon-cho ----> senior general manager
tan-to-bu-cho ---> area vice president
fu-ku-sha-cho ---> VP, Senior VP, and Executive VP
sha-cho ---> President
so-dan-ya-ku ---> advisor, consultant (old, pre-retirement, but not a board member)
to-ri-shi-ma-ri-ya-ku ---> corporate board member, director
jo-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, managing director
sen-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, senior managing director
I suppose its possible that understanding a little bit more about Japanese business practices and culture may help you someday when dealing with international customers. Or maybe the big take-away is to be sensitive to all the different business practices and cultures extant in the business world today. When you are on a business trip to a far-away place, take the opportunity to understand and genuinely appreciate the people and their ways, and don't always assume that what you think something means in your culture may necessarily mean the same thing in another culture...... When you started reading this you probably thought a keiretsu was some kind of sport, I hope you now understand a little more about the concept and all that stands behind it.....
Nippon Electric Company
At the end of the nineteenth century, the Nippon Electric Company was founded in 1899 by Kunihiko Iwadare in cooperation with the Western Electric Company of the U.S. to become the first Japanese joint venture with foreign capital. Eventually Nippon Electric Company grew to become the manufacturing arm of Nippon Telephone and Telegraph, just as Western Electric Company grew to become the manufacturing arm of American Telephone and Telegraph. Telephones and switching systems were the bread and butter of these companies, and while NEC and Western Electric enjoyed boomtimes during the manufacturing age, NTT and AT&T similarly reaped a bountiful financial harvest from the cables carrying all these telephone calls......
After I resigned from AT&T Bell Labs, I worked at a telecommunications start-up focusing on voice-response systems for the financial and trucking industries. Going from the world's premier research and development organization to a struggling startup proved to be too much of a culture shock, and I soon found myself hired at NEC. When I first arrived, NEC had several U.S. divisions affectionately known as "the seven sisters" involved in different computer and communications and technology endeavors. I had the privilege of working in the computer division known as NEC Information Systems, Inc. where we developed big iron, minicomputers and PCs. A couple of years later, we merged with the home electronics division to form NEC Technologies, Inc. and focused only on PCs.....
The Astra XL product family ran on an NEC variant of System V Unix called Astrix, and used the Motorola 68020, 68030, and 68040 family of microprocessors as their central processing units (CPU). The BusinessMate product family had the capability of running DOS and Windows, but also ran SCO Xenix or SCO Unix System V Release 2 and used the Intel 80386 and then the 80486 microprocessors as their CPUs. When I first arrived at NEC, my role was to teach NEC engineers and our customers' engineers everything I knew about NEC's flavor of Unix - Astrix and our customized versions of SCO Xenix and SCO Unix. I developed course curricula that was useful on all the hardware platforms. It was fun flying all around the U.S., Canada, and Central America talking to engineers about what I was passionate about - Writing Unix Device Drivers, Communications using UUCP, Bourne Shell Programming, and Unix System Installation, Operation, and Administration. I had alot of fun experiences in faraway places trying to create a null-modem using pinouts 2, 3, and 20 (or sometimes even 7,8 and 19) in an RS232C interface to illustrate running a uucico command from one BusinessMate or Astra XL to another.... factor in different revisions of firmware and peripheral devices, as well as interoperability issues between Motorola and Intel computers, and I was always kept on my toes......
I enjoyed teaching and traveling, but I yearned to be back in software development, so my immediate supervision let me code a bulletin board application system for the field engineers. I don't know if anyone actually used it or found it particularly useful when they could just call me up on the phone with questions, but I really enjoyed developing that system application..... before the days of automated bulletin boards (remember those BBS numbers?), before chat rooms and web hosting and instant messenger, I coded a complete system womb-to-tomb and learned alot and had a great time doing it.
I sometimes wondered if a century earlier the founders of NEC could have foreseen that their groundbreaking work in telephony would spawn a worldwide computer and communications conglomorate that not only had the leading market share in Japan for personal computers but also sold over 15,000 products all over the world..... Or that their initial investment in technology would enable a computer scientist like me to play with so many different variants of my favorite operating system on so many different hardware platforms at the same time.....
After I resigned from AT&T Bell Labs, I worked at a telecommunications start-up focusing on voice-response systems for the financial and trucking industries. Going from the world's premier research and development organization to a struggling startup proved to be too much of a culture shock, and I soon found myself hired at NEC. When I first arrived, NEC had several U.S. divisions affectionately known as "the seven sisters" involved in different computer and communications and technology endeavors. I had the privilege of working in the computer division known as NEC Information Systems, Inc. where we developed big iron, minicomputers and PCs. A couple of years later, we merged with the home electronics division to form NEC Technologies, Inc. and focused only on PCs.....
The Astra XL product family ran on an NEC variant of System V Unix called Astrix, and used the Motorola 68020, 68030, and 68040 family of microprocessors as their central processing units (CPU). The BusinessMate product family had the capability of running DOS and Windows, but also ran SCO Xenix or SCO Unix System V Release 2 and used the Intel 80386 and then the 80486 microprocessors as their CPUs. When I first arrived at NEC, my role was to teach NEC engineers and our customers' engineers everything I knew about NEC's flavor of Unix - Astrix and our customized versions of SCO Xenix and SCO Unix. I developed course curricula that was useful on all the hardware platforms. It was fun flying all around the U.S., Canada, and Central America talking to engineers about what I was passionate about - Writing Unix Device Drivers, Communications using UUCP, Bourne Shell Programming, and Unix System Installation, Operation, and Administration. I had alot of fun experiences in faraway places trying to create a null-modem using pinouts 2, 3, and 20 (or sometimes even 7,8 and 19) in an RS232C interface to illustrate running a uucico command from one BusinessMate or Astra XL to another.... factor in different revisions of firmware and peripheral devices, as well as interoperability issues between Motorola and Intel computers, and I was always kept on my toes......
I enjoyed teaching and traveling, but I yearned to be back in software development, so my immediate supervision let me code a bulletin board application system for the field engineers. I don't know if anyone actually used it or found it particularly useful when they could just call me up on the phone with questions, but I really enjoyed developing that system application..... before the days of automated bulletin boards (remember those BBS numbers?), before chat rooms and web hosting and instant messenger, I coded a complete system womb-to-tomb and learned alot and had a great time doing it.
I sometimes wondered if a century earlier the founders of NEC could have foreseen that their groundbreaking work in telephony would spawn a worldwide computer and communications conglomorate that not only had the leading market share in Japan for personal computers but also sold over 15,000 products all over the world..... Or that their initial investment in technology would enable a computer scientist like me to play with so many different variants of my favorite operating system on so many different hardware platforms at the same time.....
Sunday, September 19, 2004
Bourne Again
Matt Damon has done a few cool movies that I like alot, action packed with twists and turns. Nice distraction from the daily grind, and good entertainment. My wife and I saw "The Bourne Identity" when it first came out, and even rented the DVD, so when "The Bourne Supremacy" came out, we headed to the theater and saw that one, too. I actually like this one even better than the first one, if that's possible. It gives new meaning to the saying "Revenge is a dish best served cold.".....
But when I hear the word "Bourne", I don't think of Matt Damon and movies. When I hear the word "Bourne", I think about a third generation programming language known by the cognoscenti as the Bourne shell. Its not a compiled language, its interpreted, so its a lot quicker to prototype and debug your applications using Bourne shell. There were three flavors of shell in use in those days - Bourne shell, Korn shell, and cshell. The Bourne variant came standard with the distribution kit of the Unix operating system from AT&T Bell Labs. Korn was an add-on you could easily obtain from other researchers and software developers within the former Bell companies, and cshell came standard with the distribution kit of the Unix operating system from BSD (Berkeley Software Distribution).
While I started learning my way around the operating system with Bourne, I really got into the Korn shell in a big way. I started coding my prototypes and short projects using Korn shell. I even seriously considered naming our second child "Korny", but in retrospect I'm thankful my long-suffering wife talked some sense into me.
My professors in college use to say that we studied too many computer programming languages for the Computer Science degree. By the time I graduated, I had COBOL, Basic, RPG-II, Ada, Pascal, and C under my belt. Never used any of them in the real world except for C. But I guess all those languages helped me form an analytical approach to problem solving, heuristics, and algorithm development. By the time I learned C++ and more recently C#, fortunately or unfortunately I was no longer an individual contributor coding modules of a larger project, I led groups of project teams doing that. But I still remember developing this massive migration application for the computer center.....
I was into elegent simplicity at the time, and was starting to get bored, so I decided to code everything in Korn shell just to see if it could be done. We were running three different network topologies in the computer center - the superfast NSC hyperchannel, a reasonably fast AT&T version of ethernet called 3Bnet, and that good old standby serial interface, RS232. I wanted to make use of all available resources to migrate user data files between computer systems using any available media, either the three disparate networks or even the two different types of magnetic tape reels - 1600 or 6250 bpi (bytes per inch). My case and switch statements were tight, my error checking routines were flawless, and my conditionals never ended up getting linked to /dev/null. All using Korn shell syntax. After a couple of weeks of debugging and troubleshooting, I had taken a project that could have been done by a small team and easily dragged out to a few months and turned it into a one-man project completely prototyped soup-to-nuts, well-documented and defect-free. Korn shell ruled! How exhilirating. What fun. I accomplished what I set out to do. My immediate supervision was pleased. Some attaboys and pats on the back were received. To paraphrase a popular cartoon chihuahua from Ren & Stimpy, I felt like "We don't need no steeenkin' compilers!", even but for a brief moment. By using an interpreted language like Korn shell instead of a compiled language like C, I was able to prototype my project in record time with the desired results. It was a good feeling.....
So when I hear the word "Bourne", I don't immediately think of Matt Damon action-hero movies. I think of computer programming, and fondly remember the three different shells in use, and the time I used the Korn shell to prototype a massive migration application. But I bet there will be another sequel for Matt Damon. And it's sure to be a blockbuster like the first two, and Matt will surely look forward to being Bourne again.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I develop software, hardware, and systems for the consumer, multimedia, and telecommunications sectors. I have a passion for software and systems development. No time like the present - if you have a software idea and need help with software design, engineering development, and distribution, contact TranformTec, Inc. for a free preliminary consultation.
But when I hear the word "Bourne", I don't think of Matt Damon and movies. When I hear the word "Bourne", I think about a third generation programming language known by the cognoscenti as the Bourne shell. Its not a compiled language, its interpreted, so its a lot quicker to prototype and debug your applications using Bourne shell. There were three flavors of shell in use in those days - Bourne shell, Korn shell, and cshell. The Bourne variant came standard with the distribution kit of the Unix operating system from AT&T Bell Labs. Korn was an add-on you could easily obtain from other researchers and software developers within the former Bell companies, and cshell came standard with the distribution kit of the Unix operating system from BSD (Berkeley Software Distribution).
While I started learning my way around the operating system with Bourne, I really got into the Korn shell in a big way. I started coding my prototypes and short projects using Korn shell. I even seriously considered naming our second child "Korny", but in retrospect I'm thankful my long-suffering wife talked some sense into me.
My professors in college use to say that we studied too many computer programming languages for the Computer Science degree. By the time I graduated, I had COBOL, Basic, RPG-II, Ada, Pascal, and C under my belt. Never used any of them in the real world except for C. But I guess all those languages helped me form an analytical approach to problem solving, heuristics, and algorithm development. By the time I learned C++ and more recently C#, fortunately or unfortunately I was no longer an individual contributor coding modules of a larger project, I led groups of project teams doing that. But I still remember developing this massive migration application for the computer center.....
I was into elegent simplicity at the time, and was starting to get bored, so I decided to code everything in Korn shell just to see if it could be done. We were running three different network topologies in the computer center - the superfast NSC hyperchannel, a reasonably fast AT&T version of ethernet called 3Bnet, and that good old standby serial interface, RS232. I wanted to make use of all available resources to migrate user data files between computer systems using any available media, either the three disparate networks or even the two different types of magnetic tape reels - 1600 or 6250 bpi (bytes per inch). My case and switch statements were tight, my error checking routines were flawless, and my conditionals never ended up getting linked to /dev/null. All using Korn shell syntax. After a couple of weeks of debugging and troubleshooting, I had taken a project that could have been done by a small team and easily dragged out to a few months and turned it into a one-man project completely prototyped soup-to-nuts, well-documented and defect-free. Korn shell ruled! How exhilirating. What fun. I accomplished what I set out to do. My immediate supervision was pleased. Some attaboys and pats on the back were received. To paraphrase a popular cartoon chihuahua from Ren & Stimpy, I felt like "We don't need no steeenkin' compilers!", even but for a brief moment. By using an interpreted language like Korn shell instead of a compiled language like C, I was able to prototype my project in record time with the desired results. It was a good feeling.....
So when I hear the word "Bourne", I don't immediately think of Matt Damon action-hero movies. I think of computer programming, and fondly remember the three different shells in use, and the time I used the Korn shell to prototype a massive migration application. But I bet there will be another sequel for Matt Damon. And it's sure to be a blockbuster like the first two, and Matt will surely look forward to being Bourne again.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I develop software, hardware, and systems for the consumer, multimedia, and telecommunications sectors. I have a passion for software and systems development. No time like the present - if you have a software idea and need help with software design, engineering development, and distribution, contact TranformTec, Inc. for a free preliminary consultation.
Saturday, September 18, 2004
PDU versus RFS
A decade before the browser wars of the 90s there was the internecine battle within Bell Labs about which technology to use for sharing network files in the subsequent release of Unix - PDU (Portable Distributed Unix) or RFS (Remote File Sharing). System V Release 0, or simply System V, had been in use for quite some time. System V Release 2 was gaining new users every day, mostly people within the former Bell telephone companies, other telecommunications companies, and a smattering of university students, researchers, and some breakout companies trying to monetize the open software technology.
Of course, most bitheads weren't paying attention to what was going on with the System V side of the Unix house, but rather were more interested in what was going on with the BSD (Berkeley Software Distribution) side of the Unix house. The California regeants had already decided their upcoming release, still under development, was going to use a brand-spanking new technology called NFS (Network File Sharing) if they could only iron out all the kinks. History proved that NFS had legs, it was good foundation to build from. But I don't think anyone ever talks about PDU or RFS anymore, at least I haven't seen any recent articles about it. Just another faded memory of a dust-up between warring factions in the scrap-heap of commercially unsuccessful software technology.....
I was still a young pup by Bell Labs standards, and it was my job to upgrade existing mini-computers with new hardware and corresponding new system software. Mind you, these were not the days of packaged software and automated installation scripts with visual aids. These were the days of makefiles and option switches and command line orientation. I had gotten used to sysgen'ing new kernels on VAXen and 3B20 mini-computers - maybe it was fun the first dozen or so times I did it, but it was getting kinda old by now. Learning how to tweak the tunable parameters to optimize the system performance was exciting, and creating new /dev entries was a tad tedious, but formatting and partitioning all those physically huge disk drives (the size of frigging washing machines!!) and migrating all those user data files really required attention to detail and fortitude. So opening up the six-foot tall, eight-foot wide, three-foot deep blue monster and installing an Interlan NI1010A ethernet network card into the VAX's central nervous system shouldn't have been a big deal. Popping the card into an available slot wasn't an issue - sysgen'ing a new Unix kernel with the network interface software working properly proved to be more of a task than I had bargained for. Little did I know it would involve a couple of weeks of 18 hour days, more than a few all-nighters, and when all else failed, calling in one of the original coders of - you guessed it - a contender for one of the upcoming SVR3 (System V Release 3) networking technologies, THE developer of PDU.....
His name has long been relegated to those parts of my primary memory I can no longer access, but I remember he came from the development group in Denver. A ten-year Bell Labs veteran, he was very passionate about PDU, and was convinced this was the right network strategy to move System V into the future. During the days and nights we worked together, he told me about his ten years at the labs, all the interesting projects he had worked on, the brilliant people he had worked with. He explained that he was coming up on his ten year anniversary soon, within weeks in fact, and he was excited to see what would happen with his career. He said that at ten years, you either become a supervisory manager or a distinguished member of technical staff. If neither happened, then you knew you had no future at the labs and should either accept your fate as a solidly contributing MTS (Member of Technical Staff) with no possibility for promotion or else seek fame and fortune elsewhere, leaving gracefully. He was excited about his work with PDU, and saw it as his ticket to a cushy DMTS (Distinguished Member of Technical Staff) role with all the privileges and accouterments pertaining thereto. I was excited for him, and hopeful that he would achieve his dreams. I felt privileged to work beside this technical genius, learning so much about Unix, network software, system software, and the AT&T Bell Labs corporate culture. Eventually we got everything up and running, our debugging and troubleshooting all those long days and late nights had paid off. Everything worked like a charm. The VAX 11/780 was now running a BETA version of SVR3 using PDU as its networking technology. We partied with the group, toasted our success, and this icon of a technocrat went back to his group in Denver. I wished him good luck, much success and prosperity in the future......
A couple of months went by, and we maintained email contact regarding the upgraded VAX 11/780, as well as new system software and other developments and timeframes for the SVR3 project. Since I worked in an applied research division (Transmission Switching Systems), not a basic research division like the Unix development group, I used all my contacts to find out what was going on with SVR3, and my Denver friend had a lot of good inside information. Eventually I finally got bold enough to ask him how his 10-year review went.....
I think we all know the end of this story. The PDU versus RFS wars raged on for months, and ultimately the RFS faction won out. My Denver friend and all his PDU efforts became a mere footnote in the annals of technology history. It was a huge disappointment for him, and was probably one of the causes for him to reach his 10 year career point without getting promoted to either a supervisory management role or the DMTS role he so coveted. Within six months he was sniffing around for other companies to work at, and within a year he was gone. I haven't heard from him since. He probably landed a good job at one of those networking companies that were starting to sprout up like weeds, Novell, Banyan, maybe something like that. I really never knew for sure. We lost touch. But I will always remember that time, when I worked at the feet of a genius, cutting my technical chops on networking systems sofware and hardware, on the big iron, before automated install scripts and visual aids and support hotlines, before the browser wars..... during the internecine battle within Bell Labs over PDU versus RFS.....
Of course, most bitheads weren't paying attention to what was going on with the System V side of the Unix house, but rather were more interested in what was going on with the BSD (Berkeley Software Distribution) side of the Unix house. The California regeants had already decided their upcoming release, still under development, was going to use a brand-spanking new technology called NFS (Network File Sharing) if they could only iron out all the kinks. History proved that NFS had legs, it was good foundation to build from. But I don't think anyone ever talks about PDU or RFS anymore, at least I haven't seen any recent articles about it. Just another faded memory of a dust-up between warring factions in the scrap-heap of commercially unsuccessful software technology.....
I was still a young pup by Bell Labs standards, and it was my job to upgrade existing mini-computers with new hardware and corresponding new system software. Mind you, these were not the days of packaged software and automated installation scripts with visual aids. These were the days of makefiles and option switches and command line orientation. I had gotten used to sysgen'ing new kernels on VAXen and 3B20 mini-computers - maybe it was fun the first dozen or so times I did it, but it was getting kinda old by now. Learning how to tweak the tunable parameters to optimize the system performance was exciting, and creating new /dev entries was a tad tedious, but formatting and partitioning all those physically huge disk drives (the size of frigging washing machines!!) and migrating all those user data files really required attention to detail and fortitude. So opening up the six-foot tall, eight-foot wide, three-foot deep blue monster and installing an Interlan NI1010A ethernet network card into the VAX's central nervous system shouldn't have been a big deal. Popping the card into an available slot wasn't an issue - sysgen'ing a new Unix kernel with the network interface software working properly proved to be more of a task than I had bargained for. Little did I know it would involve a couple of weeks of 18 hour days, more than a few all-nighters, and when all else failed, calling in one of the original coders of - you guessed it - a contender for one of the upcoming SVR3 (System V Release 3) networking technologies, THE developer of PDU.....
His name has long been relegated to those parts of my primary memory I can no longer access, but I remember he came from the development group in Denver. A ten-year Bell Labs veteran, he was very passionate about PDU, and was convinced this was the right network strategy to move System V into the future. During the days and nights we worked together, he told me about his ten years at the labs, all the interesting projects he had worked on, the brilliant people he had worked with. He explained that he was coming up on his ten year anniversary soon, within weeks in fact, and he was excited to see what would happen with his career. He said that at ten years, you either become a supervisory manager or a distinguished member of technical staff. If neither happened, then you knew you had no future at the labs and should either accept your fate as a solidly contributing MTS (Member of Technical Staff) with no possibility for promotion or else seek fame and fortune elsewhere, leaving gracefully. He was excited about his work with PDU, and saw it as his ticket to a cushy DMTS (Distinguished Member of Technical Staff) role with all the privileges and accouterments pertaining thereto. I was excited for him, and hopeful that he would achieve his dreams. I felt privileged to work beside this technical genius, learning so much about Unix, network software, system software, and the AT&T Bell Labs corporate culture. Eventually we got everything up and running, our debugging and troubleshooting all those long days and late nights had paid off. Everything worked like a charm. The VAX 11/780 was now running a BETA version of SVR3 using PDU as its networking technology. We partied with the group, toasted our success, and this icon of a technocrat went back to his group in Denver. I wished him good luck, much success and prosperity in the future......
A couple of months went by, and we maintained email contact regarding the upgraded VAX 11/780, as well as new system software and other developments and timeframes for the SVR3 project. Since I worked in an applied research division (Transmission Switching Systems), not a basic research division like the Unix development group, I used all my contacts to find out what was going on with SVR3, and my Denver friend had a lot of good inside information. Eventually I finally got bold enough to ask him how his 10-year review went.....
I think we all know the end of this story. The PDU versus RFS wars raged on for months, and ultimately the RFS faction won out. My Denver friend and all his PDU efforts became a mere footnote in the annals of technology history. It was a huge disappointment for him, and was probably one of the causes for him to reach his 10 year career point without getting promoted to either a supervisory management role or the DMTS role he so coveted. Within six months he was sniffing around for other companies to work at, and within a year he was gone. I haven't heard from him since. He probably landed a good job at one of those networking companies that were starting to sprout up like weeds, Novell, Banyan, maybe something like that. I really never knew for sure. We lost touch. But I will always remember that time, when I worked at the feet of a genius, cutting my technical chops on networking systems sofware and hardware, on the big iron, before automated install scripts and visual aids and support hotlines, before the browser wars..... during the internecine battle within Bell Labs over PDU versus RFS.....
Bell Labs blotto
The year was 1985. I had just earned my BSCS, graduating magna cum laude; I was feeling great, the future looked bright. I did a round of on-campus interviews with AT&T Bell Labs, and got hired into the Transmission Switching Systems division. My wife gave birth to our first child, a beautiful, bouncing baby girl. My new employer relocated me from the city to the suburbs, to be closer to the office, and I felt we were on our way to the good life. Life was so G-O-O-D!! Happiness abounded. There was no limit to the potential of possibilities to learn and grow, professionally and personally. My career in high-tech was just beginning......
My immediate supervision at the Labs was an Irish gentleman, keen of mind, slow of tongue, and absolutely glacial in decision making. I fast learned that corporations have a timeline to decision making that lies somewhere between watching an ant crawl from one end of the room to another, to sitting on the kitchen barstool waiting for the coffee pot to boil. My work at the Labs was very intriguing, I felt like a kid in a candy store, so many computers, so much software and hardware, so much to learn and experience and do. I worked in the computer center, with an Amdahl 5860 mainframe running UTS 370 Unix, several AT&T 3B20-S (simplex) minicomputers, an AT&T 3B20-D (duplex: wow, a dual-processor!) minicomputer, and a Digital Equipment VAXen farm as far as the eye could see: VAX 11/780, VAX 11/782, and VAX 11/785 minicomputers, the stalwart workhorses of the minicomputer era.
All the minicomputers were running on AT&T Bell Labs System V Unix. All the source code for the Unix operating system was readily and easily accessible, even encouraged, and my officemate (a Chinese gentleman many years my senior) suggested that the best way to learn the inner workings of this famed operating system was by reading the file init.c line by line, painstakingly going over every function call and sub-routine, following all the links to system header files and other kernel and user mode modules, and reading that source code. Like I said, for a computer scientist this was like being a kid in a candy store. I sucked it all up, and read voraciously, and within months I actually thought I was getting pretty knowledgeable, and soon realized I was becoming a self-described Unix bigot......
One of the recruiting tools AT&T Bell Labs used on candidates was the OYOC benefit. For the uninitiated, OYOC was One Year On Campus, which meant that any eligible employee could apply for and receive one year's tuition in a computer science master's degree program at the univerisity of your choosing. The best part was during this one year, you would still earn a percentage of your salary (I think it was like two-thirds, or something like that). What a deal! What a company! What a country! This was great. So after six months of working hard in the Transmission Switching Systems division at AT&T Bell Labs, I hit up my immediate supervision for the OYOC benefit. The conversation went something like this.
"I'd like to apply for OYOC." I queried plaintively during one of our weekly one-on-one meetings.
"Hmmm. I think its only for eligible employees." was the response.
"Waddayamean? I'm an eligible employee aint I?" my naivetee must have been obvious.
"Well, I'm not sure, I'll have to check" my immediate supervision said, somewhat less than forcefully.
"Hey, sure, no problem, let me know." I replied eagerly.
A week later my immediate supervision informed me that I did not meet the definition of an eligible employee. I asked him why not. He looked me straight in the eyes, and very slowly and clearly enunciated that eligible employees were defined as women and minorities. Always quick on my feet, and thinking fast, I told him I was a Boston Jew married to an Hispanic Catholic, and the world didn't have too many of those, so wasn't I a minority, too? We both laughed half-heartedly, but the reality started sinking in.....
I wasn't eligible for this program, so I wouldn't be able to finish my master's degree as fast and with my employer's recruitment tool as I thought. What a disappointment! This certainly was a large contributing factor to my deciding to accept the position at this company. What a let-down to be told I wasn't an eligible employee. How could I possibly have foreseen that if I got hired I wouldn't be an eligible employee?
Lesson number one: note to self - always read the fine print. Bell Labs blotto. If they could dupe me with this, what else was I living under a mis-conception with at my employer? The honeymoon was definitely over now...... the kid gloves were off. Welcome to the workplace. Someone steeped in occidental philosophy would think "Don't get mad, get even". Someone exposed to oriental disciplines would accept the knowledge of the experience and learn from it. I chose the latter, and began contemplating next steps.
My immediate supervision at the Labs was an Irish gentleman, keen of mind, slow of tongue, and absolutely glacial in decision making. I fast learned that corporations have a timeline to decision making that lies somewhere between watching an ant crawl from one end of the room to another, to sitting on the kitchen barstool waiting for the coffee pot to boil. My work at the Labs was very intriguing, I felt like a kid in a candy store, so many computers, so much software and hardware, so much to learn and experience and do. I worked in the computer center, with an Amdahl 5860 mainframe running UTS 370 Unix, several AT&T 3B20-S (simplex) minicomputers, an AT&T 3B20-D (duplex: wow, a dual-processor!) minicomputer, and a Digital Equipment VAXen farm as far as the eye could see: VAX 11/780, VAX 11/782, and VAX 11/785 minicomputers, the stalwart workhorses of the minicomputer era.
All the minicomputers were running on AT&T Bell Labs System V Unix. All the source code for the Unix operating system was readily and easily accessible, even encouraged, and my officemate (a Chinese gentleman many years my senior) suggested that the best way to learn the inner workings of this famed operating system was by reading the file init.c line by line, painstakingly going over every function call and sub-routine, following all the links to system header files and other kernel and user mode modules, and reading that source code. Like I said, for a computer scientist this was like being a kid in a candy store. I sucked it all up, and read voraciously, and within months I actually thought I was getting pretty knowledgeable, and soon realized I was becoming a self-described Unix bigot......
One of the recruiting tools AT&T Bell Labs used on candidates was the OYOC benefit. For the uninitiated, OYOC was One Year On Campus, which meant that any eligible employee could apply for and receive one year's tuition in a computer science master's degree program at the univerisity of your choosing. The best part was during this one year, you would still earn a percentage of your salary (I think it was like two-thirds, or something like that). What a deal! What a company! What a country! This was great. So after six months of working hard in the Transmission Switching Systems division at AT&T Bell Labs, I hit up my immediate supervision for the OYOC benefit. The conversation went something like this.
"I'd like to apply for OYOC." I queried plaintively during one of our weekly one-on-one meetings.
"Hmmm. I think its only for eligible employees." was the response.
"Waddayamean? I'm an eligible employee aint I?" my naivetee must have been obvious.
"Well, I'm not sure, I'll have to check" my immediate supervision said, somewhat less than forcefully.
"Hey, sure, no problem, let me know." I replied eagerly.
A week later my immediate supervision informed me that I did not meet the definition of an eligible employee. I asked him why not. He looked me straight in the eyes, and very slowly and clearly enunciated that eligible employees were defined as women and minorities. Always quick on my feet, and thinking fast, I told him I was a Boston Jew married to an Hispanic Catholic, and the world didn't have too many of those, so wasn't I a minority, too? We both laughed half-heartedly, but the reality started sinking in.....
I wasn't eligible for this program, so I wouldn't be able to finish my master's degree as fast and with my employer's recruitment tool as I thought. What a disappointment! This certainly was a large contributing factor to my deciding to accept the position at this company. What a let-down to be told I wasn't an eligible employee. How could I possibly have foreseen that if I got hired I wouldn't be an eligible employee?
Lesson number one: note to self - always read the fine print. Bell Labs blotto. If they could dupe me with this, what else was I living under a mis-conception with at my employer? The honeymoon was definitely over now...... the kid gloves were off. Welcome to the workplace. Someone steeped in occidental philosophy would think "Don't get mad, get even". Someone exposed to oriental disciplines would accept the knowledge of the experience and learn from it. I chose the latter, and began contemplating next steps.
Subscribe to:
Posts (Atom)
