Intellectual Property in 3 posts – episode I

I originally called this ‘Intellectual Property Done Quick’ but, when I was finished and looked at what I had wrought, I realized that ‘done quick’ was likely to be in breach of the trade descriptions act.

So I’ve broken it up into 3 tasty morsels; today I’m doing an introduction to different types of intellectual property and I’ll follow up with applying for a patent and then finally some tips for managing IP in the enterprise.

There are 4 main types of intellectual property defined in UK law and, along with their relatively dry legal descriptions, they are:

Trade marks

Indefinitely protects signs which distinguish the goods or services of one undertaking from those of another.

A trade mark is a distinguishing badge of origin which can be a valuable asset when it imbues a product with the reputation and perception of a certain maker.

It can become a trademark either by initial registration or it can acquire trademark status over time through use.

McDonald’s golden arches, the UPS shield, and Nike’s swoosh are all good examples of a trademark – instantly recognizable and clearly identifying a specific brand.

Registering a trademark gives an organization or an individual the right to prevent others from using the same mark it in relation to similar goods or services (listed in the application). Even if you have no appetite for hunting down and suing IP trespassers, registration is still a good idea because it prevents that happening to you – priority (‘I was already using that before they registered it’) is a tough argument in trade marks. And, in the longer term, if you’re ever likely to want to license the use of your trademark to others then registration establishes an official article against which a license can be granted.

Patents

Protects the technical aspects of products or processes for 20 years.

A patent gives the patent holder exclusive rights to prevent anyone else making, using, or selling their invention for a fixed period of time (usually 20 years) before it becomes part of the public domain. Patents cannot be extended beyond their initial term – they arose as a way of governments encouraging innovation; essentially we agree to keep inventing stuff for the good of mankind in exchange for a period of state sanctioned selfishness in how that invention is manufactured and sold.

Patents are territorial – only good for the countries they’re granted in – but a number of international agreements exist which allow. In the EU we have the European Patent Office where a single application covers 36 nations, and for the wider world the Patent Cooperation Treaty covers 130 countries. In both cases you have 12 months from your ‘home’ filing date to extend internationally before it is considered a new application – this can be important as your initial filing date is considered to be the date from which protection becomes effective.

Check out James Cameron’s platform for stereoscopic image acquisition (also known as a camera mount) for example and improvement in velocipedes (also known as bicycles) for something a little more old school.

Registered designs

Protects the appearance of products for 25 years.

For a long time it has been recognized that the appearance of a product can be the key to it’s commercial success – may I present, as evidence, anyone who buys anything from Apple.

A registered design gives its holder the right to prevent anyone else making or selling products which look and feel the same as the registered design. It covers tangible, physical, crafted things (like the famous coke bottle) as well as conceptual, aesthetic things (like the famous coke logo).

Registering a design is quite straightforward – compared to a patent application – as it does not involve any detailed scrutiny by an examiner. Apply to the Intellectual Property Office and, within 3 months, you could be the proud new owner of a registered design. Also unlike patents, you have 12 months from when your design first becomes public to register it; with a patent when it’s out it’s out!

Design rights

Protection for appearance of products without any special application being made (for example copyright).

Design rights are a collection of automatic protections which apply to various original works. In practice they work very similarly to registered designs – and apply to similar works and materials – but do not need to be applied for in order to take effect.

The subclasses (if you want to be geeky about it) are:

• UK design right – protects shape and appearance, except for surface decoration, for either 15 years from the creation of the design or 10 years from the first time the design was marketed.
• Community design right – similar protection to the UK design right and also covers surface decoration, however it is only valid for a maximum of 3 years from the date the design was made public.
• UK copyright – can be thought of almost as the opposite of UK design rights because copyright covers surface decoration (not form and function) and ‘artistic’ qualities. In force for 25 years from the end of the year in which the design was first marketed.

If design rights apply automatically why would you pay to register a design? If you rely solely on automatic design rights then you must prove that a similar product was copied from your protected material – with a registered design you can prevent another party from making or selling something similar whether they copied you intentionally or by coincidence. It’s pretty easy to determine that two items are similar, but a lot more difficult to prove why.

