• Editorial voice: remarkably consistent (still global, still obsessed with traditional media, neighbourhood culture and Japan – not that any of those are necessarily bad things).
• Design: looser than it was, but for the better I think. I’ve enjoyed the pushing and prodding at the edges of what was a pretty rigid system (I described it as ‘staid’ in 2007 which was probably a little unfair).
• Website: still disappointing. Search is abysmal and micro-content difficult to pin down. It’s crying out for a proper directory – I would love to be able to pull up a list of great homeware stores in Bangkok, for example, but can’t, partly because every search result is treated alike, but also partly because many of those recommendations are buried in longer articles.
• Brand extensions: many seem to be here to stay. Shops have closed and new ones opened, events run, podcasts made, all without detracting from the essence of the magazine itself. The travel guides are excellent and, with hindsight, seem like such an obvious thing that could have been done earlier.
• Price: it’s gone up by a bit more than inflation, but not egregiously so.

I still buy it.

We’ve borrowed heavily from a number of product management, engineering and design philosophies over the years – Agile and the Lean Startup movement among others.

And I think that the way that company culture and processes evolve as a company grows is a bit like distributed version control.

In the early days, everyone’s working out of the master repository. Ideas about new ways of working are quickly adopted by everyone – everyone’s ccontributing back into the master repository.

But it doesn’t take too long before this becomes impractical. The company grows, and making sure that the way your team works is precisely aligned with the way the other team works starts to obstruct progress and limit opportunities for experimentation. There might even be merge conflicts, where one team actively disagrees with the other about the best way to do something.

So, inevitably, people start branching. Creating parallel tracks of process and culture, based on the original – but without any obligation to achieve consensus.

And arguably this is healthy. As a leader, we have an obligation to create the best possible working environment for everyone here, and that includes giving people the freedom to experiment with new processes; to do things differently; to branch the Made by Many master.

But there’s a problem with this. As the company grows, people get comfortable in their branches.

At Made by Many, we have some very long established client relationships, each with its own branch. Some of this is for good, practical reasons – different clients often work very differently and that has an impact on the way we work with them. Some clients are well-versed in evidence-based decision making and full stack innovation processes. Some aren’t. Some have much more intensive internal communication requirements than others. Some are simply further away from our offices than others.

Sometimes the branches we create started to bend away from the master repository to such an extent that a newcomer might wonder whether they were really part of the same repository at all.

And that’s mostly because we got lazy about merging.

This can have one of two effects (not mutually exclusive):

• Annoyance at wasted effort – “I wish I’d known that!”. When you realise that a colleague on a different project has already solved the problem you’ve been grappling with, but when you haven’t made the effort to communicate with them. (Or vice versa.)
• Genuinely distructive conflict – “What on earth are you doing?”. When you realise that a colleague who’s new to your project tries to work in a very different way to you. (Or vice versa.)

The first is almost always annoying, and almost always easily rectifiable. Merge conflicts are rare, and in this scenario it’s often it’s just that the merge happened too late. We’re solving this one by finding better ways of sharing best practice between project teams, and between people who specialise in particular things (like the best way to make use of online usability testing platforms, or the best way to demo an interactive prototype). More frequent merging back into master takes a bit of time, but for small changes like this, it’s relatively painless and almost always beneficial to another team very quickly.

The second is tougher. When deep-set differences in perspective, approach and outlook start to develop, merging takes a lot longer. For example, some of those branches became customer-centric to the point of excluding other inputs that might have influenced outcomes for the better. We haven’t found a good catch-all solution to this one. Thankfully it hasn’t happened very often in the history of Made by Many. But through more frequent merging of everything we’ve learned about the work we do, we can massively reduce the likelihood that we’ll be tripped up by an inconvenient branch.

This might happen formally, but is more likely to happen informally – you need to talk with people to run a complex merge, after all. That’s why it’s important to create a workplace which encourages this sort of dialogue at every level. We do this in part at a micro level; making sure that everyone has an opportunity to contribute not only to the work that’s done, but how it’s done. There are no gatekeepers to what ‘official’ process is; everyone is encouraged to contribute back to the master repository. And at the macro level, we try to make sure that people get as broad a range of experience as possible, balancing the desire among our clients to have a consistent team with the need to cycle people across different projects to give them exposure to new ideas and practices.

