Rejecting the Soft Skills Fairy

Published Updated Meri Conferences, Development, Personal Development, Productivity

A couple of months later, the Dare Conference still swirls into my head at least once per day. Great experiences are like that — they don’t just affect you on the particular day, but for months and years afterwards. Kathy Sierra recently wrote a brilliant piece about how great talks are a user experience (and so the speaker is really just the UI).

Dare Conf was one hell of a user experience.

I still can’t really articulate everything I learnt. Everything I heard. Everything we experienced as a group. Dare felt like early SxSWi. Like you were connecting with people who just got it. Who were simultaneously so different and so like you. Who were taking the time to learn some pretty hard shit, together as colleagues rather than as combatants. Who were deliberately opening themselves up to the scary change, the frightening ideas, the things that might just change the world.

[I appreciate that if you went to much more recent SxSWi you are probably wondering what I’m smoking: read this excellent post by Anil Dash on the web we lost.]

I know I’m doing things differently. Whether it’s realising when my amygdala is hijacking me, remembering to “get in the car” as my friend Neil exhorted, or using Dave Gray’s culture map to illustrate to an organisation why the delta between what they SAY they believe in and what they ACTUALLY believe in is hurting them.

The thing I most want to share with you today about Dare though, is one of the slides from Karen McGrane‘s excellent opening keynote:

Karen was highlighting that in our industry we have (and highly prize) technical skills, but to be really effective we need the others too — we need to be able to work with others (External skills, as she puts it), and we have to have to be able to work with ourselves (Internal skills).

I’ve been managing people for a number of years now. I repeatedly see this play out: someone who is technically brilliant slowly becomes incredibly frustrated that they don’t have the impact they want to have. If they’re lucky, someone helps them to realise that they need to not only be clever and technically brilliant, but they also need to have the soft skills (External) to get other people involved and they need the self-compassion (Internal) to manage their internal frustration at this not being as easy as the stuff they’re already good at.

The only difference between those who managed to develop those skills and those who don’t? Belief in the Soft Skills Fairy.

The Soft Skills Fairy has a wand, and if you were touched with it at birth then you have soft skills. If you weren’t you don’t and can never develop them.

Sounds silly, right? Seriously though, people seem to believe this. The people who believe that anyone can be taught to code, that design skills can be learnt, honed, developed, these same people believe in the Soft Skills fucking Fairy.

The truth is much harder to face: everyone can develop these skills. But it is hard, it takes work, and no one has a magic wand to wave over you to make it happen overnight.

Do yourself a favour: reject the Soft Skills Fairy. Invest in yourself. Make time for learning some of those soft skills in between the technical skills; they are both essential to being awesome at your job. Find people who are good at this stuff and ask them how they learned. Find ways to practise, outside and inside of work. Find people who will tell you the truth about whether you’re getting better and then ask them.

It’ll be hard. It’ll be worth it.

If you want a ready-made safe environment to learn some of these things, come to Dare Conf Mini in January in London. There’s still a £100 discount if you grab an early bird ticket by Monday 18 November. [UPDATE: You can now get a significant discount by using code MERI at checkout too — thanks to the organisers!]

As you’ll see from the line-up, I’m speaking (and running a full day workshop on Practical People Skills) but honestly, I’m hugely excited about what I’ll learn from the other folks speaking and attending. I imagine Dare Mini is going to be another incredible experience and I’ll walk away doing things differently. Better. And I’ll continue to utterly reject the goddamn Soft Skills Fairy.

DevOps in the Wild

Published Updated Meri Development, Operations, Presentations

I spoke today at the Eduserv Symposium 2013, giving an overview of DevOps to the largely public sector audience. I’ve uploaded my slide deck to Slideshare: DevOps in the Wild and they’re also embedded below.

The further reading links I suggested are:

The original DevOpsGuys post about anti-patterns:
http://blog.devopsguys.com/2013/02/20/twelve-devops-anti-patterns/

Niek Bartholomeus’ excellent presentation about introducing devops to a more traditional environment:
https://speakerdeck.com/niekbartho/devops-for-dinosaurs