So that’s our 4 identified types of IP.

In the technology and software business you’ll mostly deal with copyright and patents. In my next post I’m going to walk though patent application process since copyrights kind of happen on their own and the granting of a patent looks simple from the outside but turns into quite an arcane art.

And finally, now that we’ve covered formally establishing and reserving rights using the various offensive and defensive legal tools available to manage IP, the thought I want to leave you with is that there is nothing quite like good citizenship. Treat the property and creations of others in the same way as you’d like them to handle yours – patents, copyrights, or not.

Steriods for Signups

Anyone who runs a business on the web should be intimately familiar with the registration funnel (sometimes called the recruitment or conversion funnel) so - except for the briefest review to frame the problem - I'm not going to rehash that here. Instead I'm going to cover some common and some not-so-common ways to boost registration numbers.

So, for the quick review, the registration funnel is basically the set of steps a potential customer traverses on their way to becoming an actual customer (converted) and typically starts with a site hit and ends with an active user account. What these steps consist of varies with the nature of each business and might include things like a shipping address or a credit check along with the basics such as username and password.

The problem every web business faces is that the registration funnel is essentially a very lossy process. For example; of every 100 site visitors, 50 will start the registration process, of that 50 25 will complete the process, and of that 25 10 might go on to place their first order. Even with the best husbandry many web businesses have single digit conversion rates. With marketing on the web becoming more sophisticated and SEO/semantics driving smarter access to content getting the numbers in the top of the funnel usually isn't the problem and - just like any other lossy process - there can be a big impact on the bottom line by improving the rate by just a couple of points.

So how can you juice this up?

The very first thing you need is data. Just like everything else you need to understand the flow and then you need to instrument the heck out of it before you should be fiddling with it. If you haven't already got this in place then stop reading now and get on with it - the rest of this is useless without insight.

Separate your registration process out in your head; this will help you understand and instrument it. Think through all the steps in your funnel make it as granular as possible - this gives you much more insight into where potential customers drop out and much more flexibility in how you modify the process in response. Crudely; if you're thinking visitor -> credentials -> personal details -> checkout then you should be thinking visitor -> credentials -> name and email address -> shipping address -> checkout. This doesn't necessarily mean more pages or more data for customers to enter (in fact the goal is the opposite) but it does mean than you can count these things individually to see exactly what bit of information your potential customers get reluctant about handing over and it allows you to stage things a little more (see below).

The general principle is to put the fewest barriers between your potential customers and your product as possible. This means looking at what information you're asking for, when you're asking for it, and how it's captured. In some businesses there can be constraints which have to be acknowledged; with a product which is regulated or controlled in some way there may be some external rules which can reduce your options - such as the requirement for identity verification or credit checking - but the keyword here is reduce. The registration pipeline in these types of business is often poorly managed for this reason but it doesn't always need to be; take the time to understand the details of your governance and you will usually find that you have more flexibility than you assumed. For example you might need to verify your customers identity somehow before allowing them to make a withdrawal but does that have to stop you from granting them access to the rest of your product entirely?

Nice segue into staging. One of my favorite techniques in businesses with more complex registration requirements is to focus on capturing the absolute bare minimum during an initial signup (usernames, email addresses, passwords, etc) and capturing the rest 'just in time' in line with access to features. For example; why not delay asking for a physical address until the first time a user reaches the checkout? Why not ask for payment information just before their first purchase? You don't need that data until those events and having to enter it all up front can be prohibitive especially when potential customers might not be 100% sure that you're the service they want. Also think carefully about when you want to trigger the 1st step of the registration process - there can be benefit to letting potential customers play with a little bit more of your product before hitting them up for some credentials (but you have to balance this with less complete early contact information and the risk of taking it too far and having fewer accounts because the majority of the value is available anonymously).

Usability is an important aspect here. Considering the number of screens in your signup process, the number of fields, and even the phraseology of the questions can improve your conversion rates.