It’s by no means perfect, but deliberate awareness of these needs is often enough to spur us into action when we detect a signal that something isn’t quite right. If we can detect problem branch behaviour early, then it’s going to be much easier to fix things.

It gives you much more control over HomeKit than the Hue app, allowing you to set up groups containing any number of lights, rooms combining these with sensors and other controls, if you have them, as well as zones containing multiple rooms. It also allows you to manage multiple homes if you’re fortunate enough to have more than one.

You’ll need to set up Siri using the Hue app first, and then open the Home app to customise things further. For example, you could set up a ‘Downstairs’ zone – and then tell Siri to turn the downstairs lights on.

As well as being able to specify rooms and zones, Home also allows you to set up more complex triggers – turn the lights off when I leave the house during hours of daylight, for example. It also includes a much more flexible Today widget and Watch app than Hue offers. Highly recommended.

via Serenity Caldwell / iMore.

Over the last two days, mainstream UK media seems to have caught up with the fact that airport retailers here ask passengers for boarding passes so they can avoid paying VAT on the purchase when the person in question is travelling outside of the EEA.

While it’s slightly unfair to frame this as tax avoidance, it’s reasonable to assume that ‘duty free’ savings are passed on to customers rather than withheld by the retailer. Some do, some don’t.

But this isn’t the only legitimate concern a passenger should have about handing over their boarding pass.

Each boarding pass displays a barcode-encoded PNR, or passenger name record, commonly referred to as a booking reference. These are typically alphanumeric and 5–6 characters long.

With a PNR and a surname, also present in the barcode data, the retailer gets access to the passenger’s entire itinerary.

For a simple flight booking, this might not include much of interest – their seat number, for example, or the names of the other passengers.

But in many cases it will include much more, especially if the itinerary is booked by a travel agent and includes accommodation and other services. Hotel names and addresses, car rental details and so on could all be revealed – a veritable stalker’s paradise.

Quite simply: handing over your boarding pass to an airport retailer allows them to spy on your travel plans.

Despite reassurances from some that they don’t store the data – Boots confirmed to me that it doesn’t – it’s only a matter of time before this process is abused.

Corporate travellers are most at risk at present, as their PNRs are likely to refer to complete itineraries rather than just a single flight, and it wouldn’t be surprising if corporate travel policies and security teams started to ban employees from handing over this sort of information.

It’s time for airport retailers to end this practice. A simple visual check of the boarding pass will reveal the destination, which is sufficient information to allow them to fulfil their VAT obligations. Collecting swathes of personal data is both egregious and incredibly risky.

Original photo by George Veletsianos. Some rights reserved.

There’s been a flurry of writing over the last couple of weeks about the future of jobs ‘below the API’ – the notion that a new class of work is emerging in technology products somewhere between fully automated tasks performed by robots and managerial tasks performed by humans.

Of course, it’s reasonable to be concerned about having large numbers of people in ‘task execution’ roles – and as Anthony Kosner points out in his Forbes article, they’re sitting targets for potential future redundancy through automation, much like their 17th and 18th century predecessors whose piecework jobs were swallowed by large scale industrialisation.

Much of the recent writing about Uber (in particular) focuses on the effect that this modern-day piecework has on the labour market and welfare. This ‘Uberization’ is dangerous, says Farhad Manjoo’s piece in the New York Times last month, quoting Robert Reich, former US Labor Secretary:

“I’m glad if people like working for Uber, but those subjective feelings have got to be understood in the context of there being very few alternatives,” Dr Reich said. “Can you imagine if this turns into a Mechanical Turk economy, where everyone is doing piecework at all odd hours, and no one knows when the next job will come, and how much it will pay? What kind of private lives can we possibly have, what kind of relationships, what kind of families?”

Reich calls for greater regulatory oversight of independent contractors, and acknowledges that this isn’t unique to Uber: it affects supermarket staff and construction workers just as much as it affects those summoned by a mobile app.

