Talent vs Hard Work

I recently read an article by Chris Brecheen, I follow his page on Facebook and his post about dungeons and dragons caught my attention on a slow Sunday morning.

In it, he discusses a D&D player with an unbeatable magic sword who saunters up to a dragon and, through lack of preparation, is reduced to a pile of ash. Meanwhile the team who have battled against ogres, orcs, and trolls for the last three years eventually manage to bring down the monster after several hours of hard fighting.

The message was that having “talent” in something (or at least believing you do), makes you overconfidence, brittle, and actually limits what you can achieve.

In his book The Art of Learning Josh Waitzkin discusses how children are given positive reinforcement in one of two ways. Either they are told that they’re really good at something, maths for example, or they are told that they worked really hard.

The difference comes, Josh explains, when they meet a challenge they can’t overcome. The kid who is told that they’re good at maths immediately assumes when they face a question they cannot answer that they are not good enough. The child raised to believe that they succeeded because they work hard has a different outlook, they believe that they’re stuck because they’ve not worked hard enough. One child will continue to work the problem, the other will assume it is beyond them.

Believe it or not I’ve seen the same thing in developers, some with fifteen or more years of experience. When a developer is faced with a bug they cannot solve, either they assume they are not smart enough (or, far more often, that they have not been provided enough/correct information), or they simply shrug and say they’ve not found the problem… yet!

This behaviour, in my mind is one of the key differentiators between a good developer, and a great one. The outstanding developers on the team will continue to look at a problem without frustration, continually attacking it from different angles until they reach the next breakthrough. Even if that victory is only one small step to resolving it.

So what can we do to encourage this kind of behaviour in our teams? Try thanking people for their effort, rather than their smarts. Understand that real success comes from hard work, not from a bolt of inspiration.

Also, one more thing before I put aside my soap box. If we want to continue to grow then throw aside any delusions of being where you are by being the smart one, you got there through work – just like everyone else. You didn’t inherit a magical sword or extraordinary talent. So make sure you’re not relying on it the next time you meet a particularly scary dragon!

Why is Safety So Important?

I wrote recently about safety and how I’d describe it, I gave an example of a developer who suspected that a particular approach chosen by the team wouldn’t work but didn’t feel confident enough to speak out and challenge the design.

In this post I want to discuss just how serious that lack of safety is. Beyond that lack of a warning a lack of safety can lead to bugs, disengagement, and even resignations.

If you’ve not already read it then I suggest picking up a copy of 5 Dysfunctions of a Team but Patrick Lencioni. It really is very good!

To back up my statement over resignations I want you to think of the last time you disagreed with your spouse, friend, or family member folder what to do one evening or weekend. Maybe they wanted to go shopping or redecorate a room. I want you to think about how you felt doing that activity and question whether you really gave it 100%

Not really being engaged is hardly unsurprising. Let’s say you wanted to see one film but you were talked into seeing something different. Are you really going to admit that you enjoyed it or will you secretly (it not so secretly) believe that your choice would have been better?

The point of this simple example is that humans struggle to commit to an idea while they still believe that their option would have been better. When we have joint design discussions if someone has an idea and doesn’t voice it or has concerns but gets shot down then they will never feel like their voice has been heard. They become disengaged from the end result, because they never wanted to do it that way anyway. It’s not malicious, it’s a defence mechanism because don’t want to admit that out way wasn’t better.

Only be encouraging all team members to openly discuss their ideas so we gain not just consensus, but buy in. As for staff retention, if your team member never feels bought into the work because they don’t feel like their view is listened to, how long do you think they will remain in that team?

Agile Development with Lego Star Wars

Recently I was lucky enough to attend a workshop run by IndigoBlue as part of the Leeds Digital Festival.

Our objective was to build a Death Star for the Emperor. The Dark Lord of the Sith had kindly refined the construction of his battle station into user stories and the two different teams had to build various sections ready to be deployed into production.