Also consider the order that you're capturing information in; if you start with email addresses and you're automatically storing fields as they're completed - a highly recommended Ajax trick - then you have some actionable data to go with your telemetry. You might want to use it for a follow-up contact to see if you can claw a customer back from the edge of registration oblivion.

Another consideration when you're designing your forms is to keep in mind the sort of information users are likely to have close at hand when signing up for your site. The more esoteric (in day-to-day terms) the information you ask for is the higher the chances that a potential customer will need to go elsewhere to retrieve it during the signup process. Data always shows that anytime a customer leaves the page(s) for any reason the changes that they'll return and complete them drop through the floor. What might you not even need users to enter at all? You can pick up things like language and locale from the browser and tools like geo-IP; adjusting a probably-correct field from a list of common choices is far preferable to data entry.

While we're on forms; short and sweet is the way to go. Whenever you have to go 'below the fold' then you're better off splitting the form into multiple pages (otherwise it appears too daunting) and, when you're going across multiple pages, then label the progress. A simple 'page X of Y' can work wonders setting expectations.

And finally, if there is a relevant infrastructure for your line of business (meaning that you can trust it and that a portion of your users are likely to be members) you can consider using an identity service, such as OpenID, to implement a kind of 1-click signup and then just capture the additional information you need to operate the account.

Change it and see what happens - after all you're collecting all the data you need, right? If you're crafty enough then you can do some A/B testing with alternate pages or different text. As long as you're measuring the process you will really quickly find out what's better and what's worse.

Adding a feature dimension to planning boards

Planning boards – sometimes called task boards – are a great way to make work visible, facility teamwork, and surface impediments.  The work required for a given iteration of software is broken down into a collection of individually owned tasks and then, as work progresses, we watch those tasks migrate towards the right hand side with a sense of satisfaction.

This is unprecedented transparency and one of the reasons why I love it, but it does have one small shortcoming.  If you’re not intimately familiar with the work (say, for example, a non-technical stakeholder) then it can be a bit hard to determine meaning.  Yes things are moving along, but what really are those things?  Of the 4 stories we’re doing this sprint, which business feature does this progress (or impediment) relate to?  It looks almost all done but are we saying that we’ve done 3 of our features and we’re working on the 4th or that we have we done 80% of each of them?

We do want the business to be engaged and to participate in the process so we ought to try and make it interpretable for them.

Some of my guys recently started adding a 2nd dimension to their planning boards; features.  By adding a horizontal view which groups tasks by the requirement they relate to as well as the usual vertical view which groups tasks by their status (not started, done, etc) you get an at-a-glance view of the progress of each piece of business-relevant functionality, rather than just a broad sense of things happening.

Even I find this easier to consume!  Rock on you little geniuses (you know who you are).

MVP in the Enterprise

Minimum Viable Product (MVP) is a well understood concept in startups.  It is all about distilling your features down to the barest of essentials – those things which really make your product your product - in order to get something out rapidly and be able to quickly iterate guided by feedback.  From working at both ends of the startup-to-mature-business spectrum, it occurs to me that the enterprise could learn a thing or two from its lighter-weight cousins.

To broadly generalise the circumstances I’ve seen:

We’re pretty good at this MVP thing in early stage startups.  Mostly because, as we plan an iteration, we are fully aware that we might not be around for another iteration so whatever goes into this one has to count (in fact it might count for everything).  We think lean.  We’re typically good at serving our customer’s most immediate and pressing needs.

In the enterprise we have the luxury of working with the confidence that, even if the immediate next set of features don’t quite hit the sweet spot, we’ll be around for many more iterations yet before times start to get tough.  We think deep and wide.  We’re typically good at serving a big strategic master plan.

Being able to take a longer term view of a roadmap is definitely an advantage and having to spend time worrying about things like scalability is a nice problem to have, but this doesn’t mean that we can’t also think lean.  In fact some of the most value I’ve added has been in the amount of work I haven’t done...

It can work in big business.

