A Few Notes on Leadership

I was recently asked to talk to one of our teams as part of a series they're doing on leadership, taking a selection of different execs from across the business and getting their take on what it is really all about.  Leadership is a topic which resists a definition that is both concise and comprehensive, so I usually prefer to pick out a small selection of what it encompasses and deep dive on those.  Here's what I picked out for them:

Prevent entropy.  Entropy is universal and for anything to progress (or even continue to exist) we need to continually add energy to that thing.  Groups, projects, initiatives, morale, culture, all these things lose momentum when someone isn't adding energy to them, and it is a primary responsibility of leadership to be the dynamo at the center of the important things.

Configure the environment.  Make it OK to do great things, take the friction out of forward progress, teach autonomy, and empower people without making them feel abandoned.  It is a primary responsibility of leadership to establish an environment which encourages talent and quality and is hostile to impediment and waste.

Expand minds.  Not just add new knowledge but also help people to change their mental models of the world around them; to think differently and be able to conceptualize new ideas.  Experimentation, reasoning and analytical skills, and critical thinking are force multipliers for technologists.  It is a primary responsibility of leadership to change what people are capable of, to make their organizations about more than just turning the handle the same way.

Set purpose.  Everyone needs a purpose, and I mean a higher purpose, which transcends job description.  The reason you're really here gives you the confidence to make better decisions.  For example my guys aren't just here to write some code, or hack away at the Linux kernel, they're here to change the way people build web travel apps.  The better you get at describing what that means and why it matters for customers the more independent and powerful your team can become.  It is a primary responsibility of leadership to favor being highly descriptive over of being highly prescriptive, because it creates the space for teams to contribute at another whole level, not just follow orders, yet still be totally on strategy.

Hire up.  Any great human endeavor is bigger than all of us and can only be accomplished by valuing a smart, talented team over valuing being the smartest, most talented person in the org.  It is a primary responsibility of leadership to constantly raise the bar and bring in people than make you look dumb.

But the most significantly thing I think (hope!) this team learned from their research is that leadership is bigger than any one leader.  By now they will have heard a variety of different views from the cross-section of leaders they invited to talk to them.  Humans like to be able to rationalize complex things down into a single answer, or at least a small set of non-conflicting statements, and in a way I hope that they haven't been able to do that here.

The message here is that a large organization is more like an ecology than an individual organism, and therefore needs a healthy dose of heterogeneity to thrive.  As a leadership team we're capable of things that we individually could not be because we leverage that diversity; the different style and substance we each bring intersects enough for cohesion and extends enough to afford us a synoptic view.

The secret of managing software projects

As a technology manager there is almost unlimited discourse you can read about how to successfully manage delivery and control projects.  The real secret here is you don't manage projects, you manage the circumstances around a project...

This assumes that you have a team of talented engineers, a project manager as strong of character as he is on process, and an architecturally sound plan with some slack in your estimates.  If you don't already have this then don't worry, you're not about to fail, you've already failed.  What you're about to experience is you doing your best to mitigate the consequences of poor leadership.  Good luck with that.

But let's just say that you've got the structure right - now what?  If that's true, then the best contribution you can make as a leader is managing the environment around the project.  Provide a vision and simple insight into what moves the dial for the business and then move the obstacles, keep the distractions away, make sure the priorities don't change, and protect the productivity of the team members.  Keep the project fed and watered; get it the budget and skillsets it needs, get it the right visibility and attention from external teams who may be dependencies.  You're usually on the hook for the whole thing, so the temptation to dive into the details is often overwhelming.  Do it if you must but know that you probably aren't helping.  Your guys won't feel trusted and you won't be encouraging them to take ownership of their own space.  If you have a good plan on a sensible horizon, don't fiddle with it.  Every time you do you increase the chances of things not working out.

That doesn't mean you should be disinterested or uninvolved - quite the opposite.  Be there 100% for every engineer every day and give them everything they need to give you what you need.  Be easily accessible and take on any potential problem, consequence-free, that your team feels like raising.  They don't want to waste your time any more than you want to waste theirs, so if they come to you with something, it will usually be because there is a genuine risk that you're not going to get what you planned and there is something you can do to put things back on track.

I love technology.  We all do.  That's why we got into this business.  I love what my guys do, and I love to talk to them about it, but I am always aware of when prudent interest in the organization's deliverables crosses the line and becomes micromanagement and interference.

The most important thing you can give to any project is certainty.  Make a good plan based around people better than you are and then defend them.

Great Quote and Greater Source

This article has a great take on developer-husbandry, and I particularly like the last paragraph:

"I’ve gone back and forth on whether managers should code and my opinion is: don’t stop coding. Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer. Over time it means you’ll have a harder time talking to engineers because you’ll forget how they think and how they become bored."

Even better is who sent it over to me - one of my commercial stakeholders.  Being in a tech savvy business makes my job a lot easier in a million little ways.

Mechanical Sympathy

In the world of motorsports ‘mechanical sympathy’ is the measure of a driver’s impact on their vehicle. As well as fuel economy it is probably well understood by most people that your driving habits do have some impact on how long your car is likely to last, how often it needs attention, and how quickly the parts will wear out. The world of professional drivers is no different, except that excess punishment of the car can mean that vital few more seconds spent in the pit lane – which can cost a racing team a lot more than just this year’s annual service coming up sooner.

Mechanical sympathy attempts to quantify that impact and allows teams to acknowledge it and work on balancing car wear against squeezing that last little bit extra out of it.

I did a motorsports driving course a while back (number of formula 1 events participated in since training: 0 – number of speeding tickets around town since training: 1) and was mercilessly rated in this category. I guess that explains the frequency of servicing that my long-suffering saloon seems to require…