The DevOps section of GDS’ Digital Service Manual:
https://www.gov.uk/service-manual/operations/devops.html

Anna Kennedy put together a brilliant list of resources after DevOpsDays:
http://annaken.blogspot.co.uk/2013/03/devops-community-resources.html

DevOps Weekly newsletter: http://devopsweekly.com/

You might also be interested in Gene Kim’s The Phoenix Project, a novel about DevOps.

UPDATE: Thanks to Matthew Jones for reminding me that I mentioned DevOpsDays in my talk but forgot to include the link to them: http://devopsdays.org/events/

7 Things I Didn’t Expect About Agile Content Development

Meri Development, Presentations, Project Management

Tonight I spoke at the London Content Strategy Meetup, an excellent group sharing best practice in the content strategy & development arena. I really enjoyed hearing about Age UK’s research & understanding of older people (or “people in later life”) from Rob and then Chris‘ fascinating approach to figuring out a content strategy for building advocacy for mental health de-stigmatisation amongst young people.

I was quite nervous about talking about agile to this audience, particularly since I’ve only really gotten good exposure to content strategy, design and management in my year at GDS. But they were a lovely friendly bunch and I’m really grateful to Sarah Richards & Graham Francis for suggesting me to the organisers.

Essentially I subtitled my talk “a magical mystery tour of Meri being an idiot” and talked through the various lessons I’d learnt about how agile is actually a pretty brilliant approach for content development.

The book I recommend at the end is an absolutely BRILLIANT summary/primer/refresher on Scrum — I heartily recommend you buy at least a copy for yourself and possibly one for everyone you know who needs more agile in their life. You can get it at Amazon or on Kindle (I promise you the Kindle version will be the best 77p you ever spend. Seriously.).

Outsourcing and Test Driven Development

Meri Development, Project Management, Software

I imagine that most of you have aleady heard of Test Driven Development (TDD) where the tests that software should pass are written BEFORE the software itself is written. The list of tests is essentially just a formalised way of listing success criteria (and indeed requirements) very precisely. More than precision, this approach gives you a very fast indication of your REAL progress, since the newly written code either passes or fails the tests*.

Test Driven Development is a software development approach usually associated with agile development methods such as those championed by the Agile Alliance. It is usually assumed that agile development requires a team to be collocated, working intensively and exclusively together, and so little attention has been paid to the role of these methods in outsourced development.

For better or for worse** however, many of us are on one side or the other of an outsourcing arrangement. I discovered in my work that using test driven development as a mechanism for both validation (are we building the right thing?) and verification (is it working?) can be hugely powerful.

There are a number of reasons for this:

  1. Well-written tests can explain requirements much more efficiently than traditional requirements documents. Even when there are misunderstandings, the SUM of the different tests specifies the right functionality.
  2. Tests are technical and so can overcome communication barriers with added precision. Even just not sitting next to your developers (or designers) can cause communication issues. When you add the moder-day reality of offshoring as well as outsourcing, this can be exacerbated.
  3. “The customer” (whoever they might be) can be involved in the creation of the test suite. This helps to ensure that the right functionality is being created in the first place since we can check that what the software does is what the customer desired/expected very easily.
  4. Showing the number of tests passed can be a much better indication of progress than the traditional “percentage of task complete” measure. You know exactly how much of the programme actually works at any given time.
  5. Tests can be automated. Then you essentially end up with an automatic checklist of desired behaviour, so that every time a change is made you can pinpoint other areas of the code that might have been affected and refactor quickly, rather than waiting for bug reports to come in from live use.

Hopefully as agile development methods become better and more widely adopted, an increased number of the firms providing outsourced development services will start to use them as standard. In the meantime, it can make a huge difference to your projects if you manage to introduce them ahead of the curve.

What have your experiences been with test driven development and outsourcing? Share in the comments.

* Provided your tests are well written, that is. Of course, writing good test cases is a skill all of its own!

** The pros and cons of outsourcing your development definitely deserves another post! Or arguably an entire book!