Leaky Clouds

Joel Spolsky has two timeless pieces – Fire and Motion and The Law of Leaky Abstractions that are cornerstones of what I’m about to preach in this post. Please take a moment to read those articles by Joel – they’re almost 10 years old now, but are as relevant as ever.

My field, software engineering, is young and filled with changing winds. Client-server! No, web-based!.. Win32! No, PHP! No, Cocoa! No, HTML5 / JavaScript!.. Mainframe! No, rich client! No, thin client! No, mobile client!..

Entire industry moves like the trees under a powerful wind. I’ll stipulate that there are two factors in play here:

1. Psychology. The nerds that are in IT leadership positions are still very much gadget nerds. They love new stuff. They love playing with new stuff. They get the fanciest gadgets available on the market today. It’s not the Patek Phillippe crowd – they won’t go after a 100-year-old watch. They’ll go after a released-1-day-ago iPad v7, stand in line for it for hours, and pay through their nose. Just because it’s new – and new stuff is really exciting.
2. Incentives of market movers. Large technology vendors – particularly those in the leadership positions in their markets – want to keep customers in the spot where they want to buy again and again. Yes, we sold you a solution to your problems yesterday; but wait, now we have a NEW, MUCH BETTER way to solve that same problem! Yeah, you haven’t yet figured out half of the benefits of the old thing, but the new thing – it’s SO MUCH BETTER!..

Abstractions are an outstanding concept in science: instead of dealing with a bunch of low-level concepts, we create building blocks – and juggle those instead. It’s much easier to build a house if you have bricks; it’s much easier to perform a surgery if you don’t have to make a scalpel from the iron ore yourself.

Perfect abstractions require zero knowledge of how the building block was created. Such abstractions don’t exist – even the surgeon needs to know a little bit about the manufacturing process and chemical composition of the scalpel. For example, the scalpel has certain melting temperature and certain chemical characteristics (hmmm, I guess I shouldn’t put it into hydrocloric acid..).

In software, most abstractions are actually pretty bad. We like to think that the operating system hides away most of the complexities from the users – but it doesn’t. With Android, unless you know to kill apps that are running in the background, your battery life will be abysmal. Even with the famed iPad, you have strange artifacts like “zoomed mode” for old iPhone apps – total weirdness from the end-user point of view.

ORM (object-relational mapping), one of the most famous abstractions, is probably one of the worst (most leaky) – it will make you *think* that you don’t need to know SQL, but my god, that’s a horrible lie.

And yet, for system designers, these abstractions are frequently natural. As software engineers that build those abstractions, we are tempted to design for ourselves. In the end, we’re developers that build on top of those frameworks, too! “How am I not the target customer?..” That, of course, is a horrible mistake that causes unusable abstractions and frameworks that only their creators can understand.

Enter cloud computing. The latest excitement of our industry. The premise is really simple – instead of investing into technology upfront, pay as you go. Have someone else host that technology for you. That someone has vast economies of scale. Increase your investment easily in response to demand.

Sounds like a dream come true to the enterprise, right? I have 50 servers that are each utilized at 3%; I have IT staff of 10 to maintain these technology solutions; that’s really expensive. Instead, I come to a cloud vendor and pay a fraction of the cost.

Also sounds like a dream come true to an independent software shop, right? With my Find Touch project, I used to need a server in my garage – maintaining hardware, network connectivity, software stack, everything. Instead, the cloud promises to solve all of the same issues at a fraction of the cost.

With cloud computing, the situation is even worse. The field is in the “new and super hot” realm – just like those pesky iPads – and early adopters are discovering that the promise of “just move your existing application into the cloud” isn’t quite working.

The lower the level of the service that you’re moving to the cloud, the easier it is to map to what’s in your datacenter. The higher you go up the value chain, the harder the migration becomes.

If all you’re getting from your cloud vendor is hardware, everything is pretty easy from the technology standpoint. The problem, of course, is that the value add of such a service is pretty low. Yeah, I can spin up more machines and I don’t need to wait for DELL to bring those machines to my doorstep.

If, on the other hand, you want to move a VB6 application into the cloud.. And gain the benefits of deployment, scalability, billing, and all the other goodness of SaaS.. Good luck. You’re in for a treat. Get ready to essentially rewrite your software. Oh, you no longer are in touch with the vendor that wrote the source code?.. Too bad…

Moreover, the further you go from technology towards business aspects of cloud computing, the harder the cloud becomes to understand.