Recently I looked at a system to capture and analyse certain customer activity in order to get an earlier prediction of lifetime value and make data-driven cross selling decisions (which ought to push up average revenue a notch) and, on the surface, that seems like it’s worth the pretty hefty licensing, integration project, and infrastructure costs.  We started off modelling it and running the numbers; at first synthetically and later with real data.  What we learned through this early prototyping is that those features which were initially so attractive made very little difference to our business, however our little robot was uncannily good at identifying fraudulent activity.  So we switched the direction of the project, chose an alternative platform, saved a bunch of money and got some functionality which genuinely benefitted us.  Sometimes you know what the real benefits are going to be up front, sometimes you surprise yourself along the way.

We’re also planning to introduce a pay-as-you-go commercial model for our feed products.  When you add up a metering system to watch client consumption, a dynamic pricing system to set tariffs, a billing engine to produce the required invoices, and some reporting tools to keep an eye on its performance it starts to become a fairly significant undertaking.  Will customers like it?  Will it work like we hope (add top-up revenues to committed subscriptions) or like we fear (cannibalise commitment for shorter term hits)?  The best way forward in these circumstances is to ask what is the absolute minimum amount of work I can do to see if this works?  As it turns out we could do a some basic instrumentation (to get simplified metering), use some static pricing, and do the billing manually.  Net result?  A much smaller piece of work – useable in production with real customers – demonstrating how successful it’s going to be.  Now we can build on this with further iterations until we have the fully-featured and refined version we first dreamed up.

There are many more examples, some of which have worked out just fine – so we’ve kept building on them until they were feature complete, fully automated, and enterprise quality.  Others have failed – so we’ve cut our losses (fail fast fail cheap; writing off a few thousand not a few million) and moved onto something different which did turn out to be a winner.

Just because we have the budget and the appetite to do the whole shooting match right away doesn’t always mean we ought to.

The obvious risk here is becoming too short sighted with your plans.  The secret to making this work is to imagine big but plan small – keep a long term roadmap and have a clear vision of where you want all your products to get to, but take small, tightly scoped steps along that path.  Stop and evaluate frequently, adjust big picture where necessary, rinse and repeat.

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…

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.

Technical Debt Credit Rating

A while back I wrote about how closely technical debt paralleled financial debt and then a short follow-up post with the meta-message that, through the right reductionism, certain things will always cost you an inescapable minimum and the decision that you really have is about where you choose to make that payment (I argued that you either pay through the correct design and build initially, or you pay through unnecessarily increased maintenance costs later).

Outlawing technical debt is as foolhardy as always cutting corners - sometimes the right thing to do is to take a hit to get something out sooner or in a certain shape - the problem is in the repayments; in other words, they often don't exist. And if you don't go back and sort your hacks out early they tend to accumulate in the system and before you know it developing on it is like moving through treacle (and the treacle occasionally catches fire). Everything else you do takes that much longer and is that much more expensive (and those are business metrics) and can have unintended consequences - it's a crippling burden just like its financial counterpart.

I have a rule - no one is allowed to take technical shortcuts through a project [where that = incur some technical debt] without showing where, in the same plan, they go back to do some refactoring so that our long-term assets remain sustainable. We're pretty lucky at Sporting Index; most of our stakeholders value technology and recognize how critical it is to the business, so it's a conversation I rarely have to have - but I know many other companies are less fortunate.

So now I think I have a better idea. It came to me while I was thinking about why, if technical debt is so similar to real debt, it doesn't regulate itself in the same way - and I think that's becuase there is no concept of creditworthiness in technical debt, in other words no assessment of a team's ability to 'repay' a quality compromise (read: loan of functionality to the business ahead of when it otherwise would have been ready) alongside all the other outstanding quality compromises that they already have.

But we might be able to simulate that...

Imagine giving each product manager a 'credit rating' of, say, 3 - meaning they could call for unsustainable technical shortcuts 3 times as they worked with the delivery team to determine their solutions. Once those 3 debt points were used, that product manager would be unable to encourage the team to make further quality compromises until at least one of those was paid back. If you have product managers with a demonstrated track record of revisiting earlier deliveries to address technical debt then why not give them 5? A higher creditworthiness ought to enable an individual to take on more concurrent debt as we can be more confident that they'll come back to service it.

