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.

The Product Management Boundary

Talking to a few of my industry peers (web CTOs and CIOs) about what they do, and to a few CEOs about their expectations, something that’s becoming clear is that we’re increasingly being expected to know what to do, not just how to do it.

Traditional IT uses that age old you-give-us-requirements–we-give-you-back-[mostly]-matching-systems paradigm or variations on that theme. Something we do would typically have a sponsor who dreams up a course of action and a handful of stakeholders who detail it out. What you call those people will depend on whether you think you’re doing agile, RUP, waterfall, etc but typically you’d place them in ‘the business’ rather than technology.

That seems to be changing.

Less and less are we being handed requirements documents or project specs and then going off and doing work to order. Now we’re being asked things like; how do we reach new users? What things can we do to increase wallet share? Should we be doing something with social media? How are we going to internationalize this product? Yeah, that’s right, we’re finally dealing in problems not in todo lists, and - in a trend which is gaining popularity - product management is increasingly being based inside the technical delivery teams.

The days of a business giving us defined work and us delivering projects against it are going to come to an end. A pessimist might suggest that this is ‘the business’ escaping responsibility for defining it’s future. I’d simply argue that technology is an integral part of any modern business, not something else extra and external, and since we’re all part of the same ‘business’ anyway then why shouldn’t we take our fair share of determining the strategy?

I think this is pretty awesome and, in some cases, overdue – after all, don’t we want a bigger influence over what the future of the business looks like and how we get there?  Do it CxOs!

The Abstraction Trap

Abstractions exist so that we can take shortcuts when building stuff.  They readily implement some of the messy necessities behind things like, for example, network access in distributed systems – but too often they’re used as an alternative to in-depth understanding rather than a reusable way to render a system.

Staying with our distributed system example; understanding the latency between nodes, synchronisation and blocking (and their impact on concurrent work), transport overhead and reliability, and what the behaviour will be if you don’t hear back from the remote service are all critical to the success of a complex project.  Without having to explicitly program these things it’s too easy to just drop something into a pipe or throw it at a web service and merrily continue on with life having never even considered those neatly masked complexities.  Until go live.

It’s the difference between something that functions on the bench and something that will work reliably in real life’s volatile conditions.

On the infrastructure side I see the same pattern emerging with virtualisation – we’ve now got this nifty and easy to use platform which takes us another step further away from the metal.  On the plus side we can stamp out more nodes really quickly and move instances of a server around from hardware to hardware to accommodate growth and failure, but on the minus side correlating what’s happening on pretend CPUs with a real CPU and oversubscribing hosts makes capacity planning a degree harder.

All these environments are designed to abstract things away from us so that we don’t have to worry about them or recreate them every time – but that’s not the same as saying we no longer need to understand the basics of what happens under the hood.

You’ll always have better product when your engineers have the low level knowledge (primitives and patterns) needed to design and build systems and understand how they will behave.  That’s different to simply knowing how to drive the tools.

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!

Architecture in Agile

When a team first starts practicing agile a question that usually comes up fairly early is where architects fit in.  In a set of processes which usually considers ‘big-up-front requirements’ it’s nemesis, it can be a startling realisation that we (the engineering side) might have our own version of that.  Architecture tends to be associated with big-up-front specs and, if you’re not doing any of that big-up-front stuff, then where does the role of an architect fit in?

The first step towards finding your answer to that question is to understand what architecture actually is:

Architecture isn’t something separate and distinct from your projects that you can either choose to indulge in or choose to abstain from – architecture is simply the shape of what you produce.  Everything piece of software in the world has architecture, the only question is whether it was done by design or by accident.  The question is essentially whether you drive it explicitly and control your technical destiny or whether you leave it to chance and hope for the best.  Driving it would be the job of the architect.

To make a slightly controversial statement, architecture by itself has no value.  But architecture, as defined as ‘the correct technology platform meeting the current and future functional and non-functional needs of the business’ is worth everything that you can put into it.  I believe in architecture.

Architecture must be explicitly handled – lest it get away from you and leave you with unsustainable systems – but that’s not the same as saying that you must have an architect.  You simply need to have the responsibility for the shape of the system (the technical decisions) clearly understood.  Why not devolve the responsibility?  Something common to most agile approaches is the empowerment of the teams to self-organise and take control of the destiny of their own product.  Architecture is no different and, where you can identify neat boundaries between different products owned by different teams, this type of ‘product architecture’ works very well with minimal enterprise oversight.  Less distinct separation between systems generally = more enterprise oversight.

Somewhat counter to the freshman agilist’s intuition, you do need to make some up-front decisions in most projects.  Agile is about making sure you know enough about something to be effective by when you need to know it – it’s not about knowing nothing.  The trick to handling technical designs is knowing what those up-front decisions should be and what’s better handled as part of how the project evolves.  Unfortunately this judgement takes some experience to develop, but a good guideline is to stick to things which can’t be easily changed later – such as schemas, APIs, and namespace.

If you’re a formally nominated architect in an agile environment my advice is stick to patterns and delegate implementation decisions.  When you are dealing with a flow of work and you can’t initially nail down the complete set of requirements in buildable detail – the business case for agile – then you have to let your vision for the product, and the size and nature of the commercial opportunity it supports, help you pick out the right patterns.  Patterns are the best currency for an architect to deal in if he has a team of smart developers keen to take some ownership; the ‘here is a design doc, build this’ approach becomes a constraint rather than a support.

In more larger or more complex agile environments – with multiple development teams and multiple products – an architects role moves into governance; the design of common elements and the way in which products integrate and interact.  What we might call enterprise architecture I guess.  The goal here is to put together a framework which promotes self-contained and distinct products, giving each team their own jurisdiction while still ensuring smooth overall performance of the whole estate.  In my experience this maxes out the total delivery throughput of the whole organisation and gives the satisfaction of ownership to the doers.

If you’re new to architecture (giving or receiving!) and need to make sense of all this then I’d recommend joining IASA because a key part of our mission there is bringing clarity to what an architect really does for a team, a product, and a business.

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.

Software vs. Infrastructure

For some reason I’ve been running into a lot of other CIOs and CTOs lately and one topic that keeps coming up was whether we were development or infrastructure focused. The whole time I kept thinking to myself why is this even a question? Why do we feel like we should choose? Or, somewhat more provocatively, why do so many of us only feel like doing half the job?

I concede that there is a ‘background’ element to this. No one I know started off as an IT executive; we were all DBAs or developers or sysadmins first, and that gives us a nice comfortable area of personal expertise we can use as shortcuts but it shouldn’t set our agenda in a leadership role which [in most organisations] encompasses the whole shooting match.

One of the reasons why many organisations suffer the good old fashioned laundry list of regular technical woes (that we could probably all reel off by heart) is because of the interplay between development and infrastructure and a lack of end-to-end oversight over both. And, as the technology leaders, if we don’t understand both sides, keep strongly engaged with them, and create teamwork and cooperation where there has typically been borders and a lack of mutual interest, then who will? There are very few other roles with a remit in both areas and even fewer that should be taking responsibility for them failing to be an end-to-end unit.

There is a whole ‘devops’ kind of meme swelling up these days – and more power to it; I think it is dead on the money.

Devops is, by nature of the organic meme it’s emerging as, poorly defined but to me it is about the recognition that [in most cases] customers care about product – not software or systems – and product is that butter-smooth combination of software and infrastructure finely tuned to work together and operational know-how to keep it running.

It’s also about having the right feedback loops in place between engineers and the real world, so that as your products get used and abused, they become more fit for that very purpose.

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…