As an outsider to the world of motorsport the importance of certain metrics is immediately obvious – lap times or time spent under power etc – but why measure drivers on something mechanical? These guys don’t fix their own engines, swap out their own gearboxes, or tune their own brakes; that’s someone else in the team. But, as drivers, they do have a direct impact on how often this needs done, how severe it’s going to be, and how expensive it will be to do – and that has a direct impact on winning and losing.

So why don’t we measure the non-IT people in our businesses on their impact on technology? I’d like to introduce the concept of technical sympathy.

I think that people in our businesses should have at least a small part of their KPIs relate to technology. We’re not expecting them to be developers or sysadmins – in the same way that drivers aren’t expected to be mechanics – but we have to acknowledge that they do have an impact on this stuff (probably more than they realise).

Good stakeholdership can make the difference between a well-run project hitting time and budget and a chaotic piece of work drifting on endlessly. Considerate use of systems can avoid the need for expensive environmental controls and the wasting of shared resources such as disks and tapes. The costs and turnaround times of support can be dramatically different with more personal responsibility and better use of self-service at the desktop.

In almost every company I have worked in we’ve measured engineers on business knowledge and company performance to some degree, yet we never seem to have thought of the reverse even though business behaviours can have a profound effect on the cost and quality of technology.

5 Less Obvious Leadership Qualities

There is so much material out there on leadership and management – the basics of the topic are generally well covered and so I’d like to add some of the less obvious ingredients to the mixture:

1 - Do what needs done, not what you’re familiar with

When under pressure or dealing with unfamiliar situations people will often reach for the tools and techniques that they’re comfortable with – regardless of whether or not those things will have an impact.  We have to avoid falling into this trap and look at what the circumstances and the data are telling us needs to be done.  Those are the actions that will turn a situation around – even if they’re a little foreign and uncomfortable to begin with.

2 – Don’t get swept along with the tide

Change is often hard because most organisations (especially large ones) are great big machines that are good at assimilating new parts and reluctant to part with old habits.  Making a difference can sometimes feel like the only person rowing south on a boat full of people rowing north – it’s hard work and you have to be strong and you have to expect it to take some time.  Organisational culture pop quiz; what’s the street address of Microsoft’s headquarters?  One Microsoft Way.  Is there something there beyond the literal?  Try changing the culture there and then you tell me…

3 - Create the right environment

Put a piece of paper with some questions on it face down on a table and, with no further rules of instructions, ask a group of people to turn over the pages and answer the questions.  They’ll all do it silently and individually and studiously avoid even the slightest peek at each others papers (the honest ones anyway).  Take that same sheet with the same questions and place it face down on the floor in front of chairs arranged in a circle and, again with no further rules or instructions, you’ll find that people will discuss the questions openly and compare answers and debate choices.  I’ve tried this experiment myself and it goes down exactly like that; but why?

It’s because we’re all programmed to behave in certain ways in certain environments and those responses are sometimes so deeply wired in that they’re automatic.  You can fight this all you like but it is just the human condition.  As a leader you are better off acknowledging this universal constant and turning it to your advantage by creating the environment which produces the behaviours you are trying to bring out.

4 – Deal with opportunities first and problems second

Why are humans so naturally drawn to problems and so blind to opportunity?  Perhaps it’s because problems are right here and now and in our faces demanding our attention and opportunities are off in the distance somewhere, shy and subtle and just waiting to for us to make the first move.  It’s easy to get sucked down into the issues of the present – and in any case there are usually a multitude of people already doing this is most companies - but the most successful organisations I know didn’t get where they are today because their teams of execs sat around dealing with day to day issues.  You can’t ignore problems – they won’t just go away – but you have to accept that your big leaps forward will come from your ability to see opportunity rather than fix something broken.

5 – Do what serves the outcome, not what serves yourself

Obvious on the surface however I mean it in a more intimate and everyday way.  Do I get disappointed about stuff?  You bet.  Do I feel mad when some things go wrong?  I’m only human.  The difference between good leadership and average leadership isn’t what happens and how you feel about it, its how you respond to those events.  Would I like to go nuts and shout at a few people from time to time?  You bet.  While that might make me feel better I have to ask myself if it will improve the situation and help the rest of those involved cope – whatever does that is the response I owe the team.

6 - Use role power sparingly

Reliance on role power is lazy management and breeds unengaged, dispassionate, dependent teams.  People always perform better – and add more value beyond the basics of their role – when they are bought into what they’re doing, understand the value and the part they play, and believe in the vision and the goals.  That’s harder work than simply telling people what to do (you have to invest in sharing a vision and collaboratively coming up with plans that the whole team can feel that they own and identify with) but then again we’re here to do what’s effective, not what’s easy.

7 - Make decisions not choices

When faced with options most people can choose between ones they favour more and ones they favour less.  But making a decision is making a choice and then seeing to it being carried it out.  Drucker’s definition of a decision is that a choice has been made and then:

• someone has been made accountable for it’s implementation
• a deadline has been established
• people involved or affected have been communicated with

When making decisions what really matters is that you recognise that your role as an executive is to create the necessary action rather than just pick from a menu.

I said I would share 5 of the less obvious leadership lessons I’ve learned over the years and the more astute reader will note that I have given 7.  Overdelivery – that’s the final lesson!

Finding Talent Part 2

Continuing on from my last post here is the balance of the talk:

Culture is critical to success

Culture is meaningful in 2 ways; it’s the environment that allows high performance people to contribute all they can, and it’s an essential ingredient in attracting them in the first place. Like most things I’ve touched on here, culture is a massive topic all by itself – how do you even define it? The freedom to work to the job and not to the clock, a casual office atmosphere, an appreciation of the value of their innovations, and the ability to try out new tools and processes are just a handful of the things I’d lump into this category, however if you want to distil it right down to it’s elemental for I’ve never heard better than Dan Pink’s:

