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.