Recently, I worked on moving my web-based application from a standard hoster (1&1) to a cloud platform. I chose Amazon EC2 for my experiment. MY GOD, even as a technologist, I was at loss to understand what the costs for my migration are going to be. My old platform offered a pretty large VPS; they screwed up with customer service, so I was looking for a new home. All I wanted was an apples to apples comparison of price and major features. I didn’t expect major demand spikes – even though the ability to respond to them is nice. All I saw was myriads of instance types and datacenter options and pre-pay versus pay-as-you-go per minute of usage and my head was spinning after an hour.

My god, can’t you just tell me how much I’ll pay for the load I *know* I will have? A stupid little calculator for idiots like me that will tell me how much I’ll pay a month?.. To see if your service is worth it?..

Hosting vendors have this down to an art: show just three options, with a clear feature matrix; highlight the middle one with a tad more features than most people want; help upsell that one.

Cloud vendors? We have EC2 and S3 and fancy queues and monitoring with a cool name and you need to learn all of those proprietary acronyms and oh my god am I going to have to have my IT staff relearn everything?.. Cuz my CEO sure isn’t going to like this..

Seriously?.. You call that an easy switch to the cloud?..

I’m not saying the cloud is a fad. I am, though, saying that the cloud is in a state where it’s “hot and sexy because it’s new” and it’s primarily driven by technologists – not the business leaders. I want to see cloud vendors lead with value proposition – and better abstractions – and not with the newfangled technology “fire and motion.”

I want to see someone who’ll take my PHP app and will put it into the cloud – for the same price for a single VPS as my dumb old hoster. Using the paradigms I’m used to. I want my app to *not change at all* in order to adapt a cloud-based billing service. I want my storage to work just like I’m used to. I don’t want my IT staff to learn anything new – I want the framework to adapt to THEM.

Let’s greet the cloud – and hope that it grows up from the infancy it is in now.

Relationships are Everything

It’s so easy to get caught up in the day to day. Today’s firefighting. Major technical issue. This client screaming at you for yet another delayed shipment. That colleague throwing a fit because she wanted to take a vacation in September and your ship date is on September 30th and oh my god she’s really pissed off.

You’ll solve the immediate issue at hand. Of course you will – I have no doubt. Every hot tactical issue gets solved. Look back upon your past year – you’ll remember all those late nights, and you’ll see that it all worked out in the end.

Now look back 5 or 10 years ago. And try to remember the firefighting you did then.

What, having a hard time?.. The tactical stuff doesn’t float up in memory easily? What does come up?..

The people. The feelings. The relationships.

Oh.

Hmmm, interesting. I wonder what that means.

Fine, fine, I am a demeaning bastard. Give me a break, I just scored a free cocktail from a flight attendant.

What it means is that the only thing that matters in the long run is the people. You’ll forget the tactical firefighting. You’ll forget the problems you were working on. You’ll forget the problems, the technology, the contract terms, the programming language, the price you quoted, the vendor you hired…

The only thing you’ll remember are what you felt, who was by your side, who fell apart, and who really made sure everyone made it through.

You’ll keep that memory with you for the rest of your life – and so will the others that were next to you. When you are in need, the people that will help you will be those that have fond memories of you – it’s just as simple as that.

The only thing that matters is people. Invest in people around you. Make sure you comfort them in need. Motivate them when the tough times come and they need to work around the clock.

In the long run, it doesn’t matter how brilliant you are. If you’re an ass, you’ll end up nowhere (in our field, a particular section of nowhere is reserved for the arrogant asses). If you invest into people around you, they will cover for your misjudgements; they will forgive your stupidity; they will pay you back a hundredfold.

Go ahead and smile to the person next to you. Make them feel appreciated. Invest in them, make them better off. You’ll make a world a better place today – and you’ll be so much better off yourself tomorrow.

 ”Be nice to people on your way up, because you’ll meet them again on your way down.”

Game Theory

Humans are fantastic at finding holes in incentive systems. Give incentives to retail employees to push an add-on product – and they’ll find a way to do so without increasing your bottom line profits. Incentivize efficient behavior for testers – finding bugs! – and they’ll open millions of stupid, mindless little defects that waste your time.

Joel Spolsky says it best:

I’m always on the lookout for these incentive schemes gone wrong. There’s a great book on the subject by Harvard Business School professor Robert Austin – Measuring and Managing Performance in Organizations. The book’s central thesis is fairly simple: When you try to measure people’s performance, you have to take into account how they are going to react. Inevitably, people will figure out how to get the number you want at the expense of what you are not measuring, including things you can’t measure, such as morale and customer goodwill.

This has far-reaching implications into motivating employees that are far from commission-based. Let’s take two simple premises that many large companies follow:

1. Reward employees on a curve (ex. 20% great, 60% average, 20% under-performing). Force that curve at every level of the organization to make sure that no manager can claim that his team is “all stars” and thus pull the blanket of rewards to her group.
2. Tie financial rewards for an employee are to their individual success only – that is, their relative performance compared to their peers, as viewed by a panel of superiors. The logic goes, if you tie employee rewards to product success, you won’t have stars joining struggling teams as they don’t want to be weighed down by failure.

Let’s think about what you get in the end from this explosive combination from a purely logical, reasonable employee. They observe that their own upside is completely disconnected from the success of their product. As a result, two kinds of behaviors start:

1. Backstabbing and political play. This one is kind of obvious and everyone talks about it: if I’m rewarded based upon subjective opinions of my superiors, I better kiss up to the superiors and make my peers look bad.
2. Poor hiring. Who are the people doing the interviewing for new talent in your organization? The same people that you apply the incentives to. “If I hire mediocre people onto my team,” the thinking goes, “I will be a shining star at the next performance review!” Therefore, I’ll give a Hire to an intentionally bad candidate! This will ensure my continuous success in the organization, while decreasing the chances of the group as a whole to succeed.

OK, you’re in shock. You’re about to say that:

• I have to work with these mediocre people that I just brought into my group. Yeah, so what? I can hire really nice and really unproductive co-workers. I’ve seen plenty in my career.
• If everyone does it, the company will go under and there won’t be any cash wins for anyone! Yeah, except that when I see others doing it, I don’t want to be the one left out.
• This is plain immoral and intentionally malicious to the organization! Nobody would do this!

Do not ever place people in a situation where rational, logical behavior conflicts with their morals. Your counterpart will either suffer moral trauma (my wife really wanted to go to Hawaii, and there I am, not doing all it takes…) or do the thing that’s wrong for the business.

Here’s an intuitive way to approach this: if your friend lent you a MILLION dollars in cash tomorrow, with no contract or witnesses, with no trace of the transaction, would you be tempted to cheat them and pretend they never gave you the money? How about a BILLION dollars? An amount that will be enough to take care of EVERYONE you love and their grand-children, for the rest of their lives?..

Stop lying to yourself. There is a price for everything. People are rational beings, and they place value on things that are difficult to measure. You probably wouldn’t screw a friend for a thousand dollars, right? But for a BILLION? You would. Everyone would. Don’t put your friends in a position where their morals conflict with what’s good for them in terms of utility. And don’t ever do this to business associates, because I guarantee you – their loyalty to your business is lower than your loyalty to your friends.

Good fences make good neighbors. Good contracts make for fabulous partnerships.

Engineers Don’t Need Babysitting

I’ve recently written about the role of Product Managers in technology organizations. In that article, I looked at what PM’s SHOULD do. I’d like to discuss the subject of one personal pet peeve of mine around what many perceive to be a part of the PM’s role: babysitting engineers.

Let’s imagine the following setup: a 10-engineer technology startup. A single product manager, responsible for the roadmap (what will our agile shop produce – and in what order). They also have commitments to the CEO and the board of directors around business timelines – for example, external partnerships lighting up by certain dates. The PM is also a Scrum Master.

Let’s look at an issue: an engineer frequently forgets to report the remaining/completed hours for their work items. There are several possible interpretations of the issue, and thus, several possible solutions. Let’s look at each of them in detail.

Scenario 1: I “just forget”

The engineer is, presumably, simply forgetful. Someone needs to remind them – and that someone is the PM, as they’re the scrum master. The PM essentially then becomes a walking-talking alarm clock – “Did you update your hours?” – “How about you, did you update your hours?..” Why are you paying a HUNDRED GRAND PLUS to a babysitter?

Allow me to doubt the feasibility of this root cause. Does the engineer forget to put their pants on? Usually not. Do they forget to run unit tests before the checkin? No. When was the last time they forgot to check in a file and broke the build? Never really happened. Hmm. I guess they aren’t a very forgetful person, in general…

Scenario 2: I don’t see the value