AMP – Autonomy, Mastery, Purpose

Autonomy is the freedom to choose what to do, based on an overarching understanding of goals and objectives, rather than having work broken down and fed in as proscribed steps. It’s a ‘give me a problem and let me get on with it’ attitude.

Mastery is the desire to get better at something; to develop, improve, and perfect what you do for no other reason than that itself. It’s a strong motivator for high performance people; they constantly want to track progress and do better next time.

Purpose is the need to connect with a greater mission that they find inspiring. Traditionally you could say that companies are formed to extract profits from a market – and that’s always going to be true – but what will inspire high performers is changing the nature of friendship rather than building a social networking site or redefining how education is delivered instead of putting infrastructure in a school; and sure, everyone expects to, and intends to, make some money along the way.

Be available

Most high performance people I’ve worked with value time with their leadership – whether you’re their boss or their bosses boss etc, they want to tell you what they’re doing and they want to know what your thoughts, priorities, and plans are; the longer term the better. It’s how they feed their ‘autonomy’ part of AMP and it’s how you make sure it’s going in the right direction.

Proliferate

In most organizations I’ve worked the truly high performance teams are small pockets of greatness amongst a wider – shall we say more diverse – population. Out of all those places I could tell which ones were headed for success and which ones were headed for mediocrity (regardless of the industry or the product) because in the ones headed for success the wider organization picked up behaviours and practices from the higher performing – and more successful – teams and then everyone lifted their game. In those destined for mediocrity people resisted change regardless of the practical demonstration of it’s benefits being right under their noses. As managers of high performance people we can help this process in a number of ways; we have to recognize that most people (good or bad) don’t like being told they’re doing it wrong or that your guys know better, but what you can do is encourage external interest in what your guys are doing or how they’re doing it and, if one them is interested in spending time with (or moving into) another team, make sure you do everything you can to make space for that to happen. Everyone grows that way.

Know your role

It might seem a little bland or obvious but one thing high performance people will know is what they expect from you, as their manager, and if there is one thing that’s respected it is competence and solid leadership. These kind of guys don’t like working for weak or indecisive management, they take comfort from knowing that you know what you’re doing and you’re doing it like you mean it.

Expectations can be different internationally

This one is particularly true in the IT industry – given how portable our skills are, the way our technical vocabulary overcomes language barriers, and how much offshoring is being done. My experience setting up a develop centre in Romania taught me that, while most of this stuff is usually true, it should be used as a theme rather than a fixed set of rules to use in every circumstance. For example shoulder surfing with one of your developers while they step you through their code could be considered unwelcome micromanagement in one setting but essential interest and support in the other. There is no substitute for taking the time to appreciate what ever individual’s unique needs are. As leaders we’re in the business of making our guys as effective as they can be - whatever their interpretation of that is.

HR still wont help you!

I guess it’s starting to sound like I have a real downer on HR, but I really don’t. I do have a downer on bureaucracy (and even more of a downer on large scale process and paperwork when it doesn’t contribute to the performance of a team or individual) and I have a downer on efficiency at the expense of effectiveness. My point here is simply that no one else but you can or will take ultimate responsibility for the performance of your teams. HR is there to help you, but remember that they’ll never stand there with you and take a beating for things not working out in your team and I don’t know a single executive that would be satisfied with the excuse ‘I applied all the management steps HR specified’…

Set the bar high

It should be difficult to get a job in a high performance team because the rest of the people in the team will have a high standard and will not thank you for lowering the average. High performance people like to work with other high performance people – they’ll always be looking at what they can learn from those around them.

Mix it up

As much as high performance people are always looking at how their peers can help them develop they also enjoy helping others – with the potential but without the knowledge – to develop. For this to work you need to get good at spotting good quality high potential people rather than just those who have all the skills and knowledge right now today. These guys are usually good long term investments too because they’ll soak up knowledge like a sponge and there will be plenty of progression for them in your team as what they’re capable of doing for you expands.

Spend time on the best not the worst

There are a whole lot of nice sound bytes like ‘the squeaky door gets the oil’ etc to justify loading your time towards the people in your team which need the most support, and for some reason human beings are always more drawn towards problems than opportunities, however consider that the opposite bias might be better. How about spending the biggest share of your time with those in your team who will benefit most from it? Don’t allow your weakest performers to be a huge sink for your (highly limited) personal bandwidth and, as some pretty smart guys I know always say, ask yourself how much benefit the organization gets out of 10% more performance from your best performer vs. 10% more performance from your worst performer.

Don’t hoard

Weird point to close on given that this was the ‘retention’ section of the talk, but I think that too many managers focus on retention for retentions sake (which can be especially dangerous when it becomes a KPI). I think the focus has to be on establishing a win-win relationship with smart people which will result in a lot of value for both the organizations mission and the employees personal development and professional growth. Recognizing right from day 1 that this arrangement has a finite lifetime is simply being realistic. I always feel proud and happy when people that work with me move on to something else – in the same organisation or elsewhere - and I take some satisfaction in the knowledge that it’s a step forward for them and that I’ve helped them get there. Besides, I have always found that when people can see how the stuff they’re doing for you links in to the bigger plan they have for their lives they stick around longer because they see how working for you actually contributes to achieving their long term goals rather than preventing them from moving forward.

I originally agreed to do this talk because so many organisations have a very traditional approach to recruitment and management and these approaches are just no longer relevant when you’re dealing with complex technology challenges requiring talented engineers. It’d be a better profession to be in – for both the people on the ground and the companies who benefit from their expertise – if more of us did this stuff differently. You can find the original slides here.

Finding Talent Part 1

Here’s a synopsis of my recent talk on recruiting high performance teams (you can find the slides here) which was made famous at this year’s IT Directors Conference.