So if we fixed the employment framework, would we still have a problem? Probably. Peter Rheinhart writes of Uber’s workforce:

The skills they develop in driving are not an investment in their future. Once you introduce the software layer between ‘management’ (Uber’s full-time employees building the app and computer systems) and the human workers below the software layer (Uber’s drivers, Instacart’s delivery people), there’s no obvious path upwards.

But I’m not sure this is it – I think there’s a fundamental omission here. Uber drivers and Instacart runners do have an opportunity to develop their skills, particularly in customer service. While their car-steering functions may be eclipsed by robots, their ability to interact with other humans is likely to be useful for a little longer at least. In economies driven by the service sector, these skills are immensely valuable, and the ‘path upwards’ may lie well outside of the worker’s current domain.

So what is the problem with jobs below the API? Perhaps it’s just something about the APIs that we don’t like:

Research shows that evidence-based algorithms more accurately predict the future than do human forecasters. Yet, when forecasters are deciding whether to use a human forecaster or a statistical algorithm, they often choose the human forecaster.

It turns out this isn’t limited to long term future-gazing. UPS drivers have mixed feelings about the Orion system that determines route planning:

The experience can be frustrating for some who might not want to give up a degree of autonomy, or who might not follow Orion’s logic. For example, some drivers don’t understand why it makes sense to deliver a package in one neighborhood in the morning, and come back to the same area later in the day for another delivery. But Orion often can see a payoff, measured in small amounts of time and money that the average person might not see.

The rise of opaque intelligence – or, if you like, the creeping spread of computer says no – is a legitimate cause for concern. Taken to the extreme, this diminishing agency, Manjoo says, sounds like a ‘hellish vision of the future of work’.

But this assumes a lot about how these APIs are created, deployed and managed. It’s inevitable that this shift in the way work is planned and allocated will continue, but who says that the systems that do so need to be blunt and unfeeling (or say no all the time)? If the APIs are the problem, let’s treat this as a serious and fascinating design challenge, not a doomsday prophecy.

Andy distinguishes between nice ideas and good ideas, describing them as the ‘currency of creative industries’. Mike seemingly adopts a counterposition – ideas are inventory – but goes on to say:

Ideas should be handled like a vital commodity. They are critically important but if we’re consuming any form of human resource such as creativity and ingenuity in order to create and validate those ideas and consider a spectrum of alternatives, then we’re creating more work than we need to create and that’s wasteful.

The literal interpretation suggests that we should constrict the flow of ideas in order to relieve the demands on our time and energy; there’s a more subtle reading which Andy captures in the segregation of nice from good:

We confuse good ideas with what are just ‘nice’ ideas. Nice ideas are things we like in that low-commitment, fuzzy kind of way, as they whizz past us and onto the pages of trend blogs.

Which brings us back to validation – the challenge isn’t that we have too many ideas, or that ideas are a burden from the moment of conception. Just that ideas which hang around too long attract ‘disproportionate value’, as Andy puts it. And when Mike says that ‘one person’s idea can often be just another thing the rest of the team is forced to deal with’, he’s absolutely right. An idea in this context is essentially a hypothesis, and this is the sort of thing Eric Ries talks about in The Lean Startup when he argues that we should be asking should it be built? rather than can it be built?

Is the answer to this simply to speed up the validation process? To eliminate the possibility that an idea or hypothesis will stay around long enough to become inventory? Potentially, yes – particularly at the early stages of client work at Made by Many, we typically generate hundreds of ideas, but rapidly shred them down to a handful of realistic candidates for customer development.

But even this process isn’t insulated from new input – and for good reason. And, in a world where a live customer development process is trivially easy to set up, it’s impossible to free ourselves entirely from continual new input; new ideas emerge from customer communities through the social web, for example, as well as from product owners (in the broad sense), and both in incredible volumes.

Still, this notion of the lingering hypothesis is an interesting one, and merits more thought. If we can match the pace of validation to the velocity of idea generation or input, can we eliminate inventory? A just-in-time validator, perhaps? Minimal time to validation feels like a good thing.