The engineer simply doesn’t see the value of reporting their hours. They see it as process for the sake of process. The annoying PM keeps printing the stupid report, and there wasn’t a single time when anything useful came out of following this dance yet.

Possible solutions:

1) Your organization might not need daily stand-ups and up-to-the-day updates on remaining work.

WHAT? DID YOU JUST SAY THAT WE DON’T NEED SCRUM? I’m closing this page right now and unsubscribing from your stupid blog!

Yes, I did say that. Scrum is not a silver bullet. Following the book to the dot will get you nowhere. If your next release is 2-years out, if there are no ambiguity in what you’re building, if you don’t have any budgetary/business/technology interruptions (this does happen!), you can go with a good old waterfall. Or you can change scrum to reduce the amount of daily overhead.

2) Your developer doesn’t have the knowledge that will help them understand the value.

Who uses the roll-up reports? Just the management team, to make prioritization decisions? And you’re wondering why the individual contributor dev has no idea why they should keep updating it? Because they see no value for THEMSELVES. Help connect the dots for them: what you do every day helps us make better business decisions this way and that way, which in turn moves the odds of our business succeeding – and you cashing in on your stock options.

Scenario 3: I don’t give a damn

You’re convinced that the engineer truly understands the value? You talked to them a couple times about it? They still don’t do it?

There’s only one explanation left. They are a lazy ass and don’t give a damn. They simply aren’t hungry – they are coasting along without really caring for success. Get rid of them. They aren’t pulling their weight and are negatively contributing to the morale of others.

…

In parting, I’d like to once again state – your engineers don’t need babysitting. They need motivation. Treat them like adults, like your partners – and they will pay you back with frenzied dedication and an amazing product.

Arrogance, a fatal flaw

It’s curious to explore reasons for failure. We often discuss lack of vision, poor execution, wrong team as the killer for technology ventures. Allow me to shed some light on my recent favorite: arrogance.

Our field is full of socially awkward, yet really smart people, and many of them see such drastic intellectual superiority over many of their peers that they catch a fatal disease. At some point in high school, they got an A when everyone failed a test. Or, in their big company, they single-handedly saved the day and saved an entire department from slipping. Or they were a young prodigy in academia and wrote a famous paper.

This is when it hit them – dude, I’m really bright. Moreover, I’m so successful that it must be because I’m so much smarter than folks around me. In everything I do, I can only trust my own judgment – because it’s better than that of others.

And this is when they’re dead. Rand Fishkin, the founder of SEOMoz, calls this “the dangerous hubris of the startup world… the original and most serious of the seven deadly sins.”

They’ll be the ones to build a beautiful new gaming system, only to ship it with a controller that’s too large for half of the world to use. Or they’ll build a gorgeous car, and in their wisdom call it something that sounds great to their own ear – but means “it doesn’t go” in Spanish. All of these are the problems of leaders that think that they have the world in the palm of their hand – and they need no one else’s advice.

I stipulate that the cause of death of countless startups is the stubborn certainty of their founders to keep the original course. The reality is, most successful companies changed course drastically since their inception. You have to be flexible to admit a mistake, make a course correction before it’s too late, and vigorously attack the new path.

I’m a big believer that growth happens through what Einstein called a “school of hard knocks.” Through failure and humility, we see our own imperfection, and strive to improve on it. If we think we’re already perfect, the learning stops. The issue is that the others keep learning – and the world keeps evolving. If we keep using the same hammers for the new tasks, we’ll go extinct.

This issue is exacerbated by our talents. There’s a lot of really brilliant arrogant technologists out there. There ingenuity places them into leadership positions – thus putting not just them, but their followers in jeopardy.

Ask yourself, and be really honest – what were some of the mistakes I made in my professional life? What were some of my judgments that ended up being really false? I’ll point to Eric Sink’s Make More Mistakes article as a fantastic inspiration. The guy pours his soul out for the others to learn – it sure is a painful process, but my god, you get to internalize the lesson from those mistakes so well when you put them on paper.

Here’s a couple of my own dumb mistakes.

1. Do the market research before jumping head-first into a venture.

Cocktail Builder, my first entrepreneurial project. Premise is simple: put in the ingredients you have in your bar, it tells you what drinks you can make. Moreover, it says what stuff you can almost make – so that if you were to buy this one extra ingredient, you’d be able to make this cocktail.

Hey, I thought, when building this – I can sell the missing ingredients online, right on the spot! People are really likely to buy at this point! And so I go on and build the entire site. I market it, get pretty good traffic.. And then I start working on adding the monetization capabilities for selling liquor.