The talk breaks down to 3 areas; recruiting, retaining, and running. The emphasis was on recruiting – because it was a talk about finding and hiring talent rather than general management instruction – so I’ll go over recruiting in detail in this post and combine retaining and running in the next:

Keep a bench – you are always recruiting

Any decent manager I know is constantly assessing everyone they meet – socially or professionally – and sorting them into ‘would hire’ and ‘wouldn’t hire’ buckets whether or not they are even currently hiring.  This way they can start to build a relationship and get a real life feel for how the person performs outside of the artificial construct of an interview situation and then they have an extant ‘bench’ of talented people that they know of, and might even have been grooming, when positions come up.  You see roles filled quicker and cheaper with better quality people.

Attracting talent – what YOU say doesn’t matter

One thing that attracts good people is what other good quality people have to say about working at a certain organization – and anything said by another employee or associate of the company automatically has weight and credibility that the official company line doesn’t carry.  People expect YOU to say that your company is a great place to work, and therefore they take your recruitment sites/company spiel with a pinch of salt, but they’ll pay much more attention to what your guys say on social media platforms.  So encourage your team to blog about work and the team and the projects.

HR is not going to help you

Now, let me just say that up front that I’m sure this isn’t always the case, but the fact is that the role HR departments take in modern organisations is changing.  The focus is now much more frequently on compliance (employment law) and health and safety legislation and in putting in place cost reduction measures around recruitment (enter good old efficiency at the expense of effectiveness).  Seldom is an HR department oriented toward courting talent.  That said – if you do have HR guys that are all about the talent then you should hug them dearly and make them feel appreciated.  They’re getting rarer.

Nobody is better than the wrong body

A common mistake in recruitment – especially under deadline pressure - is compromising on the person your looking for.  This can be a tough one to stick to.  In the worst of circumstances you’ll have no-one in a role, a business demanding quick progress (and maybe even viewing vacancies as one of the reasons things aren’t moving quicker), and you’ll have seen literally hundreds of CVs.  But every single time I have taken on the best person I’ve seen so far – rather than holding out until I meet someone I considered to be the right person for the role – I have regretted it.

Salary is only part of the equation

There is no correlation between the best people I have ever had working for me and the people who have been on the highest salaries.  Top talent are much more interested in taking a stake in something they believe in (read: equity), performance linked bonuses, the challenges of the projects, and the culture/working environment.  Salary has to be enough to take pay off the table as an issue but the best people I know don’t chase salaries, they chase challenges.

Crazy about technology - not the industry

It’s easy to fall into the trap of hiring engineers that love the company subject matter over engineers that love engineering.  Mistake.  Your best technologists will understand the commercial forces that drive the business, the market, and the customer in their organisation – and it’s nice to have a passion for the product you’re building – but not at the expense of loving and living the bit you do.  That’s code.  I’m hiring guys who build world class highly scalable data distribution systems, not a football team.

PLU is nice – but I’d rather have talent

People Like Us (that syndrome of only ever recruiting a very narrow band of like-minded people) is a good way to make sure you end up with a group of people who seldom disagree, but no variety – no alternative points of view, no challenges to the status quo, no new ideas – doesn’t make a high performance team.  Lumped into here I’d also underline how important it is to hire people smarter than you are.  Not as clever, or less clever so that you can feel nice and superior, but more clever.  That’s how things get pushed on and it shouldn’t be feared – it should be expected.

Agencies – surrogate networks

The best way to hire anyone is through your network – that is, people who are known quantities and proven performers who have the right personal qualities (which is why I say keep a bench) but eventually you will have to use agencies anyway because everyone goes to them (which I think is because, historically, everyone goes to them).  The secret to dealing with agencies is to remember what you’re doing – buying the value of their network – so don’t accept ones that just keyword-match CVs or phone around on a per-engagement basis.  You want to look at how long they know a candidate for before they put them forward, whether they’ve met them in person, and whether they’ve placed them anywhere before.

Paperwork is an artefact of good people

And finally remember that the goal is to get the right people in place, not to have completed the right forms and followed the right steps.  Don’t establish an overreliance on artefacts - process is important but not at the expense of results; it exists to help you get the right outcomes and is not an outcome in itself.  Not convinced?  Test it yourself this way – imagine you’ve brought on board a series of poor performers who haven’t lived up to expectations.  Your boss is going to be firmly asking you why (if they’re any good that is).  You followed all the right steps and completed all the right forms.  Do you think that absolves you of responsibility for those results?

Obviously this talk is aimed at the engineering end and, even then, only for those of us lucky enough to have tough technical challenges and interesting business problems to solve.  I appreciate that isn’t everyone but I hope there’s something in there for you anyway.  In a few days I’ll post a summary of the retaining and running sections.

What am I going to do today?

Here I go again – with that ‘time’ spiel – anyone who works with me will be switching off about now; but it’s a good spiel and one that I think it isn’t common enough in the corporate consciousness, so now my readers (both of them) get to endure it. It’s really about scarcity, and recognising the resource which we should prize most dearly yet too often let slip through our fingers.

When asked what their most valuable resources is, most people will say money (the odd few might say people – true in another interpretation of the question). Cash is critical to a small business, as it’s often in sort supply, and critical to a large business, because of increased fiduciary responsibility and reporting requirements. But the thing that you can never replace is time and, no matter how big or cash rich an organisation gets, none of it’s individual members ever have any more of it available to them than anyone else anywhere else. It’s fixed. It’s also a unique type of resource to manage – you can’t save it up for a while so that you can spend more later and if you spend it unwisely, you can’t go back for a refund and try again.

Just how scarce is this time thing? Let’s do some quick maths and see how much of it we actually have available to us this year:

1 - Start with 365 days in 2010 (assuming that my time travel project doesn’t get off the ground)
2 - Most of us average out to 5 days per week, so let’s take away 104 leaving us with 261
3 - Most companies give an average of 22 days annual leave every year so now we’re down to 239
4 - On top of this Her Majesty bestows upon us 9 bank holidays in 2010 leaving us with 230
5 - Sick leave isn’t always all used up but let’s assume a worst case of 10 which puts us at 220

Starting off with 365 days makes a year sound like a long time, but we pretty quickly slashed a staggering 40% off that without really trying. And that’s without any contingency for things like sabbaticals, maternity/paternity leave, jury duty, family emergencies... and we can’t make any more of this ‘time’ stuff. It can’t be bought, borrowed, earned, duplicated, or recycled.

Most of us waste much more of this than we readily accept. Ever sat in a long meeting on a tangential topic with a large number of attendees – some of whom aren’t even really engaged (on blackberrys etc)? Ever wonder what the world might be like if those 10 people each got that 2 hours back? In the corporate world I think time is undervalued because it is a hidden cost (outside of professions which explicitly price their time such as legal advice and chartered accountants) and there are often few controls on how one spends their [the organisation’s] time compared to the controls and various levels of signoff on how one spends the organisations money.

Everyone has key projects to do and those projects only get done by people spending time on them. And, as we just worked out, a year sounds like plenty of time to do all this stuff but we usually end up with a fair bit less time on our hands than we started off with.

Getting what we want done means being aware of the priorities and valuing time enough to spend it deliberately – on the things that are most important to the organisation. I used to be surprised about the sort of things that really successful companies dropped on the floor – genuinely good ideas just not getting attention – and then I realised that they hadn’t been missing opportunities; they were just uncompromising about their priorities, staying focused on their most meaningful things, and fiercely guarding against distractions. That’s how they got really successful in the first place.

A different view on Job Satisfaction

If you’ve been here before then you will know that I don’t just regurgitate content here unless I think I can add something significant to it, but I guess every rule has an exception.  One of my guys sent this around a while ago, and again quite recently (OK I get the point), and I think it’s too good not to share:

Jobs are not meant to satisfy us. Jobs are not animate things that have knowledge of who we are, what we are seeking and what our special needs could be. You may say that I am just making a philosophical statement. To the contrary, I believe that it is the most practical and rewarding way of looking at many things in a professional career. When I see scores of successful people around me, I believe that their achievements are largely because of such a perspective. It also occurs to me that developing this perspective is eventually beneficial in every way possible.

Let me go back a century and tell you a story. My grandfather was a medical practitioner in the Bihar of 1920s. He had a brood of children who were orphaned due to his untimely death. Two of my uncles had just about finished high school when he moved on. Their older brothers could not afford to send them to college. The two had to be gainfully employed, somehow, as soon as possible. They were taken to Tata Steel, an hour away from where they lived. Tata Steel and the government of Bihar were the only two employers you could think of in a five-hundred mile radius of my uncles’ hometown. The possible work one could get at Tata Steel was that of a technologist- engineer or of a manual worker. So, what could be done with the two boys with their high school qualifications? They were neither fish nor fowl. “Take them to the lab,’’ someone said. A German technician who ran the place was looking for a few hands. The burly German took a hard look at the two. Then he showed them a broom standing at one corner of the lab and asked them to sweep the floor. By the end of day, one of the two just ran away. To him, it was too much to handle. The one who stayed back retired as a chief supervisor of Tata Steel. The difference between the two? The one that stayed on was not trying to seek ‘job satisfaction’. Instead, he focused on satisfying the job.

The more prosperous the industry, the higher the number of people looking for this elusive thing called ‘job satisfaction’. Similarly, the more qualified some people are, the higher is their need for ‘job satisfaction’. Sometimes, it is as elusive as seeking ‘true love’. There are times when we get lucky deservedly or otherwise. But we also get used to it and conclude that it is the responsibility of the organization to maintain a continuous supply of job satisfaction.
Whenever I think of job satisfaction, I remember all those who have to work at night—policemen, airline pilots, nurses and doctors, ambulance drivers and hotel staff, and of course the sentinel of the snow and the desert and the mountains. Do their jobs ‘satisfy’ these people or do these people satisfy the jobs with which they have been entrusted? Are jobs living things that can ever ‘satisfy’ us?

In the corporate world, like any other place, when we open the bonnet and look under it, we find a whole bunch of tough, dirty but strategic tasks that must get done for the bacon to come home. Sometimes, they are so tough and so dirty that they overshadow the strategic nature of the job. So, all such jobs have to be ‘sold’ to prospective incumbents. More they are sold, less buyers they attract. Often, the man who takes up the job is either a loser who has no other choice, or someone who just views it as a transit camp. For many potentially high-performance individuals, a false sense of survival, desire for glamour or just the need for creature comforts make these jobs undesirable. “I would rather be in Kolkata than be posted to Mungher.’’ “I rather have the corporate planning job than be collecting bad debts.’’ Or, consider this one here: “Give me a cerebral job, I do not enjoy handling transactions. ..’’

Few of us ever ask the boss to be rewarded with a tough and dirty job. We only look for the ‘plum’ ones. Yet, there are people, who given a tough and dirty job, make it strategic: they transform the job in unbelievable ways. In a typical career span, there must be at least four such solid stints in one’s life to make the person a solid professional. All the great people I know have been in the trenches for much of their lives, and their inventory of bruises outnumber the commendations they have received. The occasional commendations stay on the wall. It is the bruises that these people carry with pride.

Subroto Bagchi

That can come across a little old fashioned on a quick read, however I think there is a lot to it when you take the time to internalise it.  When I think about the times that I’ve loved the most in my career, I can see a strong correlation with the times when I’ve been the most focussed on what needs done and making that happen.  Weird how that seems to come back to you in the form of satisfaction…

Entropy