I pretty much guranttee that any product manager's cavalier attitude towards shortcuts would change and they'd suddenly treat technical debt as the instrument it really is and use it only where it mattered materially. That, ladies and gentlemen, is a feedback loop.

The downside is that you'd have to be better at tracking this sort of thing and, like any other method, it'll need some discipline when a product manager with maxed out technical debt points wants just one more shortcut. If you've ever had to maintain a spaghetti codebase (as most of us have at some point) then you'll know that these things need closely policed anyway, so perhaps being forced into formally tracking it isn't so bad.

Nobody Wants Computers

Well they shouldn't - they should want what computers will do for them.

Many people turn up to conferences or SIG meetings and ask me how virtualisation or a centralised inventory database or VPNs (or pick something) will help their company. Misguided. My response is always the same - what is your business case and what benefits are you expecting? I do get quite upset when I don't get a good answer to that, because it means someone somewhere is cooking up some technology for technology's sake.

Sales functions are excellent at creating a need around a product they sell - great if you're in that business and I used to be - but it is the functionality your organization really needs that should matter. Talk to me about outcomes, goals, what you want to be able to do from a business capability perspective, and then the right technical solution will fall out of that.

Contorting business processes to fit a specific technology or vice versa - i.e. doing it backwards - only ever works when combined with a healthy dose of luck.

The ISO standard for business plans

If I had a quarter for every time a budding entrepreneur has asked me about what should go into his business plan, then I'd have - let's see - three fifty? I don't know, but put it this way, it's in my top 10 FAQs. My two secrets behind this one are; a) there is no such thing as a standard format or expectation and b) it matters a lot less than you probably think.

Don't agonise over format and presentation - the vital thing is to intimately know your key facts and be able to provide a logical narrative for them. What are your costs? Where does the revenue come from? Who are your customers and how big is the market? How soon will you start bringing in revenue? How is your product different from any competitors (current or future)? What does it cost you to acquire new customers and what is their lifetime value? Have you done this before and who do you plan to work with? Even if you just talk through it you're always better off knowing those things inside and out than having a 200-page glossy document.

And when I say that a business plan matters less than you think it isn't because investors won't want one - they very much will - it's because in the early stages of a new idea what matters most is working product. The best, most detailed, most polished business plan in the world will always be worth much less to a potential backer than a pretty basic, hacked together but functional, beta product.

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.

The Paradox of Freemium

One of the businesses I advise recently flipped over to a freemium model and – as expected – saw a step change in paying subscribers. It does lead to the question; in a world where we typically make money by making things and then selling them to others, how did we decide that giving valuable things away made commercial sense?

Firstly, for those who may have spent the last few years in a cave, I broadly define freemium as giving away something of substantial value along with an associated upgrade/expansion path which returns benefit to the organisation.

This is already commonplace. So many of the everyday tools I use have an element of freemium to their business model; google apps, zen agile, bitbucket, linkedin, mockingbird, a number of podcasts (which lead to paid-for books or other products), and of course almost every iPhone app I see these days has a fairly comprehensive ‘lite’ version.

For a long time we’ve given away tightly limited trial versions, exposing a very small subset of the functionality (or usage time) in order to coax users into a purchase to unlock the rest, and freemium is almost a reversal of this. Give away quite a rich set of functionality with no expectations, and you’ll pick up a group of buyers for that additional stuff on top.

Making this happen comes down to product design; you have to make sure that you hold back something(s) compelling enough to encourage purchases while making sure that your base product is functional and complete enough to be of significant utility on its own. There are so many ways to slice this, and sometimes the differences don’t even need to be rendered – you might simply impose several distinct licensing terms (free for academic or home use for example).

In one of my all-time favourite Ted Talks, Dan Pink says:

"The mid 1990s, Microsoft started an encyclopedia called Encarta. They had deployed all the right incentives. All the right incentives. They paid professionals to write and edit thousands of articles. Well compensated managers oversaw the whole thing to make sure it came in on budget and on time. A few years later another encyclopedia got started. Different model, right? Do it for fun. No one gets paid a cent, or a Euro or a Yen. Do it because you like to do it.

Now if you had, just 10 years ago, if you had gone to an economist, anywhere, And said, "Hey, I've got these two different models for creating an encyclopedia. If they went head to head, who would win?" 10 years ago you could not have found a single sober economist anywhere on planet Earth, who would have predicted the Wikipedia model."

I think those same sober economists would probably have said much the same thing about freemium, and probably much more recently. Getting customers to pay for your product by first giving most of it away wasn’t common sense – and maybe it still isn’t – but you certainly can’t ignore the evidence that it works.

Encouraging Profitable Usage

A couple of weeks ago a friend sent me this article from a mutual acquaintance at CCP. It's all about the continuous struggle that the MMO guys have keeping their in-game economies balanced amongst all the real-world trading of items and game currency.

I was particularly interested in the stats near the end - in a crackdown on gold farming they managed to drop CPU utilisation 30% through a 2% drop in players (banned accounts who were violating these terms). To paraphrase that; 2% of the player base [revenues] were creating 30% of the load [costs] and that my friends, is what I call unprofitable usage of a product.

When you read that last sentence it makes perfect sense, however so few of us on the web think this way. How often have you looked up your top workload creators (page impressions, transactions) and your top revenue creators (purchasers, subscribers) and compared the two? How sure are you that your costliest customers - that you are probably supporting a collection of CPUs to service - are not marginal or worse in terms of value to your organisation? With sites more data rich than ever (read: more back end work per view) and screen-scraping a more widespread way to acquire content it's worth working to discourage this behaviour or at least make conscious decisions to allow it.

This thinking should be taken all the way back to product design - on the web we tend to emphasise users/visitor/subscribers without really thinking through what constitutes profitable usage.

It's not just about nailing people who are out to exploit you either - as a long time data provider my biggest issues have usually been well-meaning customers with lazy integrations. If you're going to build a client on top of a web API it's quick and easy to poll the bejesus out of it round the clock and then react to data in the responses rather than, for example, get a schedule of 'interesting' data and dynamically set up threads pick up smaller changes to discreet items on separate and appropriate timers. Take trades for example; why hammer a Hang Seng Index Options feed after 4:15pm? Or how about our feed - do you need 5 prices a second for this weekend's football fixtures on Tuesday or would hourly pre-match odds and squad changes be more than sufficient that far out? A slightly trickier initial integration but a better and cheaper product (for both parties) thereafter.

And finally I've always found it more effective to encourage good behaviour than discourage bad behaviour. Sometimes this can be as simple as an SLA which guarantees a superb latency up to a certain number of requests and creeps out in bands beyond that. Other times this can be purely commercial - why not extend better pricing to customers who genuinely cost you less to service or a tiered revenue share to those who contribute more to the partnership?

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.

Cloud Congress Done Quick

[well, my bit at least]

Yesterday I spoke at this year’s Cloud Computing Conference covering what cloud computing really is all about (once you peel away the hype) and how to break the back of the adoption problem – what do you put out there and how do you get started? It was the first time I’d ever done a talk that had absolutely no diagrams or pictures whatsoever in the presentation and, considering the plainness of the slide deck, it didn’t go too badly at all.

Excluding the mundane introduction, here’s the reader’s digest version of my key points:

What's in a cloud?

As a relativity new and trendy technology cloud computing is open to a lot of debate and even the 'correct' interpretation changes as the technology matures. We've had web applications for a long time now, so I'm not comfortable with SaaS being thrown into the cloud bucket. I like to define it in the context of how it changes how you deliver software (by abstracting away the complexities, layout, and connectivity of infrastructure from you developers) and how it impacts the way delivery costs are calculated (by exchanging metered billing on a usage basis for CAPEX-heavy up front acquisition).