And that’s when I realize: you can’t really sell hard liquor online in the US. Ooooops. There goes that idea… and 8+ months of work with it.

2. There will always be people smarter than me. Find them.

Find Touch, my next entrepreneurial venture. My co-founder and I were convinced that we needed to amass a large client base by luring them with a free product offering, before we can follow on with a jobs marketplace that will leverage that client base.

Our first advisor and lawyer – thank you, David Marks – asked a seemingly obvious question: why aren’t you guys going for the real deal right away? Why not create a jobs marketplace immediately, instead of a silly entry offering that’s impossible to monetize? This question saved us months of work and ultimately made us a viable business.

Our second advisor – thank you, John Kueber – kicked us in the butt when we were obsessed with raising money. We spent 6 months agonizing over decks, financial models, introductions to angels.. All while we had basically no product and little traction on the marketplace. John made us drop this nonsense in favor of making the product sing – and in favor of getting some real customers use this product.

This is just the beginning of my list.. At this point, I know that I probably have more wrong hunches than right ones. That said, I do know one thing for sure – if you listen carefully, someone will quietly whisper a thought that never visited your head. You may just find a missing piece of the puzzle, if only you are willing to listen.

….

In parting, allow me to offer you a story from a friend. He was recently interviewing in a successful technology company for a senior position; he was speaking directly with a division’s vice president. He asked the VP a simple question: do you see the role of your employees as implementors of your vision, as an extension of your own capabilities?

The VP answered “yes, I simply cannot implement all of my vision myself, so I need my team to follow through on it. I frequently have issues where the team doesn’t quite understand the full scope of my intent, so they have trouble implementing it.”

Is it just me, or does that phrase smell like “I’m the smartest ass in town and I know the solution to every problem. I need cogs for my machine to execute my vision.” No matter how brilliant that guy’s vision is, his team is going nowhere. Innovation comes from diversity and from nay-sayers – from passionate, open, and respectful disagreements. Innovation comes from employees that have autonomy, mastery, and purpose as their motivators.

Interviewing – Challenge Your Assumptions

We’ve all been there. This guy comes in to interview, and three minutes into it you get this feeling. He’s all words and no action. He’s an arrogant bastard. He’s an architecture astronaut.

The interview goes on and on, and with every new topic, you find more and more reasons around why your initial sense is true. Hey, he didn’t give any credit to his peers. He invented it all himself, ha. What an ass!

This is all nice and great, except that you’re really sucking as an interviewer at this point. You had a gut feeling – you made a decision in the first few moments since you met the person – and you’re essentially looking for proof for your already made-up mind.

Since hiring superstars is your #1 priority, this mistake, in my book, is in the category of “lethal” if you’re a founder of a company and you’re bringing in employees #3, 4, and 5.

I’ll go further and stipulate that we’re hard-wired to be making such mistakes. There’s a curious amount of research on first impressions – the amount of judgment people pass on from the first 5 seconds of their interaction. In one leadership training class I took, they brought together a diverse group of people – completely different ages, industries, seniority levels. They had us pair up with a random person in the class, without exchanging a single word with the partner. Then, each of us gave some thoughts about the role, seniority, and industry of the other.

It’s shocking how precise – and how correct! – most of the observations were. The other person didn’t even open their mouth!..

The reason we’re hard-wired to make such a fast, snap call, I believe, is because of the basic fight-or-flight response. You need to judge whether the oncoming object is a danger to us; if we’re bad at it, we’ll get eaten. Thus, natural selection helps advance those that are good at it.

The problem, of course, is that at the workplace, the interactions are much more complex. You WANT to hire people that are radically different from you. You want to hire nay-sayers. You want people with radically different backgrounds, those that approach problems from the other angle. You want the whole of your company to be more than the sum of the individuals. If you fail to challenge your snap judgement, you’ll have a bunch of copies of yourself – creating an environment that magnifies your weaknesses, instead of compensating for them. Like the kings of the medieval times, you’re risking to suffer organizational hemophilia – the disease of “too much blue blood.”

Instead, I invite you to state the assumption that’s popping up in your head, and ask: what could this person say to convince me that they’re NOT what I think they are? If I think they’re not technical enough, can I ask them to code something? If I think they’re too full of themselves, can I ask them about a time when they were wrong? Literally, drop the current conversation topic, and abruptly switch to this new question.