A great note just came through on the Manager Tools mailing list the other day called ‘Everything Decays’ and I liked it because it explains something I’ve recently been wrestling with in my head much more eloquently than I could hope to put it.

Let me reproduce the first 2 paragraphs here so you can see what I mean (can’t find a link to the original work – will post when I do):

“One of the things we've noticed is that managers like having a solution which solves their problem forever. We suspect you've felt this way. In the rare instance you've found the solution you thought would solve the problem forever, you've probably also discovered it's not true. The problem has come back because the situation changes. The people change. The knowledge changes. The need changes.

The fact is, everything decays. For our technical readers, it's just entropy. At work, every problem, every meeting and every relationship is decaying, right now. Now matter how good a meeting is now, in six months, left to its own devices, it won't exist (the ultimate decay) or it will be a lot less effective. The process that you've been working so hard on, and finally got just right, in six months will either be OBE (Overcome By Events) or will need significant rework. You may not have understood, up till now, why good processes that worked before begin not to work. The answer is, the situation, systems or people changed and the process didn't. Entropy. Everything decays. It's not just YOUR stuff that decays, because you're not a good manager. EVERYBODY'S stuff decays. Always.”

The message goes on to talk about how professionals need to continually assess relevancy; keep looking at what they’re doing and making sure it makes sense as circumstances change and the business and the people in it move on.  This resonates on a number of levels including – probably most acutely – the number of managers I still meet who believe there’s some kind of silver bullet out there for their troubles.

What isn’t touched on is the natural entropy you always get in any set of processes or practices even when the environment around them is stable – and the less ‘habitual’ the behaviours are (i.e. cemented through solid and continuous application), the quicker the decay kicks in and old habits creep back in.

tl;dr - there is no substitute for sustained attention and focus, especially during a period of change where some more dedicated coaching can make the difference between lasting change and a blip on the curve.

What kind of idiots are in charge here anyway?

When I coach people about being effective in organizations something that regularly comes up is their ability to influence decisions made at the senior level. Because (with very few exceptions) most people in most organizations are rational and competent professionals with the organizations best interests at heart, any time they feel like their proposals or suggestions aren't being adopted, it can be easy for them to lose a little faith in senior ranks.

I never like hearing that because the truth is (again with very few exceptions) that most executives in most organizations are also rational and competent professionals with the organizations best interests at heart. So why don't your ideas stack up for them?

My advice is usually to look into these two things:

1 - What don't you know that they do - executives will usually have a much broader view of things and can therefore be privy to other information, plans or constraints elsewhere in the organization, that you may not be. Taking into account the things that might be invisible to you, not adopting your recommendations might well be the most beneficial course of action. In my experience, most executives are more than happy to share this information with reports who show an interest in the wider business, so just ask.

2 - What data aren't you being effective at conveying - sometimes the message just isn't getting through and therefore your decision makers don't fully understand what you're proposing and why. It happens to me; I see a lot of proposals for a lot of things (very few ill-conceived) and if the key facts aren't well summarised and the options clear, I am not able to make an effective decision. Again, the solution starts with communication. Ask why, use questioning techniques to check for understanding, find out how your audience wants things presented. I am yet to meet an executive who won't be willing to give that feedback - after all, it helps you both.

Answering these two questions usually gives people the insight they're missing to clear things up and, if it doesn't, then I guess it's always possible that you might be one of those few exceptions...

Things change because people change

Occasionally I get a hard time for spending such a large part of my time with my teams, with the individuals, out on the floor in their work instead of in my office with 'my' work. Occasionally that's also fair - I have a different job than the people who report to me, and the the people who report to them, and that comes with different deliverables.

On the other hand a big part of my job is the performance of my department, the quality of their deliverables, and the continuous improvement of both of these.

New processes, technology changes, new policies, culture and structure are all part of it, but ultimately nothing is ever any different until individuals change their day-to-day actions and behaviours. You will never create lasting change by making rules and proclamations from behind a desk, or just by telling people to 'do better'. Lasting change only comes from sustained leadership focus; coaching and repetition and doing things differently together. When the man on the ground changes then overall results change.

Oh and don't forget my golden rule no. 22867: paperwork is an artifact of effective work - effective work is not an artifact of paperwork.

Let's Ban Agile

Bet that made you look.

Whenever I'm dealing with the wider business and I come across confusion about (or resistance to) agile practices I typically find that, once the few genuine issues are swept up, much of what's left comes down to semantics. And fair enough too - the extensive metadata that has built up around engineering processes is intimidating.

If we put all that aside and just talk about the basic practicalities of doing projects, you are pretty much just looking at an inventory of requirements that must be turned into an inventory of working product. To do that, distinct individuals need to execute specific tasks within certain time constraints (or, more colloquially, who does what by when). From there, we build up some rules to make sure everyone can cooperate effectively around those basics, and it is these rules we'd tend to call our development process/project methodology.

It isn't any harder than that. But, for some reason, we like to make it sound difficult through a plethora of technical terminology.

Instead of iterations, why don't we just talk about tackling big projects a bit at a time? [In fact, I'm yet to discover a better way of solving huge problems than breaking them down into a collection of smaller ones] Instead of backlogs, let's just have a prioritised list of requirements. Instead of standups, let's just have regular and frequent meetings to keep everyone on the same page. Instead of sprint planning sessions why don't we all get together to iron out a detailed plan before we commit to our next chunk of work?

I guess what I really want to ban is unnecessary jargon - at least when dealing with the non-technical contingent of the business. I think we should use common everyday language to describe what are, ultimately, practical and common sense activities.

Just because we're solving complex and difficult problems doesn't mean we need to use complex and difficult processes - in fact, one could make a case for quite the opposite.

Reporting & Agile