It was only at the end of the first sprint, after my team had constructed a very impressive throne room and firing dish that we realised that none of us had asked how we were supposed to deploy into production.

The Emperor it turns out had an operations team and was very particular about production access. We couldn’t just drop sections of the space station anywhere, there were rules, and if we didn’t talk to the operations guys, the other team, and on occasion the emperor himself there was little chance we’d succeed. I don’t want to share all the rules as IndigoBlue had clearly put a huge amount of time and effort into developing them, if you want to know more I’d highly recommend you to get in touch!

After three sprints I’m glad to say we started to get the hang of things and our Death Star reaches its MVP.

The Emperor was delighted that his Death Star had a trench surrounding it…

A board room for holding important meetings.

And a shuttle bay.

Not to mention all the other bits I didn’t get a great photo of!

Overall it was a brilliant evening, a great game to remind ourselves of some the basic Agile and DevOps concepts, and I had a lot of fun. If you see another of these events advertised I’d highly recommend it!

What Exactly is Safety?

When I first heard about someone taking about safety in the workplace I assumed that it was part of an anti-bullying campaign, a Health and Safety initiative, or perhaps some huggy feely thing from someone in HR. It took a little while for me to realise that not only is safety everyone’s responsibility, it is perhaps the most important component of an effective team.

To try to illustrate what safety is I’m going to give you a fictional scenario.

I dropped in on the last few minutes of the team’s planning session. As their manager I’m not strictly required to attend but I like to join occasion to keep up to date with what they are working on.

One of the developers was up at the whiteboard, pen in hand, and he was gesturing enthusiastically at his design. The rest of the team nodded, some eagerly, others showing the fatigue so typical towards the end of a long meeting.

Seeing that the group were wrapping up I caught the eye of one of our senior developers. We had a 1:1 scheduled and I wanted to get started quickly so I wasn’t late for my next meeting.

A few minutes later, coffee in hand, he had just finished telling me about the new data access module he’d created for one of our legacy products. After giving him the appropriate thanks I shifted the conversation onto the upcoming work.

“So it sounds like planning went well?” I asked.

He shifted awkwardly in his chair, obviously not enamoured with the change in topic. “Yeah… but I’m really not sure it’s going to work.” He muttered “I tried something similar a few years back and it just got way to complicated too quickly, the code became unmanageable and we had to abandon the whole thing.”

My blood ran cold. There was a lot riding on the next piece of work. Deadlines, client expectations, the team’s reputation. Forcing calm into my voice into my voice I asked the most obvious question.

“Did you mention this in the meeting?”

“No…” he said “I didn’t think they’d listen to me…”

I’ve deliberately tried not to give extreme an example here. It’s all to easy to discuss nuclear reactors or operating theatres when taking about safety but that implies that the requirement to feel safe only matters in life or death situations. That’s not the case. The more confidence people have the better our teams will function at all times.

So, let’s talk about the problem here. The team has decided on a particular design for a piece of work. One of the developers believe that the solution is doomed to failure and has failed to share that concern. It’s very easy to blame the developer here, or the guy holding the pen for not listening, but in truth it’s everyone’s responsibility to make sure that people feel they can contribute important, and often unwelcome views without fear of reprisal.

But where does this fear come from?

Unfortunately it’s hard coded into our DNA. Based in the same rational as our irrational terror of public speaking the fear of speaking out and voicing unpopular views is grounded in our history as a tribal species. Millennia ago, if a member of the tribe appeared weak, either because their view had been successfully challenged or if they’d lost such a confrontation then they risked being ostracised from caveman society. We are programmed with a strong herding instinct not to challenge dominance or listen to viewpoints which may make us appear weak or incorrect. Unfortunately in the modern workplace these fears put projects at risk of failure.

Team members feeling safe enough to voice their ideas is crucial if you want your team to reach its highest potential. We need to build teams where everyone, not just those with fancy job titles or big egos feels safe to voice their opinions.