If you have a 3G-capable iPad, or another tablet and are currently paying for data in the UK, Fogg is worth a look.

The free package includes 1GB data per month in the UK, Denmark and Sweden – no credit card or other payment details required. A no-brainer for if you currently pay for a SIM in your iPad in any of these countries and don’t use a lot of data, and even better if you travel between them.

There’s also a no-contract premium package which offers 10GB per month for 99 SEK (£10.26 at the time of writing), and which will in theory offer access in additional countries in due course. Italy, Ireland and Austria are next on the list.

The signup process is minimal, and my SIM arrived within a couple of weeks. It’s a combined mini-SIM and micro-SIM package, so scissors may be required for devices which use a nano-SIM. Once the SIM has arrived, it’s a case of inserting it, and going through a one-time login process to activate it. I had to switch data roaming on to get it to acknowledge a data connection.

It seems to be using Three’s network, and one can only assume that Fogg has negotiated a low enough wholesale price point with Three and potentially other operators in Denmark and Sweden to make the free product viable. The technology is subject to a pending patent which describes the method for switching between ISMIs (mobile subscriber identities) when the user’s location changes, which may make it easier for Fogg to manage the wholesale agreements.

In any case, quite how long the free package will remain is unclear – it seems like a fairly irresistible freemium entry point. Here’s hoping this is the start of a revolution.

I’ve been using it since then, more or less, and it’s been an invaluable tool, less for taking advantage of coincidences, as very few others still use it, but more as a means of self-reflection, reminiscence, and for filling out visa application forms.

It sounds like this is how the creators use it too:

It still works, and I still use it, but more and more for recalling details of the past for various bureaucracies. I’m still proud of what we did as a little team there.

Every so often the fail snail appears, and every time it does, I worry that it might break forever. But it seems to soldier on, thankfully. Of course, TripIt does most of the same things – but it lacks any sense of elegance. And that’s important, particularly when you’re travelling at the speed of a house mouse.

An emotional piece from Astro Teller at Wired talks about the notion of the ‘10×’ or ‘moonshot’ project, and highlights something we encounter every day at Made by Many:

When you’re working to make things 10% better, you inevitably focus on the existing tools and assumptions, and on building on top of an existing solution that many people have already spent a lot of time thinking about … But when you aim for a 10× gain, you lean instead on bravery and creativity.

Building on the work of others isn’t necessarily a bad thing – and indeed, iterative approaches to design and development can often result in efficient processes and effective results. But without the bravery and creativity (particularly the former) which Teller references, we often find that the people we work with end up trying to tackle the wrong problems.

What if we could replace all that effort on the wrong problem with the bravery to change the very question itself? Often, if you step back and apply enough audacity and creativity, the new perspective you get makes doing the impossible, possible.

We place huge emphasis on validation – not only of the assumptions we’ve made about the target audience for a product, or about the commercial model which might underpin it, but most fundamentally of the brief itself. Skype in the classroom grew out of a brief, with related assumptions, which would have taken the project and product in a very different direction to that which it’s taken over the last two years.

‘Challenging the brief’ isn’t exactly a new idea, but the extent to which we adopt a binary view – that everything is either hypothesis or evidence – makes for an approach which values both the power of iteration as well as the energy of bravery and creativity.

via Anthony House.

It details an investigation by Verizon into a perceived security breach in a US company’s VPN system, noting an active endpoint in Shenyang when the employee whose credentials were being used was at his desk in the US.

To cut a long story short – he’d couriered his two-factor authentication token generator to a contractor in China, who was happily carrying out a large portion of his workload – and seemingly successfully:

His code was clean, well written, and submitted in a timely fashion. Quarter after quarter, his performance review noted him as the best developer in the building.

The Verizon blog post doesn’t say what happened to the employee in question – most likely, he was fired – but it’s exactly this kind of arbitrage which should be encouraged in today’s workplaces. Maintaining productivity while increasing employee satisfaction and remuneration – isn’t that the dream of every company’s leadership?

Update: The Register reports that the employee is no longer at the company in question.