Skip to main content

Posts

Showing posts from 2014

Cohesion Breeds True Synergy

Aloha and welcome back!  It has been quite a long time since my last entry and, after having dealt with "real life" on a number of important occasions, I am looking forward to engaging you in thoughtful discussions once again. Lately, there have been examples, front and center in my professional life, where I have seen large opportunities missed.  Specific to my experience, these "cost" the company revenue in the sense that there was revenue that could have been earned but was not.  However, this could just as easily be a degradation of the professional credibility as a team (or member of a team), a lack of increase in operational efficiency (which does cost the company money in reality), etc.  So what is cohesion exactly? Dictionary.com states the definition as the following: cohesion [koh-hee-zhuh n],  noun - the act or state of cohering, uniting, or sticking together. That is "content free," but Wikipedia's summary of the topic is more hel

Death of a Programmer

During the 18 years that I was an application development professional, I took great pride in being a part of the elite group of geeks that could write an application that was needed by the business or desired by the public.  After all, I had spent 4 years in college formalizing the previous 5 years where I was cobbled away in the corner of the library or computer lab writing applications on a TSR-Model I (4K of RAM!), learning how to be a practitioner of the black arts. And so when I first started seeing process automation solutions like BMC Atrium Orchestrator and later CA Process Automation , I was aghast.  "How dare they!" I bellowed.  "They're taking away my own secret sauce that makes me stand out from the crowd!" I yelled.  Never mind that I left application development in 2005 - I just wanted to maintain my status as one of the computer programming elite. Lately, I've been getting more intimately involved with CA Release Automation .  And whi

I'm Looking for a New Job!...

...And you're reading this because you thought I was serious. A number of months ago, an EVP and member of the Executive Management Team emailed me to say he wanted to spend a few minutes chatting with me.  He and I had met, face to face, for the first time the week prior and I left a positive impression on him that he wanted to explore further.  In the spirit of full transparency, I allowed this meeting to stay visible in my work calendar in spite of the risk of my management chain seeing it and misunderstanding. So, of course, my manager did see it and did misunderstand.  He called me up a week after the appointment was made (but still before the actual date of the meeting) and seemed distraught that I didn't trust him enough to tell him if I were dissatisfied with my role.  This was the inspiration for a previous blog entry where I contrasted the concept of happiness versus contentedness in one's role.  Another part of my discussion with my boss, that I did not desc

Apple Did What?

Figure 1.  The iOS code exhibiting the SSL handshaking problem. (Originally published on www.servicevirtualization.com ) As a veteran of the application development industry, I can share plenty of horror stories about things that just "went wrong," from a tape backup software vendor not having a backup of my hard drive and then having the hard drive fail after I left, to projects that were canned after being in development for four years without a single beta release. During those 18 years, however, I can recall having to go through a very rigorous process while working on Wall Street whenever any code was considered a Release Candidate for production.  Essentially, any code to be rolled out to production had to pass a code review by your peers, and we all took delight in shooting down other members' code, all in the name of quality.  In one instance, a library of common routines that I created after refactoring a few of my own applications was stuck

WhatsApp, Revisited

While researching for my blog entry about the Facebook purchase of WhatsApp , I wanted to get the opinion of someone who has industry experience in this sort of thing.  So I reached out to my good friend and former colleague Mark Pilipczuk who is a marketing veteran with 25 years of experience and a former SVP at AOL.  My question to him was simple:  did the purchase make sense when taking the cost into consideration.  His answer is below. " I haven't spent any real time thinking about whether the $19B was a good/bad/indifferent deal.  What I have been thinking about is the YouTube acquisition by Google a few years back. Many thought the purchase for $1.65B in stock was excessive, particularly for a startup that had no real revenue model and had some serious potential copyright issues. In fact certain three letter ISPs looked at YouTube a couple of times prior to that and couldn't make the math work for an acquisition. What Google was betting on--it turned out correctl

WhyApp?

"Why? WHY?"  That's the question many people are asking themselves in the light of Facebook's historic $19B acquisition of instant message maker WhatsApp.  I must admit I was puzzled myself at the price tag, but found no shortage of Internet pundits (on Forbes and CNN Money , to name just two) willing to justify the cost based on a number of factors. Personally, I prefer quantifiable measurements.  And while my weapon of choice is typically financial metrics, such as NPV, IRR, and ROI, when it comes to M&A targets of this type where the primary driver is the size of the acquired company's user base, I switch to the advertising metric Cost per Thousand (users), or CPM for short.  ("M" is the Roman numeral for "thousand.") CPM rates are typically used for things such as online advertising and name list rentals (i.e. when you register on a website your information is rented to other companies who can specify that they want a pool of demog

Happy vs. Content

Some time ago, my manager at the time was having 1-on-1 calls with each of his staff to do a routine temperature check.  During my call with him, he asked me a common question:  are you happy?  This is not an uncommon question, to be sure, but I wanted to use this blog entry to highlight the difference between being happy and being content in one's employment situation. You may accuse me of splitting hairs, but the answer I gave to my manager highlights the difference between the two states.  I said to him, "I am definitely happy in my job.  You are a great manager; you have earned my respect as a business professional; and you allow me some latitude to do things that are outside of the scope of my responsibilities, which keeps my job interesting."  And then I continued, "but am I content with my role?  No." Three parts to this recipe How is it possible for someone to be happy but not content?  You can look up the definition of the two words if you wish,

Is Success the "End Game?"

(Originally published on www.servicevirtualization.com ) I've often felt that technologists are very good at thinking in terms of whites and blacks, since problems in the realm of IT are often expressed as one of two states:  either the server is responding, or it isn't; etc.  So it's unsurprising that executives with strong backgrounds in technology (vs. the CxO who is more business focused) think that success is often a good stopping point.  After all, if the server has an uptime of 99.9999% then you really can't do much better.  Can you? The answer depends on how you define "success."  It's easy enough to define a threshold and state that crossing that line is what success is.  But I would challenge you to justify the particular threshold that you have established.  For something like 99.9999% uptime that may be easy to do, but for something where the threshold is much lower (and, consequently, the potential upside is larger) you will have a much mo