When I talk to people about their experiences with agile development I frequently hear - from the business side - that once all the bureaucracy has disappeared (which no one tends to see as a bad thing), they struggle a bit with the visibility of projects and the reporting of progress.

This view is usually 100% in contradiction with what I hear from the same organisation's development practice - who will usually tell me that visibility has never been greater and that they have an unprecedented degree of transparency and openness with their business partners.

Can they both be right?

When we, as engineers, make statements like the above we're usually referring to the public nature of our SCRUM/XP/etc artifacts - product backlogs and burndown charts are open to anyone in real time, requirements, estimates, and plans tend to be kept in readily accessible web tools, and of course most events in the process (such as daily standups and each iteration's demo) are public forums. What else do you need to have the most detailed, accurate, up to date view of every piece of work anytime you want it?

This is all true, but where we tend to go wrong is in underestimating the underlying complexity of something that inherently makes sense to us. There is actually a significant degree of interpretation - based on technical knowledge built up over years - necessary to answer a simple question such as "how are things going?" through agile artifacts alone; we just tend to be pretty good at doing it in our heads as we go.

Here's a simple example to underline my point. O2 has a pretty nifty self-service portal, and I can use it at any time of the day or night to see what my current mobile phone bill is and how far through my monthly quota of data and text messages I am. It works well for me because they have taken some underlying data about my account, put it through some pre-processing to provide some plain-English conclusions, and presented it on the web conveniently formatted so that I can interpret its meaning. Instead, imagine if they did transparency and self-service as we sometimes do in software delivery and just told me that all the data is there - the same artifacts that they use internally are open to me - and I must draw my own conclusions from some raw material. I guess I would install toad, connect up to their DB, select my rows from the billing table, join that with my rows from the metering table, and dump them into a view that showed me a current bill value along with my unused quota of texts etc. A few of us out there would probably quite like this alternative but, nonetheless, we have to agree that it is unlikely to be a level of service that the majority of O2's customers are going to be happy with let alone know how to use.

So what can we do differently?

Try to aggregate and simplify a bit for your stakeholders; provide just a little more interpretation and presentation on top of the solid data you already keep and it will be much easier for non-techies to make sense of. As long as you are not misrepresenting the underlying facts (easy to do unintentionally whenever summarising data for consumption by others) you'll probably find that your business partners will refer to that as the 'transparency' you've been trying to achieve and they'll thank you dearly for it.

Just a little more on SLAs…

Yesterday I posted a little something about SLAs and I’m always happier with things when I can wrap them up with a handful of guidelines.  Not always possible in the complicated world we live in, but here goes anyway:

1. Discover the things that are meaningful for the business.  I risk stating the obvious but there is always a temptation to approach this ‘backwards’ by starting off with what can be measured rather than what is significant (and then working out how to measure it).  You don’t want to end up with a bunch of metrics that are easy to count but don’t describe desired system performance.
2. Strike a balance between persistence and change.  Unless doing lots of projects isn’t important to you, be careful not to base all your KPIs on availability/stability metrics – or if you do, at least be aware of how that can drive reluctance to push changes through the system.
3. Make appropriate interpretations for each product or system.  In most organisations different systems, or parts of each system, are subject to different uptime, capacity, latency etc demands.  And assuming you pick some basics like performance they should be specific to each product; for a website that might be a number of page impressions, and for an analytic system that might be a time to render when a data set is updated.
4. Include time as a dimension.  Most businesses – particularly on the web – have a number of 24x7 products, but there are also a lot of systems that only get used during business hours or at certain intervals (e.g. payroll is usually a monthly thing).
5. Disregard #1.  Kind of.  Now that you’ve gotten this far, you will need to consider some feasibility, because signing up to unachievable SLAs doesn’t help anyone.  Have a look at what devices and services underpin the business functionality you are measuring.  Trees of dependencies, composites in SOA for example, tend to live up to the least strict SLA rather than the aggregate of the set.

Rules of thumb – apply in conjunction with local knowledge!

More Meaningful SLAs

Establishing internal service levels with the rest of the business is a difficult process - there are so many variables that can be measured and, as we all know, you change what you measure by measuring it. For example, if you express your SLA exclusively in terms of system uptime, then you improve all the activities around keeping your system available. The flipside of this is that you often discourage the activities around effecting change in the system - after all, any releases or upgrades or new features always carry some risk to availability and that's what they're measured on...

The place to start is to work out what's important to the organisation. Performance and availability are critical to us (a latency sensitive transactional platform with variable usage patterns) but so is change (a content driven web application correlated with events in the real world). We decided that performance, availability, change, and support response were the key metrics for us - nothing unique so far, and next we had to make an interpretation of each of these that was relevant to our various systems.

A basic principle here is recognising that it isn't just the raw numbers that should be appropriate to each individual product, but what is being measured too. Throwing an overall value at the problem (for example 99% availability across the board) makes the job of putting together your SLA easier, but is it a true reflection of your infrastructure? Whenever I've seen this coarse-grained approach used it has always led to less than acceptable uptime for the most critical applications and wasted investment propping up others that are realistically less important.

Another way to make sure your SLAs really closely matches business need is to introduce the dimension of time. In many systems and many organisations demand - and the cost of downtime - varies over time. For example, how many accounts and payroll systems are used around the clock? If you can trade off to 'best endeavors' over weekends and evenings then you shouldn't have too much trouble meeting a five nines commitment during business hours between Monday and Friday.

For our website we have a flat availability target (such is the nature of a 24x7 site) and performance we interpreted in a latency metric for price publishing and order placement. For reporting systems - which do not experience the same round-the-clock demands - we have different availability targets during business and after hours. Performance in the context of those systems is interpreted as a certain set of daily reports delivered by a fixed time each morning and a message delivery SLA on alerts on certain events. SLA's around change and product delivery are much more complicated and fraught with subjective measures. We've gone with measuring development projects iteration-by-iteration; what got delivered vs. what was committed during that sprint's planning. It's objective and encourages good estimation and strict control of scope creep during a sprint.

