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.

Communication: Nobody will understand a word you say

The stereotype of technical experts being bad at human interaction has been around since … well, about 1980, according to Google’s incredible n-gram viewer:

This idea that very logically-minded, rational, analytical thinkers are bad at relating to their fellow human beings is, of course… well, actually, broadly accurate.

While not everyone is as bad as Sheldon, the reason that character works so well amongst the geek population is that we all recognise a little of ourselves in him. The nuance, accoutrements and niceties of common, “real-world” interaction sometimes seem pointless, baffling or stupid to us.  Human communication is a system for transmission and reception of information which, in terms of fidelity, wouldn’t fare particularly well against two tin cans and a piece of string.

Every time you have to communicate with a fellow human being in your time as a software developer, there is a standard which serves to strip away subjectivity, reduce the signal to noise ratio and improve the consistency and quality of the shared understanding of that information. UML, use cases, flow charts, DFDs, ER diagrams – even code itself. These are the standard tools of trade for a developer and we like the certainty they provide.

The bad news: None of those tools exist in management. The effectiveness of your communication as a manager will be not be judged by any sort of objective standard.

“Right” and “wrong” become entirely subjective concepts. Not so long ago, at a company function, I was chatting with some of my closer colleagues – people who share a similar set of views, tolerances and ideologies. People who will be friends even if I leave the company.

One of them was talking himself up long and loud, as he often does. At one point in his monologue of self-adulation, I made the comment “You’re sort of like Jesus, really, only with less crucifixion.” I was joking of course and just doing my best to keep his ego somewhat in check.

The next morning, I had an email in my inbox from someone who had been standing nearby – not in the group, but just within earshot. He had taken offence to my mention of Jesus and the implied blasphemy against the holy word of his religion. He chastised my misunderstanding of the importance of the story of the crucifixion and offered to set me right.  I politely declined, with a very carefully worded email, offering apologies for any unintended offence.

Obviously I had no intention to offend with my comment, but simply by overhearing what I’d said, I’d managed to offend someone. In the world of management, this issue arises constantly.  The intent of the message behind what you say and the perception of the message by those who hear it may be poles apart, depending on a huge range of personal context factors. In this case, the issue was resolved between the two parties involved, but I have seen similar situations escalate to HR remediation and beyond, into the realm of legal action.

The fix: You know how you’ve been making fun all your life of ‘management-speak’? How managers hedge their words and don’t just come out and say what they mean? You’re going to need to do that. An understanding of language is going to be critical to how you are perceived.  Forwarding around “inappropriate” jokes or images just went from being a cheeky way to build camaraderie with your colleagues to a risky, potentially career-ending move.

You’ll need to build a variety of communication styles which you can employ, depending on the situation. When you’re speaking to large groups, you have to be most careful. Emails, read twice before sending – they are a permanent, archived and therefore retrievable record. You can drop your formality among close colleagues, but as my experience shows, even then you need to be careful who is standing nearby.

Feedback loops: Error 504, forever

One of the key elements of an efficient working environment for a developer is feedback loops which are as short as possible. When I was writing code daily, I invested what I thought was a fanatical amount of time and effort in reducing the overhead of every dev-related cycle.

Checking out, writing code, compiling, stepping through, altering code, spinning up remote resources, rebooting web servers, restoring test databases, checking in – everything was automated and stripped down to the shortest possible cycle time.

Then I started working with some other very senior developers – and really learned the meaning of fanatical. Macros, keyboard mappings, shelling out to scripts… they took the art to a whole new level. Seeking out short feedback loops is instinctive for developers. It is fundamental to our productivity and helps keep us in the zone.

You can often distinguish a good developer from an average one, by what they do when they encounter long feedback loops. Average developers climb on chairs and start sword-fighting. Good ones are working on the build script, so they don’t have to wait so long next time. They are fundamentally motivated by the results of that loop and it is simply instinctive to reduce the time it takes for those results to be returned, in any way possible.

The bad news: Nothing you do in management will have a short feedback loop – at least not in terms of time frames you are used to. Development loops range from sub-second up to minutes at the very most. For management decision-making, the range runs from hours to never – and it’s almost always never. Because a corollary to long feedback loops in management is that you will also never, ever be sure that a decision you made actually caused the outcome you observed later. Developers drink directly from the bottle of job satisfaction when it comes to identifying, working on and fixing problems. Managers are left sucking the dregs out of the carpet. A week later.

The fix: You quite simply have to let go of this one. You need to focus on acting through others and thinking in the long term. If you find yourself thinking “it would just be quicker to do it myself”, stop. It may be quicker this time, but what about next time? And the time after that? Working through others means you have to build knowledge, skills and understanding in your team, even if it pains you to watch it first time around.

Perversely, you also need to drop your standards. Your team will have a variety of skill levels within it and sometimes the junior dev won’t write code to the standard you would have yourself. Participate in code reviews, provide feedback and concentrate on the team, rather than the task.