Facebook spent $20m building a platform to breach your trust. Actual cost: $60 billion.

facebook-3249888_320Today’s raid of Cambridge Analytica’s offices followed revelations that the company had been involved in harvesting data from 50 million Facebook users and then using that information to influence the USA’s 2016 presidential election.

After their stock lost $60 billion in value, Facebook apologised for the “breach of trust” and promised to do better in future.

However, Mark Zuckerberg’s potted timeline of related events leading up to the incident makes it clear that the Facebook Platform, released in 2007, was operating as intended.  It was specifically designed to “enable people to … share information about [their friends]”.

In addition, Paul Gewal, VP & Deputy General Counsel for Facebook made it clear that this was not a data breach and that all data had been obtained from users “knowingly”.

So why is Facebook facing a backlash from their investors and users, if the system operated as expected and was not compromised?

The answer is that Facebook built a system without considering the ethical implications of its functionality.  The system presented a request for authorisation which its authors knew users wouldn’t read or understand and it then shared private information about other users without their knowledge.

We have names for those who exploit human weakness for their own gain – a shyster, a con artist, a fraud.  We also have names for those who share private information about their friends – a gossip, a grass, a rat – a traitor.

Digital systems are now such an integral part of so many human activities that it becomes imperative that we view their operations, both intended and unintended, in these terms.  Digital ethics should now be a fundamental consideration for all organisations building or implementing digital systems with the power to influence the lives of their users and their staff.

Instead for Facebook, their early focus was on gathering as much as data from their users as possible and then building ways monetize and share that data as widely as possible.

Facebook’s early motto was “Move fast and break stuff”

When they went to IPO, Zuckerberg announced the 5 core company values, none of which referenced treating users or their data ethically:

  • Focus on Impact – “work on the biggest problems”
  • Move Fast – “prioritise grasping opportunities over avoiding mistakes”
  • Be Bold – “take big risks, don’t be afraid to fail”
  • Be Open – “share as much information as possible as widely as possible”
  • Build Social Value – “give users the opportunity to express themselves online”

It is these values, bereft of ethical consideration for the end user which spawned the digital attention crisis and this month resulted in betraying the trust of millions of users.

Taking a conservative estimate that 50% of the funds raised by Facebook through to 2007 were invested in product development, Facebook spent around $20m to build the Facebook Platform.

Not building in digital ethics cost them $60 billion.

[All opinions are my own and do not represent those of my employer.]


The Zone: Banned for life

As a developer, you need long, undisturbed periods of time in order to concentrate on the problem at hand. Your best, most productive time is when you are in ‘the zone’.

Any developer worth their salt has experienced this state, where the outside world disappears, you’re holding 20 variables in your head at once and are being incredibly productive. A lot of job satisfaction is generated from this place; I personally equate it with the creative satisfaction that artists experience. It’s powerful stuff.

The bad news: To introduce even minor managerial responsibility – say a team lead role – into your job description, is to receive a lifetime ban from ‘the zone’. Once you become a hub for communication and decision-making, your chances of getting enough unbroken time to get into that effective, productive state are effectively zero. You are likely to be regularly frustrated at the constant interruptions of your colleagues.

The fix: I’m afraid the only effective solution I’ve seen to attempting to split your time between coding and managing is to give up on one or the other. If you’re attached to the management element of your role, you should seek to also ramp up other non-coding activities that can be completed in shorter bursts.

Design, documentation, code reviews, coaching and client interaction all fall into this category. If you’re attached to your coding, don’t be afraid to say as much and just pass up the whole management thing altogether.

Maker’s schedule vs manager’s schedule: http://paulgraham.com/makersschedule.html


Decisions: Striving for average

When I wrote about how moving from a technical role to a management one is going to suck, I highlighted what I believe is the key reason: it involves a fundamental, religious shift in your personal values and motivation. One example of this is that as software developers, we strive constantly towards a commonly defined and accepted ‘best’ possible solution. In management, there is no such thing.

When I was new into management, I invested a lot of time trying to ensure I was doing the best I could by every single one of my employees because I believed that was my new objective measure of success. At the time, someone passed on the sage piece of wisdom that “if everyone loves a decision you’ve made, you’ve made a mistake”.

During those early years, one of the things I implemented was an employee awards program. I’d read some of the literature around the hazards of replacing intrinsic rewards with extrinsic ones, so my system required that people were nominated only by their peers (rather than management) and there was no monetary prize, just kind words read out at the monthly town hall meeting in recognition of good work.

I remember very clearly my horror when, shortly after the first of these awards, an employee (we’ll call him Jim) requested to speak to me, so he could complain about this new recognition system. In my mind, this was a wholesome, uncontroversial way to give team members a pat on the back. What on earth could Jim be upset about?

In the meeting, Jim pointed out that he had worked alongside one of the people who had been recognised under the new program. The recognition had been for hard work and commitment to reach a critical project milestone. Jim made the point that he had done the same sort of work, on the same project, under the same conditions, but that he had worked an extra few hours in the final week, because his area was one of the last to go through testing and bugfixing. Jim was upset that someone else had been recognised and by implication, he had been excluded.

The bad news: No matter how universally loved you imagine your decision will be, there will always be someone who hates it and thinks you are an idiot for even entertaining it for a moment. Lavish your team with new aeron chairs, free drinks and massages? Well, unless you’re Google, your financial controller is going to come asking questions in very short order.

Flexible work hours for night-owl developers? Project managers will arrive with their new project plans indicating that the impact on the analysts, customer reps and the test team means a revised delivery date of shortly after man has walked on Mars.

The fix: Strive for average. Seriously. You are there to make decisions between competing interests – that’s your job! – and it will almost never be the best option to take one extreme or the other.

You need to be able to weigh the information you have to hand objectively and look for the decision which delivers the best balance of outcomes. In my experience, good decisions are greeted with a shrug of acknowledgement and never spoken of again. If you are cheered and carried off on the shoulders of your audience, the question should arise in your head – what price has to be paid for today’s inebriating adulation?

Sober questions about risk analysis, commercial exposure and fiscal responsibility may face you tomorrow.