Category Archives: Leadership

Mindfulness for Senior Executives – a commentary

The management magazine strategy+business have just published a short video on this topic with Havard Psychology Professor Ellen Langer

Having watched it, I think that some of what she says is correct and has real value. The real benefit of meditation in this regard is the clarity and focus that comes after it rather than the act of meditation. That everybody benefits from being more in the moment rather than coasting through life on autopilot. That the act of mindfulness increases attention and focus and leads to better interactions and results in many cases (from a personal point of view at work it’s one of the things I ask for in meetings, even if it’s just by putting away laptops and phones). All good stuff.

But I really hope that some unfortunate editing cut out some deeper explanations of her comments as there are some glaring mistakes that make me wonder how much time Professor Langer spends in the business world.

Her statement that you should always be mindful does not take into account the mental and emotional cost of “always being on”. If you’ve ever have the chance to see a capable C-level executive at a major function you will notice how exhausting it is being in the moment to every person they speak to. It’s very much like an actor being on stage except the spotlight is always on you. Typical strategies I’ve seen used by CXO’s are to either make their involvement very short and controlled or to have a small support group that they dip in and out with when they need to get re-energised. We need to be aware that mental resources are not an inexhaustible resource and one that we need to husband throughout the day. Prof Langer does mention that “you cannot be actively thinking about everything” but I read that as referring to the depth of your mindfulness not to the duration.

-note to self, I regard the work day as neither a sprint nor a marathon but a series of sprints. One of the tricks of using mindfulness comes from recognising when one needs to be sprinting and fully engaged and when one can back off the accelerator, defocus slightly and recoup energy.

Late in the video, her assertion “there’s no more information than there ever was” is either blindly simplistic or just plain wrong. The rise of the machines has meant that we have a far greater insight into the workings of our business as thing’s a easier to measure and monitor. Barely a day goes by without someone proposing a new metric and it becomes a critical task of a leader to decide which metrics need to be paid attention to and which should either be ignored, killed off or delegated to someone else. The only way that her statement could be true is if you redefined information to its most abstract platonic ideal. Yes, the information has always existed in-potentia but now we have direct access to a firehose of real actual information, far more than we had before.

And how about her sign-off for a weapons-grade “thought leader” bullshit aphorism.

Rather than spending so much time worrying about making the right decision, I think we should spend more time making the decision right“.

I know that we play a game with soundbites, the media love them for their ability to make easy headlines from them and we the viewer love them for their ability to distil a proposal down to its essence. Unfortunately, what Professor Langer has said is a Deepity of epic proportions. It’s  trivially obvious in that of course we want to make the right decisions (duh!) but it’s totally false to infer that we don’t make correct decisions without sufficient worrying about both how we make them and the data that we are basing our decision on. Even if we are generous and focus on the use of “so much time worrying”, then it is still wrong – the only way we can test that a decision is correct before we make it is by running it though thought experiments to see what the consequences of that decision are. The greater number and varieties of these virtual scenarios then the greater confidence we will that it is correct and it follows that the more examined decisions will likely be the better ones.

I’m actually a strong advocate for mindfulness, especially in the workplace, but these sort of vapid statements do not help people understand mindfulness nor implement the sort of changes that can have a positive impact.

 

 

 

Inform, Educate and Entertain

For all the reams of advice written on how to “do” social media successfully, I’ve read nothing that beats Lord Reith‘s description of what the BBC was created to do

“Inform, Educate and Entertain”

Okay, so you might not be running one of the world’s greatest broadcasting networks but if you want to engage an audience, any audience, follow this maxim and you won’t go far wrong.

Why your engineering department needs a tech blog

If you know me it’s no secret that over the last few months I’ve been looking for a new challenge (stay tuned for more on that later!). While I was doing this I was struck by just how many organisations still don’t have blogs written by their technical department.

At a time where social media is EVERYWHERE this seems almost perverse. With the dependence on the web and mobile almost every company is now an internet company to some degree. An airline is in the business of moving people around in flying boxes but they have an enormous technical infrastructure. Banks are in a similar position and so are pretty much every company that sells something. Okay, not everyone is going to have a large development organisation but almost nobody has zero and because of this all companies will suffer similar issues around:

  • How do you attract quality technical staff?
  • How do you communicate complex technical issues that have a fundamental impact on the business with a wider audience of laypeople?
  • How to inspire and fulfil technical staff?

These are notorious hard problems to solve. High quality tech staff are far more productive than average tech staff and you only want to hire the best. Technologists are notoriously bad at communicating their domain to non-technical people, both internally and externally, and also tend to be driven by different motivations.

So why does having a technical blog help?

  • It’s free advertising for recruiting technical staff
  • Transparency drives quality both in the product and in the engineering culture
  • You are upskilling your technical staff for very little cost and can produce content for talks at conferences/whitepapers
  • You are engaging with your community and raising your profile which is turn means free brand marketing

Examples of the companies that do this best are Twitter http://engineering.twitter.com/, Linkedin http://engineering.linkedin.com/blog and Etsy http://codeascraft.etsy.com/category/engineering/.

Admittedly it’s only my experienceand not a rigorous survey but there does seem to be a fairly strong correlation between companies with a good engineering culture, i.e. places I would want to work at, and having a good tech blog. If your technical staff don’t have a voice what are we to think? That you don’t value or trust them or that the standard of your technology division is fairly low and you don’t want to expose just how bad they are? Either way, my interest in working there is going to be non-existent.

It might sound harsh but if you are in a technical leadership position you owe it to your company to have a blog written by your technology staff. I would go as far as to say that every technical person should have “write a blog post” in their yearly objectives.