Making SLAs commensurate with what the business genuinely demands from a given piece of technology is important. Setting your sights high can seem like a good idea on the surface but, when you consider the frightening magnitude of difference in cost between 99.5% and 99.9% uptime, that couple of points can only ever be described as waste if they are not intimately linked to the organisations success.

5 tips for more strategic budgeting

With the end of the financial year looming as the next major fiscal date in many UK company's diaries, IT people everywhere will soon be embarking on the wishlist-to-business plan journey that is the budgeting process.

There is already a lot of good advice out there on how to estimate numbers and prioritise what makes the cut, and that can be a brutal process, so here's a few things I keep in mind to make sure I'm not being too short sighted:

1 - Know the cost of a customer. The rest of this list isn't in any particular order, but this is definitely number 1. Most good CIOs and CTOs I meet know what this disk array costs vs. that disk array and what these licenses cost vs. those licenses, but not that many know what a customer costs to acquire and convert or to reactivate if they drift away. The relevance? Knowing that means you can work out exactly how many frustrated customers you can lose because of that bug before its worth fixing, or that slow server before its worth upgrading. In this light, things that might otherwise not have made the cut become the no-brainers that they should be.

2 - Don't be influenced by trendy buzzwords. There is always a meme that vendors will be able to exploit because of our inability to apply common sense and logic to a pitch on whatever the currently fashionable thing is. SOA, virtualisation, and cloud computing come to mind whenever I recall ill thought through spending sprees. That's not the same as saying that these - or any of the other candidates in the same category - aren't good technologies with valid applications, just that any investment in them should be handled with the same pessimism and judgement of real business value as money spent anywhere else. Just adding 'cloud' onto the name of a product doesn't change it's fundamental ROI, so don't let these slip by you unchecked.

3 - Know the cost of scale. When sizing up a new project, give growth plans some weighting rather than just initial costs. Depending on the degree of speculation involved in your plan, taking cheaper entry options can sometimes bite you when you reach scalability limits.

4 - Wider consultation. A year is a long time and a budgeting exercise inevitably involves dusting off your crystal ball and trying to foresee everything that everyone is going to want in the coming 12 months. Good luck with that and, although it seems a little obvious, spending a bit more time with each area of the business trying to coax their plans and ideas out of them will at least expose the bigger ones up front.

5 - Increase priority on core things. Another one that sounds obvious but - through its limited practice - clearly isn't. In tougher economic times it is particularly important to give the most crucial things the most attention, and it can be mistake to favor too many might-lead-somewhere-might-not initiatives over those core basics upon which the business depends today. I think it is critical to set aside time and money for innovation and to take a punt on those less-certain ventures that our instincts tell us have that commercial je ne sais quoi but it needs to be proportionate to the main line. This is important when deciding what to drop in order to bring your wishlist and the available cash resources closer together - big but critical projects can be easy targets because they pull back more cost in a single swipe than a number of smaller but less meaningful items will.

Standups vs Team Meetings

When teams first start to pick up SCRUM, there is a tendency to let stand ups replace regular team meetings. The risks here are that your stand up will elongate and get off topic because it is the only chance you get to talk about issues as a group, yet your team cohesion will still suffer because no matter how long you can string out a stand up in the morning it won't be long enough to table all the things you need to get through as a team.

A stand up is a project-oriented meeting, all about running the day to day work of the team, has a tightly fixed agenda, is time bound, and specifically focused on what's required for today.

A team meeting is a team-oriented meeting, all about maintaining the team, continuous improvement, future requirements, and focussed on bigger picture topics.

They are definitely two very different meetings with two very different purposes, and both of them are necessary for a team to run smooth projects and keep productivity and job satisfaction high.

I think you might have it backwards

The most common criticism I hear about agile is also the most common mistake teams make in their early adoption of iterative practices - not fixing any certainty.

One of the benefits of managing projects using, for example, SCRUM is that you're not burdened with having to define all the requirements up front and plan out all the tasks and times for all the resources for 6, 12, 18 months. Trying to precisely define everything a project needs up front and trying to plan for every dependency, holiday, resource issue, structural or strategic change over a long period of time proves again and again to be an impractical task.

Enter agile.

Suddenly we don't have to worry about the detail of every change and every movement over an entire year, and we're introducing a whole bunch of flexibility. Where it goes wrong is not fixing any certainty in the delivery process at all.

Agile is about certainty and detailed planning, just detailed planning over a period which is possible to predict. Who knows what'll happen over a year, but you at least have a fighting chance of planning out the next 2-4 weeks will some degree of accuracy. Beyond that you can keep plans and requirements fluid and high level, netting you the right balance of fixing doable deliverables and keeping flexibility.

Software delivery needs certainty to happen - you have to be able to rely on some requirements and some resources over some time span in order to make progress - and agile isn't about not having any, it's about having it on terms you can foresee.

conferences - jolly good or just a jolly?

It has always interested me that two different people can look at the exact same conference, and one declare it to be an unmissable event relevant to their work and the other consider it a waste of time; a free day out of the office at best.

It always leads to a discussion about which events are worthwhile and which aren't, but here's the secret - whether a conference is worthwhile or not is only 10% the event itself and 90% what you do while there and afterward.

You could carefully plan the sessions you attend, take the time to meet people with similar technical problems or who have done worked with relevant technology and follow up with them later and, when you return to the office, share your new knowledge around and adopt some better practices.

Or

You could have a few days out, enjoy some vendor's hospitality (free beer always tastes better), and check out some new bars and, when you return to the office, settle comfortably back into your old habits.

That, ladies and gentlemen, is the difference between a jolly good conference and just a jolly.