Note that your first impressions, in some cases, will turn out to be exactly true. For example, one gentleman I recently met, I was getting a sense that he’s quite stubborn. I asked him to recall a time when he was convinced by someone else. A time when they thought one way was good and true, but someone jumped in and convinced them of a different approach.

The gentleman thought for a while, and came up with quite a telling example – as a business leader, he saw the technology group gravitate towards a process that he thought was dumb. He didn’t force his opinion down their throats; he let them have it their way. Note a subtle difference: he was NOT convinced himself; he merely allowed his people to make what he considers a mistake. This was quite eye-opening – by focusing on the assumption I made and precisely targeting it, I gave him an honest chance to convince me that my assumption of his stubbornness was wrong; instead, he reinforced it.

I encourage you to do the same the next time you’re interviewing someone for your team. What could this person say to convince me that they’re NOT what I think they are?

Platform as a Cop Out

It’s fascinating how the Microsoft glory isn’t letting people sleep well at night. Most entrepreneurs I talk to these days understand that the way to create a lasting advantage is to create a platform – something that entrenches you way better than an application.

Quoting Mr. Ballmer of Microsoft, “Developers! DEVELOPERS!! DEVELOPERS!!!“

The reason, of course, is that every application that gets built on your platform creates a sunk cost and deeper entrenchment. When a developer decides to take on your platform – when another company essentially BETS THEIR LIFE SUPPLY on your platform, you have an ally. That ally is selling their product to end customers. Every time they make a sale, you win tremendously – even if you didn’t make a penny from that transaction. The entrenchment of your platform – and thus, your lasting advantage – has just gone up, because it’s now more difficult to switch – all that money spent on the existing application is already gone. Why reinvent the wheel? We already have a VB-based Access 97 application that solves our problem..

You’ll laugh and point fingers at IT departments of companies stuck in 1997, but this logic very much makes sense. I’m Johnson & Johnson. IT is very much a SERVICE, not the core of my business. IT Department built applications that do the job. Fine, they aren’t great – they don’t scale or deploy easily, and there’s recurring cost to maintaining them that keeps going up – but compare that cost to switching to “free” Linux or super-user-friendly-and-sexy Mac OS, and the choice is clear. They’re sticking with Windows. Joel Spolsky describes this phenomenon well in his “API War” article.

Here’s a problem, though: everyone understands how great the platform advantage is, but few know what it takes to get a platform to win. They think “we have a sexy product; let’s now open up our product for various partners to build on top of! Come on, biz dev people! GET US SOME PARTNERS ALREADY!”

Ummm. How do I say this politely. Your platform story is a cop-out. A platform is viable only if it comes with several MAGICAL applications built on top of it. Applications that INSPIRE developers to play around and experiment. Applications that demonstrate the power and desirability of the platform.

Let’s look back at what Microsoft did when pushing Windows. The key to that victorywas MS OFFICE. Office is the flagship demo application that has always shown developers that OH MY GOD this platform can really be used to build amazing shit. When MS was pushing Windows over DOS, nobody really knew what this Graphical User Interface thing was about. Nobody trusted it. And KABOOM, here comes a fantastic suite that everybody wants. The application DRAGS THE PLATFORM by its ears towards success. Suddenly everybody wants to get Office – but to run it, you need Windows. More users have Windows -> more developers feel like creating software for it.

Another example: Apple and its iPhone development platform. Look back at iPhone v1. It had NO custom applications. Why? Because it made no sense to invest into the platform before there was a flagship set of products to demonstrate its power. As soon as end-users LOVED the mail app, developers took that app as a paradigm for stacked panel interfaces. Customers ENJOYED the tabbed music player interface – and developers started imitating it in their apps, too. If Apple took the Microsoft mobile phone road with its software back then – clunky built-in apps, no real flagship end-to-end scenarios to imitate – iPhone would have been a flop just like Windows Mobile 6.

Here’s the rub: nobody knows your platform better than you do. If YOU can’t ship a few amazing end-to-end solutions on top of your platform, how do you expect others to do it? External partners will start with a little tinkering – replace the MySQL adapter in your sample app with a SQL Server adapter. Maybe change the reporting engine from the sample MS Excel to Tableau. Oh wow, it still worked. I guess I’ll be brave and try a bolder modification of the sample app now.

If you’re building a platform – or even harder, a platform company – make sure that you have some SHINY end-to-end solutions built on top of it the day you ship.