Tag Archives: business

Losing the Signal

I have a confession to make. I had a BlackBerry for a few months and I hated it. To be fair I was late to the party. By the time I used one, the iPhone had launched and and the BlackBerry was not the Cool Thing any more.

Nevertheless, a few years before that I remember seeing them all the time around the City and Canary Wharf. They had an impressive tactile quality, where were people continually touching them, scrolling the side-wheel or the spinning the little trackball on the later models. By the time I started using one, the hardware itself was still great but the software was incredibly dated.

Clearly there was something about the BlackBerry that was interesting. This book, “Losing the Signal,” is about the maker of the BlackBerry.

It’s a history going from the foundation of the company to roughly the resignation of the co-CEOs that had run the company for years. Since we all know how it ended, the simple chronological structure works well. The authors interviewed just about everyone on the record. They managed to get both the good and the bad out of those they talked to, making it neither a hagiography nor uncritical.

In the end, the story is one of hubris. Early on, it was a huge advantage to the company. Everyone else knew that mobile email was at best niche, at worst a waste of time. Everyone, of course, was wrong and RIM was right. But in 2007, when the iPhone launched, that hubris started to work against them.

Unlike rival handset makers, Lazaridis didn’t come to Barcelona armed with 4G prototypes, but with a physics lecture... Now he was going to explain to Verizon why they were wrong about 4G.

I’ve seen this behaviour before – from my own employer at times – the supplier telling the customer that they’re Doing It Wrong. They knew that the next generation of cellular technology wasn’t a big deal – the speed was unnecessary, the power consumption was a problem – knew that customers valued the security of the BlackBerry above the web browser of the iPhone or the App Store of Android. Only this time they were wrong.

I knew some of the story, having seen the devices and read articles, especially post-Android, post-iPhone, but it was good to read the whole history. The access the authors had to the key people is impressive and they made good use of it.

In the end, if you’re interested in the earliest successful smartphones, BlackBerry is the company to follow and this book is well worth reading.

Ops is undervalued

I made the mistake of suggesting that there was a blog to be made from this tweet. This is that post.

People still underestimate the value in (Developer|Operator) Experience when building platforms and honestly it’s kinda shocking to me.

If you want to win mindshare you need to make your tools actually usable. If you don’t want to lose it you need the same.

First: I agree with the sentiment. Maybe not to the same extent as Danielle, but I fight the same battles in my day job. I wanted to say this now because, on reading the rest, you may think the opposite. What follows is an explanation of why this is a common situation. I don’t mean it as a justification.

In summary, making software work for ops teams is not a focus either for software companies or internal development teams because of at least three reasons:

  • It’s not a business driver
  • Ops are not the buyer
  • Engineering is run by developers

Naturally there are exceptions to these rules. Every company is different. These are observations, not rules.

Working at the “coal face” it’s easy to forget, but people don’t buy software. They buy a solution to a business problem1. These days, that solution is often software but you don’t buy a new product because it’s cool2.

A driver might be to get a report generated more quickly, or to provide a new service to paying customers, or to reduce the costs of some infrastructure3.

But, you argue, the ops team are the people who keep the system up and running. How can this new system generate reports or deliver a service if it’s not running reliably or has not been provisioned correctly?

You’d be right. Sadly, organisations are often not structured to recognise that fact. The IT teams tasked with making everything run smoothly are frequently in a completely different reporting hierarchy from “the business.” I put “the business” in quotes as I hear it described that way all the time, but it’s this us-versus-them philosophy that brings many issues, including how ops get sidelined4.

With “the business” and “ops” being in separate reporting structures, one or the other has to sign off on the purchase of new software (unless it goes way up the organisation) and that’s always going to be “the business.”

The buyers normally consult the ops team, but ultimately they’re going to put their own needs first. Objections that the ops team have will end up in the business case, but likely in an appendix that no one will ever read.

This makes no sense because, as we all know, most of the expense of a system occurs after go-live. But monitoring, management and deployment are not things at the top of mind of developers and business users.

But even in the IT organisation, the ops team frequently don’t get the attention they deserve either. Anecdotally, this is because IT leadership come from the development team. Their outlook on IT is therefore skewed towards making things rather than keeping them running. I see the same challenges for testing teams. Or, indeed, the lack of testing teams.

This lack of buy-in from the ops team is endemic. I see it in companies buying and using software. I see it in companies that make and sell software5.

At this point, what I would like to be able to do is say, “And the solution to this terrible problem is…” Sadly there is no easy answer. Saying “You should listen to your ops team” is both obvious and unhelpful. Making tools useful for the ops team to get mindshare is a good way to get your software on a shortlist but maybe not enough to clinch that sale.


  1. I’m talking here about software used in a business of course, but the difference between this and personal use isn’t as great as you might initially imagine. You buy a game to solve the “problem” of boredom. Very few people buy software because it’s software. ↩︎
  2. You might buy it because this, specific solution is cooler than the other options. ↩︎
  3. That is, even in the case where it’s the infrastructure that is being improved, the business case is not “make the ops team more efficient” but “make the cost of operations lower.” ↩︎
  4. There’s another blog in how toxic “the business” as a concept is. This isn’t that blog. ↩︎
  5. This is a chicken and egg problem. Do software companies fall into this trap because they’re run by developers? Or is it because they’re selling to companies who have already fallen into the trap? ↩︎