My test (does your definition of cloud computing rely on the observations of your end users?) is simply to ask yourself "am I saying I am a cloud company just because my users access my product over the web?" If so, then perhaps you need to consider that maybe you might not be. Nothing wrong with that, but nothing new either.

What your FD sees

My next section expanded on the CAPEX vs OPEX shift that cloud platforms enable. If you have got your product design right then - on the web anyway - more usage should equate to more revenue and, with a cloud platform, more usage equates to more cost. See how that works? The cost base grows in line with revenues, therefore smoothing out that lumpy accounting and tricky budgeting activity that is characteristic of large hardware drops throughout a site's lifetime. You've also able to bring new things online relatively quickly (eliminating the ordering/delivery lead time/racking and stacking stages) and you can afford to try out slightly more speculative business cases - if I'm on the fence about a particular feature then I'm much more likely to give it a try if I know I can pack it up quickly and cheaply later if it's turns out for the worst.

Most cloud platforms have pretty good metering systems in place and that allows you a much more granular view of what part of your system is directly responsible for what parts of your cost base. From a business case perspective my advice here is to include all costs and not forget about time as a factor. Sounds a little obvious but when, for example, looking at Amazon's S3 as a storage platform for an analytical data set your total cost is going to include the transferring in and out of data as well as the cost per GB of storing it. Time matters too - I've seen the odd business case for a cloud platform fail to stack up because over a 3 year period more total cash is paid out than total cash spend once the large CAPEX bill is amortized over the same period.

Cloud capabilities

I also touched on some of the less obvious uses for cloud computing because so much emphasis is given to migrating existing systems into the cloud and I don't think enough time is given to considering what additional things that aren't being done now could be brought on because of the inherent properties of cloud platforms. These include private content delivery networks (because the larger cloud players tend to have a good reach), enabling offshore or outsourced development without opening your perimeters to external organizations who may have weaker security policies, neutral territory for integrations or joint ventures, and large scale load testing (because where else will you get hundreds of high spec load generators external to your network and connected over realistically-latent lines).

Development and testing environments are a good way to dip a toe in because, if you're doing it right, you will already have nicely sanitized data (which gets you clear of most of the oft-cited security concerns) and you won't be expecting production-sized load. It's also the best way to get a good feel for the cloud suitability of your production system without making any user impacting changes.

Architecting for the cloud

Many people - mostly those selling cloud integration tools or who charge by the hour - will tell you about how they can help you move your systems into the cloud. Don't kid yourself on. If you're using a half-way decent definition of a cloud platform then there is a lot more to it than is commonly appreciated. There are a number of good design patterns that I believe organizations should start adopting today and not just because they prepare systems for cloud runtime in the future, but also because they're pretty good ideas on their own merits.

It all starts with my favorite - decoupling and creating clear, distinct boundaries between functionality in a system and abstracting the specifics of the implementation which delivers said functionality behind a well defined interface. When you present specific uses of data to a network in this way then, subject to a bunch of common sense rules, you are able to host that individual part of your overall system another way - on different servers, in another data center, or hey, in the cloud! As long as it's reachable by it's consumers - which brings us nicely onto messaging and using state sparingly - you buy yourself the flexibility to move things quite dynamically. A service registry is also highly desirable if you a) have composites made up of many services and b) want to be able to move them and scale up/down dynamically.

All good practices for scalability and availability regardless of your stance on the cloud.

The crystal ball

You're not allowed to speak at an event and not give some predictions. I think there is an old charter or something somewhere. So mine were; barriers are coming down and this will continue with technologies such as private link and private clouds, as with all trendy concepts the waters will be muddy for a while as the word 'cloud' is appended to everything we've already got in order to sell it to us again, and within 5 years I expect to see hybrids (cloud-type platforms in use to some degree) in almost every organization.

Overall a good conference - some top panelists and speakers, and I met some great folks there. Thanks to all the guys and gals at SixDegrees for putting together a worthwhile and fun event.

You can find the slides here.