I plan to write more about safety over the next few weeks, however if you’re interested in learning more I highly recommend Leaders Eat Last by Simon Sinek and Crucial Conversations by Kerry Patterson.

The Three Ways of DevOps

If you’ve ever read The Phoenix Project (or pretty much any other DevOps book) then you’ll most have heard about the three ways.

The first time I heard the name I imagined some deep levels of understanding that the DevOps Sensai was imparting mystical knowledge to young grasshopper. I still like the mental image but having read a little deeper I believe they are three steps to building a successful collaborative team.

Let’s look at the three ways.

The First Way – Systems Thinking

The idea of the first way is to appreciate that each series of tasks is interconnected into a complex system. Recently I described how a delay at one stage in the system knocks on to each subsequent task, having a good understanding of the overall system allows you to identify where your bottlenecks are, exploit them and avoid work queuing up in front of any individual person or process.

The Second Way – Amplifying Feedback

The second way is all about looking at what happens at the end of the system and using that knowledge to improve the process. If a particular result is of a poor quality then the team need to know so they can focus more effort in the testing phases. Equally if a release is of a particularly high quality or gets good customer feedback then the team need to know that what they are doing works!

The Third Way – Experimentation

The third way is about constant experimentation and improvement. The team is willing to take risks (because they know their feedback loops are good and they will find out about any issues quickly). These teams adapt to changes quickly and are not afraid to challenge processes just because “that’s the way we’ve always done it”.
I believe that the fact these ‘ways’ are numbered is in fact very important. Without an appreciation of the end to end system it’s impossible to develop strong feedback, after all where does the system end and where should your feedback be coming from!? Equally, without this strong feedback experimentation is extremely dangerous – you may in fact be making things worse!

I also believe that these concepts can be introduced to a scrum team to lift them to the next level. By introducing ideas such as systems thinking and feedback (already a strong Agile theme) you’re asking the question of what in fact is the definition of done? DevOps encourages collaboration across Development and Operations, if a scrum team includes both roles then it’s logical that work is only “Done” when it is running properly in a customer’s environment. That surely, is the ultimate goal of any software development team?

Have you come across the The Ways? What are your thoughts? Can you use them in a scrum team?

But I’m Not In Customer Service…

I’m going to start with a confession before hopping on my soap box. I was recently copied in on a couple of emails going back and forth with a customer. I wasn’t overwhelmed by our responses, in fact there were quite a few things I would have changed, the information was accurate but it wasn’t conveyed particularly well. I was about to get involved when I had the thought “But I’m not in customer service…”

All I can say is that I’m extremely glad I didn’t say those words out loud, as soon as my internal monologue had paused for breath I realised just how little sense it was making. We are ALL in the business of customer service!

In most corporations we’re split into various teams, often with complimentary skills. We are then given goals and objectives to complete. The majority of my time is spent supporting my team and working with upcoming releases. On a day to day basis I don’t speak to our customers that frequently (unless we’re collaborating on a new feature or UAT obviously).

Does that mean I’m not in the business of customer service?

Does that mean that I don’t need to consider the customer?

Absolutely not!

Aside from the fact that it’s our customers who pay my salary as a developer the entire goal of my working day is to provide a high quality product to our customers. There are many parts of that, a good design, a high quality implementation, but also the marketing and support we provide to our customers.

If you were searching the app store and you found two equivalent 99p applications one with beautiful screenshots and another with bad grammar, typos, and a vague feature list which would you invest your money in?

If you were making the decision for a multi-million pound software investment would you rather work with the team who fob off your questions or the one one who can provide high quality answers?

Now, I’m not saying that we all need to move into marketing and join the OU’s customer service courses. But I do believe that we all need to remember that the reason our business is operating is because we have customers – providing a good service to them is in ALL of our remits from the developers to the accountants and everyone in between. Build your features with the customers’ frame of mind, write your email with the phrasing you’d like to receive and let’s not any of us mutter the phrase “but I’m not in customer service!”