App Store pricing

Like Spotify’s complaint before it, yesterday’s “App Store Principles and Practices” document from Apple got me thinking.

Apple talks a lot about free apps not paying anything (which isn’t entirely true of course), and it’s always pitched as a feature.

But the more I think about it, the more I think it might be a bug.

This effectively means that all paid apps have to subsidise all free apps. Is this what’s preventing Apple from reducing the 30% fee?

Why should free apps get a free ride? How much value is Facebook getting from Apple? My apps don’t take your personal data and use it for advertising purposes — something that Apple seems to be in favour of — yet I have to pay 30% and Facebook pay nothing.

Of course, we have to consider unintended consequences. It would be fair for Google and Facebook to pay, but what about a game I wrote in my spare time? Or that useful utility I wrote for myself that I’m altruistically sharing?

I don’t know is the short version. Should they charge for each download? Or each App Review? They’d probably need exceptions for certain categories, but also to be very careful that the system doesn’t get gamed.

The other thing Apple doesn’t directly address is Spotify’s most compelling argument: the fact that Apple charges 30% commission for apps that provide digital services, such as streaming music or books, means that no one other than Apple can actually allow in-app purchases in those categories. Apple only allow in-app purchases with the fee yet many of these services just don’t have 30% “spare” that they can give Apple. Apple Music and Apple Books don’t have to play by the App Store rules and they don’t have to pay the 30% fee.

If anything, this is harder than than the free freeloaders problem. It doesn’t seem right that Apple couldn’t compete in these categories, yet the platform owner clearly has a huge advantage here.

Anyway, at least two issues here and no firm conclusions. They always say “bring me solutions, not problems.” Sorry, I failed.

ReWork

The gist of “ReWork” is that anyone can be an entrepreneur but you don’t have to follow the Silicon Valley tradition of seeking venture funding and providing foosball tables. If you do things right — different — you can make a sustainable business in a more traditional, bootstrapped way, and you don’t have to continually grow to be considered a success.

Many of the “lessons,” however, apply to almost any knowledge work. They subscribe to a less-is-more philosophy, and the book follows that example by being a quick read. Like the less-is-more outlook, that doesn’t make it bad, only very targeted.

If you’re looking for a complete framework for running your business, this isn’t it. (But then you’re probably not the kind of person who is likely to start a business I guess.) Instead, it’s a collection of related vignettes touching on varied aspects, from funding to focus to culture.

Much of the advice is so obvious that you wonder why more people don’t do it. But the fact that people don’t is exactly why their business (was 37signals, now Basecamp) has been a success and that writing about how it works doesn’t give away any “secret sauce.” It’s not that people don’t know the “secrets.” It’s more that people don’t have the discipline to stick to the programme.

Overall, there’s a lot of good material in here. If you own or work for a small company where you can potentially put the advice into practice, it’s probably worth a read.

Creativity, inc

I wasn’t entirely sure what to expect when I started “Creativity, inc.” In the end, it’s a bunch of anecdotes strung together to explain certain business practices that Ed Catmull believes has made Pixar successful. Half biography, half management guide if you like.

While the stories are engaging, and he has a surprising degree of humility, it’s difficult to see how many of the ideas can be successfully translated to other industries. Which is not to say that he’s wrong just that I wouldn’t expect to take his advice and immediately apply it to your workplace.

For example, he spends time talking about how the Braintrust has helped identify or solve many problems. But how would that work for a software product? (Is software engineered or crafted as other creative endeavours are? That’s a longer discussion for another time but, in short, I think it qualifies as creative.) I can see how it might help a review of the UX or visuals but the most helpful people for a code review would likely already be on the project. You need so much domain specific knowledge that I have a hard time seeing how an independent third party could provide anything other than high-level or generic development advice.

The other thing that stood out is that much of the advice would only work for companies awash with cash. I absolutely see the value in, say, teaching a designer how to code or engineers how to draw (two examples from Pixar U) but calculating that value and showing an ROI? Even the “rich” companies I’ve worked for have generally shown a preference for “shareholder value” and profits than hard to justify benefits for employees. Maybe that is why Pixar is successful where so many others are not, but you’d need a lot of spare money to support these endeavours, and not every enterprise is in an industry where they could afford do so even if they were willing.

Ultimately I’m a sucker for anything Pixar, so I found it to be an enjoyable read, and it certainly gives food for thought. Maybe that’s all it’s supposed to do. But will I be directly applying many of these lessons to my day job? Sadly not.

My delicious.com bookmarks for December 16th through December 21st

  • On this day in 1996, Apple acquired NeXT – Fifteen years ago today Apple effectively started its upward trajectory.
  • Why big companies can’t change – "At the polar opposite position from big industrial companies sit startups, nearly every one of which begins with an effortless expression of why? Big companies ask What? then How? but almost never Why?"
  • Christopher Hitchens, 1949-2011 – "I’m not going to say R.I.P. I don’t think Christopher Hitchens is at rest. I don’t think there is anything left of him to rest. I think he is dead. But tonight, I’ll be raising a glass of Scotch in his honor. The world is a better place because he was in it, and it is a sadder, less interesting place now that he’s not."