If your technical department does not have a blog you might as well be announcing to the world that you are second tier and are happy to stay that way.

So are you?

Regarding Quality

“I’ve noticed that them that has it in them to shine will shine through six layers of muck, whereas those who ain’t shiny won’t shine however much you buff them” – Nanny Ogg in Terry Pratchett’s Thief of Time

The traditional engineering organisation structure is dead according to Yammer – why they are right, and why they are wrong

There is a brilliant article here written by Yammer’s VP of Engineering Kris Gale. The article is covers a talk that he did at Hack+Startup on why the traditional engineering organisation structure is dead.

The truth is that in many ways he is absolutely right. The rise of Agile, Lean, DevOps and Continuous Delivery all show that the landscape has moved wildly within the last few years and the structure of engineering organisations needs to adapt to this.

Kris points to a new engineering organisation which follows the following rules:

  • Small teams (2 to 10 people) doing small projects (2 to 10 projects)
  • All projects have a definite end date
  • Team members only assigned to one project at a time
  • Prevent specialisation
  • No code ownership
  • Bug fixing is done by everyone

In his talk that went along with the article, he mentioned that he was deliberately contrarian and wanted to make people think and he’s succeeded and I agree with almost everything he says. Traditional engineering organisations need to follow this approach when it is right. The issue is that it is not always right.
Continue reading

Failing productively

I was in the Facebook offices in London recently. Very cool offices in a very nice location but what one of the things that struck me most was the signage on the walls.

I have to say that I absolutely love this.

It’s one thing to hear this at conferences (which sometimes seem to exist for the express purpose of making us aware of our own incompetence!) or from coworkers who have your back anyway. It’s another thing to have this as fundamental aspect of the culture corporate and just a million miles away from the lip service that so many companies pay to this idea. You know the sort of company, they maybe have a nice motivational picture of an eagle along with a pithy comment about attitude and altitude and think they are being daring. If you are lucky your direct boss embraces the idea that being able to fail is a good thing and if you are really lucky your boss’s boss does too but the whole company? Really?
Continue reading

Psychology for Technical Leaders

When I first moved into a position of leading developers I experienced a fair amount of good natured teasing that I’d do my best programming via Outlook and Omnigraffle. While this has been true (thankfully only to a point!) it has been outweighed by the ability to have a far greater say into the resourcing, architecture and implementation of projects and how my company does its work.

One thing that I’ve become painfully aware of is that the operational aspect of this position has a larger ‘people management’ aspect to it than I had previously thought. This is especially true when you extend your view to include recruitment, appraisals, motivating staff and the like and not just setting up your teams to deliver quality code as fast as they can. The soft skills of leadership tend not to come easily to those with a natural technical focus (describing almost every developer ever) so it only makes sense to take advantage of psychology research in the areas of skills assessment and motivation. These is a wealth of knowledge out there and I thought I would discuss a few of the more interesting/useful ones that I have come across.

Continue reading

Big Data for business: be careful what you ask for

This post on the temptation of data raised an interesting aspect of Big Data: that we run the risk of being overwhelmed by data and that organisations and investors are looking too hard for the one piece of data that will be the key to success. Drowning in data is a real risk to an enterprise and something that great leaders are aware of ( lesson 3 in this awesome leadersip slidedeck from Colin Powell – “Experts often posses more data than judgement”) but being swamped by the data is not the only problem.

Another problem with casting the net of big data wide in this way is that eventually you will end up finding some sort of pattern, any sort of pattern if you keep looking hard enough (there’s an XKCD for this). The human brain is a fantastic pattern recognition system and is easily fooled (see Pareidolia) and it’s far too easy to make mistakes like confusing correlation with causation.
Continue reading

Leadership is not Management!

Apologies if I’m stating the bleeding obvious yet again but my previous article, Developers: you are not the sum of your technical skills, raised a bit of comment on reddit. Not a huge amount of comment since the commentary that programmers cannot be insular is fairly obvious but one point that was raised a few times was the section that dealt with being in charge of a team.

“I really, really hate that this is taken as a given. The idea that every successful, productive programmer will eventually lead a team is just… Frustrating.”

“As to being “put in charge of a team”, leaders tend to emerge whether you christen them with a title or not.”

Now there are two points here. Firstly, I completely agree that much of the industry has a mildly insane view of the career track of a developer and secondly there is a massive difference between leadership and management and should encourage qualities of the former from everyone, not just those put in charge of a team.
Continue reading

Developers – You are not just the sum of your technical skills

I’ve been pondering the fact that when I started out on a career in development, I focussed on the technical side of it almost to the exclusion of all else. This was especially true for me since I was coming from a non CompSci background after spending years sticking electrodes in people’s heads and doing biological research. This made me painfully aware that in an industry like programming, if you don’t know your stuff you are useless to your team and your company. Worse, you run the risk of ending up a Net Negative Producing Programmer and reduce your team’s output to less that it would be if you weren’t there.

Thus the first few years of a my career as a developer were spent focusing entirely on technical matters. I fought hard for the expertise in the areas that I worked in: Java, JavaScript and C, web development, back end services and multi-threading… the list is long and mostly distinguished (EJB’s… blergh!). I wanted to be that go-to guy for all thing technical and do my part in making my team the best in the company. As a contractor, my skills were the yardstick for how I was judged for new roles so of course I was interested in keeping them up to date.

After a relatively short time it became obvious that this wasn’t enough. Being technically adept is the foundation of our job but certainly not the totality. Even before you get your first job you realise the importance of communication. Not just in communicating your skills to get that first job but then once you’ve got it, then communicating with the rest of your team including the non technical members. This is especially true in an Agile world where you have to be able to tell others what is going on in a way that they will understand.
Continue reading