Posts Tagged ‘business strategy’

You can’t “do integrity”

Sunday, June 8th, 2008

The procrastinators motto is “Don’t put off for tomorrow what you can put off until the day after tomorrow.”

Granted, I can be incredibly productive at times. So much so that I’m generally considered a “high output” person. But when I read The 7 Habits of Highly Effective People, I only got as far as the first one!

What I most remember from the book was the its focus on the Character Ethic and, especially on integrity.

Now, I’m not sure that I’ve found a good dictionary definition of integrity, but I love Alan Simpson’s quote on the subject, “If you have integrity, nothing else matters. If you don’t have integrity, nothing else matters.” Although the business world is frequently full of cutthroat competition and questionable behavior, I have to, in the end, agree that Simpson’s quote applies even to industry.

It is true that the business world can be a mean place. Our competitors are trying to “kill us.” I would love nothing better than to “crush them”. They’re trying to “take away our air supply.” We’re “gonna hit ‘em where it hurts.” It’s easy to see how the urge to succeed results in violent language.

Despite the uncouth exterior, there is a certain nobility in business, too. There are simply some things you don’t do. Some, like bribery and “side letters” you don’t do because they might land you in jail. Others you don’t do because, at the end of they day, they end up hurting you. Consider:

  • Lying
  • Overcharging
  • Failing to provide support
  • Although companies are frequently guilty of these, I think that most CEOs will tell you that these are, at the end of the day, tactics that end up hurting them. You can go out of your way to sell your product, but if can’t do what it claims, the customer will ultimately figure it out and be very unhappy with you. You want to get as much money as you can from a customer but no more! If a customer feels that they overpaid and if they learn that others inexplicably paid less, it will be very difficult to sell to them again.

    Ultimately, it is good business to act with integrity. One of my company’s greatest assets is that we’re “nicer” than our competition. Our competition will try to push unnecessary products or will flat out lie about us to try to win deals. More often than not, this behavior has actually helped us. Nobody wants to buy from someone they don’t respect.

    It pays to be be kind.

    Tear Down This (Fire)wall!

    Wednesday, June 4th, 2008

    My company sells software that allows users to login to non-Windows computers by using their Windows (Active Directory) credentials. We enable users to have a single username and password that works across all Windows, UNIX, Linux and Mac OS X systems.

    While there are several “vertical” markets in our space (retail, financial, government) one particularly interesting one is the educational market. Schools, universities in particular, frequently run many different operating systems and frequently need to provision (add) and deprovision (remove) user accounts as students enroll and graduate (or fail to graduate!).

    Microsoft Active Directory performs authentication by using the Kerberos protocol. This security protocol was developed by MIT and features various clever cryptographic techniques that make it valuable for user authentication. For various reasons, however, Kerberos is used exclusively within corporate networks; it is not used to authenticate users on the public Internet. Users will login to their desktop or laptop computers and will be authenticated by an Active Directory (AD) server within the corporate network. When users access resources within the corporate network their AD credentials are re-used (what is termed, single sign-on) and they are not prompted for any new credentials. When those users try to access resources (for example, secure web pages) in the public internet, however, other security protocols are used (for example, basic authentication over SSL) and the users typically have to type in new credentials.

    This concept of authentication inside and outside the firewall, I believe, may soon be a thing of the past and some educational customers demonstrate why.

    Although many universities still employ firewall-based architecture others have resigned themselves to a porous network and treat all computers as, essentially, being on the public Internet. From the IP addressing perspective, their computers typically are within a protected network. Few large organizations have enough publicly assigned IPv4 address space that they can put all machines directly on the Internet; they use private networks, NAT (network address translation) and routers/firewalls to allow external access. From the practical perspective, however, some universities are assuming that their internal networks might be completely compromised.

    Our product is of limited use to these schools. They still have private networks for things like accounting and student record keeping but these private networks are further isolated from their general university-wide networks. They might be in subnetworks within the general networks or they may be completely disconnected from any network that their students can access. They might choose to use our product within those private subnetworks but not to perform authentication throughout their general university-wide networks.

    I think we will see similar moves in corporate networks. At some point, organizations will concede that it is impossible to protect their entire internal networks. Rather than putting up a wall around their entire organizations, some companies will choose to protect critical applications (payroll, human resources, etc.) but will assume that all users in their general corporate networks are potentially hostile. This will actually make it easier to implement wide area networks as there won’t be much need for VPNs. A user in the corporate network will not be considered to be any more trustworthy than a user in the public Internet. Users in remote offices might as well come in directly through the public network instead of setting up a virtual private network. Either way, some more secure mechanism will have to be used when a user tries to access a protected resource.

    I’m still not sure what this mechanism will be. It might be some type of identity federation (based on Active Directory or not) but I’m concerned about slow adoption rates and the complexity of setting up federation between organizations. Perhaps Network Access Control and/or dual-factor authentication will play important roles, too.

    One thing I am sure of is that, like funeral parlors and waste management, the security business will never go away.

    Being Open

    Monday, June 2nd, 2008

    Likewise Software (originally Centeris) has always been an open source company. We built products on top of Samba, MIT Kerberos and OpenLDAP. We’ve been frequent contributors to these projects. We employ or contract several Samba developers.

    For a while, we played down this aspect of our company. Our reasoning was that enterprise software companies (in other words, “large companies that spend a lot of money on software”) are less likely to want to pay for open source software and more likely to value proprietary software. Indeed, one of our competitors would frequently bring this up with customers as a way to, we thought, devalue our software.

    A while back, we decided to stop being apologetic about open source and to, in fact, emphasize that we are an open source company. We released an open source version of our software, Likewise Open, and we made it available to various Linux and UNIX vendors. It is currently shipping with Ubuntu 8.04 and will shortly begin to appear in other distributions of Linux and UNIX. We continue to sell Likewise Enterprise (with many more features), but the open version is free.

    At first, this change in public posture required some internal selling. Our sales people, as a matter-of-fact, worried that we might be committing seppuku.Without recounting the details, let me say that they ultimately came around and were willing to give it a try.

    Our sales folk are now our #1 proponents of the open source approach - the strategy of being “open” about being Open has paid off tremendously. Why? Several reasons:

    1. There is a tremendous amount of “good will” around open source. There are customers who have chosen to buy our paid, Enterprise, product because we have an open product. 
    2. The Linux and UNIX distributors are much more likely to take your calls if, you too, are an open source company.
    3. Likewise Open is easy to download and install (it doesn’t require any Windows components, unlike our Enterprise version). When you have thousands of downloads, some of these inevitably turn into high quality Enterprise leads.
    4. When companies are interested in the Enterprise version but don’t yet have budget, we can propose they use Likewise Open in the meantime. Once they are using Open, they are much more likely to buy Enterprise than to buy a competitor’s product.

    All this said, the open approach is not a marketing strategy. You either are an open source company or you are not. You can’t pretend to be one.

    When we see a proprietary company all of a sudden release its products under an open source license and try to succeed on support contracts, we term this the Open Source Hail Mary play. Everything else has failed so they try this one last thing to see if they can be the next Red Hat. It doesn’t work that way.

    The open source community can be extremely tight knit. If you are an open source company, you’ve been contributing to the community on a regular basis. “Contribution”, of course, means contributing software, patches, etc. Contribution also means participating in technical discussions. It can also mean, periodically, contributing financially as well (for example, sponsoring conferences). You cannot declare yourself to be an open source company any more than you can declare yourself to suddenly be Italian. You either have to be born in Italy or (through a long process) become a naturalized citizen.

    Over the next few months, we are going to continue to expand our Likewise Open offering. We will be putting more features into the product and will be evangelizing its architecture. Once again, there is some concern that we might be giving away too much but, if history repeats itself, we will get much more in return.

    The Decline and Fall of Microsoft? Conclusion.

    Thursday, May 29th, 2008

    What can Microsoft do to reverse the trends that I’ve talked about in the last 4 posts? First, let me admit that it’s possible that Microsoft accomplish this by doing what it’s always done: grinding it out. Keep investing in Windows Mobile; keep pouring money into MSN; invest some serious money in the Zune business. Sheer grit and determination can overcome many missteps. If Microsoft can persevere, they can wait for a competitor to make a major mistake and then step in and take up the slack. The Sony PS3’s strategy for online gaming is an excellent example of this. Sony made a bad decision and the XBox business was able to profit from it.

    If I sat on the Microsoft board, however, I would be very nervous counting on the “grit” strategy. I would be looking for bolder ways to transform the company while it is still healthy and dominant. As I suggested in the first installment of this series, I think Microsoft has to start by asking itself the ultimate TQC question: what is it doing wrong that is causing it to generate bad processes? “Processes” here can refer to many things. Product design and software development processes are obvious places to consider but I think even more important are strategic planning and basic financial processes.

    Here are some of my answers to these questions based on 10-year old knowledge and interpolation with what I hear from friends who are still at the company:

    1. Project planning is resulting in poor products because the company has too many people involved in the design process. Microsoft Vista had dozens of program managers working on it. Microsoft Excel 1.0 had 1 program manager on it. Is the difference between Windows XP and Vista 50 times more complex to manage than Excel 1.0? If so, that’s probably a sign that you’re doing something wrong.

    Update 6/19/2008 - I’m told by Microsoft folk that my numbers are way off here, that it was more like 10,000 developers and 1,000 program managers. I just can’t fathom these numbers so I’m going to pretend that there were 1,000 devs and no more than 100 PMs that mattered.

    2. Complex products require huge development teams. There’s simply no efficient way to integrate the work of 1,000 developers. If you can’t do daily builds and if developers have to wait weeks for their checkins to appear in public builds, you’re doing something wrong.

    3. Thousands of developers and testers coupled with dozens of program managers require large product units and even larger business units. If your business units are large, few people in the unit will truly feel “P&L responsibility”. If a unit fails to meet its goals, the BUM may feel the pain but the 2,000 people who work for him/her are not going to get fired and probably won’t even see smaller bonus checks. On the other hand, if you have too many business units, you’ll inevitably end up with overlap and turf wars between them.

    4. When a company is as large as Microsoft, central planning is impossible. You can set broad goals but there’s no way that the Chairman and CEO can know enough about all their businesses to be able to contribute much to their strategies.

    There’s a common thread that runs through all of my observations: Microsoft is simply too big. Its size results in poor planning, bad financial management and excessively complex products/projects that are impossible to manage.

    Just like the Roman Empire, I think it’s time for Microsoft to split itself up - even more so than Rome/Constantinople. Windows, Windows Mobile, XBox, MSN, Windows Live, Applications, Hardware: each of these should become a completely separate entity. Each of them should have its own CEO and its own stock. More importantly, each of these should be its own financial entity. They can start out with a good “stake” from the parent company, but each would have to demonstrate its own profitability or go out of business. Can you imagine the MSN Company trying to fund a leveraged buyout of Yahoo for $40B+ if it only had $4B in the bank? A smaller company would never contemplate such a boneheaded move.

    Ideally, each Baby Bill would start out with 1,500-2,000 people.  I suspect that over time, several of them would shrink in order to maintain their profitability. The “parent” company could, perhaps, keep the Windows business and Microsoft Research and could provide services to the others in order to avoid needless duplicating infrastructure.

    The companies would still have the problems I’ve been describing. The Microsoft brand would still be less cool than Apple’s; Microsoft would still need to improve its management culture; Microsoft would still need to learn how to succeed in areas other than technical prowess. The Baby Bills, however, would allow managers more freedom to experiment and would provide more incentives for success and more penalties for failure. Removing the $20B+ safety net would make Microsoft a more dangerous place to work and, I think, Microsoft would benefit greatly from it.

    The Decline and Fall of Microsoft? Part 4.

    Wednesday, May 28th, 2008

    Contrary to what many believe, innovation has been central to the success of Microsoft. The reason why some people fail to see the innovative side of the company is because they are looking in the wrong places. Although there has been some innovation in the visible side of software, the innovation at the API level has been much more significant.

    Before leaving HP in 1986, I’d spent my last year there working on something called “New Wave.” This project was trying to figure out a software architecture that would support many useful concepts: embedding of documents inside other documents, providing “links” between documents. allowing “drag & drop” between documents. If these features sound familiar, they should. They were enabled by Microsoft’s “OLE” (Object Linking and Embedding) in the late 80s/early 90s. The concept wasn’t invented by Microsoft (nor HP for that matter) but the software mechanism to make the features available and to work in an efficient process was. OLE later morphed into “COM” - a technology that did much to enable software “building blocks”.

    Does anyone remember CORBA? Can anyone name 3 major applications that supported it? Probably not. While Microsoft was developing OLE and COM, the Object Management Group (composed of HP, IBM, Sun, Apple and others) was trying to do the same in an multi-vendor, cooperative, fashion. While Microsoft solved the problem exclusively for Windows on Intel architectures and only when using C++ or Visual BASIC, The OMG was trying to solve the problem in an OS-idependent, architecture-independent, and language-independent fashion.

    We used to say at Microsoft, “if one person can do a job in a year, two people can do the job in two years.” Imagine the efficiency of 11 companies trying to design CORBA by committee.

    OLE/COM is but one example of Microsoft innovations at the API level. The Windows GDI API unified display and printing code (in a way Postscript/News once sought to do). The DirectX API allowed game developers to efficiently access hardware while exploiting graphics and sound accelerators provided via Windows drivers. ODBC, ODB and ADO (and now LinQ) have provided progressively easier ways of accessing data in relational databases.

    As a long-time software developer (pre Altair!), I can say that C# and .NET, coupled with Visual Studio, have made programming incredibly productive and even “fun” again.

    Beyond these are things like the Microsoft Office API (including the functionality available to built-in macros), the various specialized APIs (driver layer, speech, NLP, etc.) and now Silverlight 2.0 which promises to finally make writing Web 2.0 applications a less-than wretched experience.

    Alas, these API innovations are no longer enough to guarantee Microsoft’s success.

    Windows has 90%+ of the desktop computer market and 65% or so of the server market. Microsoft office has 90%+ of the office software suite. 

    Improving the Windows or Office APIs does not help Microsoft make any more money. Operating systems and productivity applications pretty much do what people need them to do. Purchase decisions are beginning to be made based on criteria other than technical prowess.

    To continue to succeed, Microsoft needs to grow into new markets. Here are a few businesses that Microsoft is trying to develop:

    • Mobile-phone and PDA software (Windows Mobile)
    • Web-based search (advertising)
    • Game consoles (XBox) 
    • Media players (Zune)
    • Enterprise line-of-business applications (ERP, CRM, etc.)

    In which of these markets has Microsoft achieved at least 50% market share? None! 30%? None! The XBox is most successful at just under 30% market share (sales, not units). Windows mobile is at about 6% (below the iPhone!). MSN? 10%. Zune? Even my Microsoft friends laugh when I tell them I bought a Zune.

    That the XBox is the most successful business is consistent with my focus on APIs; game developers are still very much interested in platform features, tools and functionality.

    Microsoft started as a developer tools company (Microsoft BASIC). Some prodding by IBM got it into the OS and, thus, the API business. As it grew its Applications business, it never lost its core focus. I heard Bill Gates once comment on how “all great applications have been programmable” and I think he was stating, not only a truism, but also Microsoft’s subconcious mantra.

    As long as tools and APIs were driving product functionality and purchasing decisions, Microsoft would see tremendous success. Now that this is no longer the case, Microsoft will begin to suffer.