The 3 Elusive Qualities of a Product Owner

It may sound overly simplistic but in my experience products generally succeed or fail in correlation to the effectiveness of Product Ownership on the team. Mainly because we under-appreciate the importance and the difficulty of the Product Ownership aspects in the product creation process. In my opinion the choice of this role is far more important than the coach or other team members. The role is full spectrum, they go all the way from discovery to delivery and more.

Ironically, we tend to think of software applications as being primarily technical objectives, our focus is too often on the quality and ability of the engineers, the architecture and design. We will spend time on process and optimization and efficiency.  All the while forgetting that the most common and most consistent failure of all software products is that no matter how good the quality, how optimized or efficient it is, or how good the engineers are that built it – if you build the wrong thing it is a failure.  A perfectly designed but unused product is worthless.

History if full of great products that missed the mark, how many apps have you downloaded to your phone that are no longer used or were never used after the first 30 seconds.  There are many many more products that fail to ever get in the hands of customers at all. Internal IT products are often culprits of this, the assumption seems to be that because the users are forced to use the product we don’t have to actually ask them what they want or how they will use it, we build great products that don’t fulfill the actual user need.

1410209080-dont-let-these-3-myths-stop-you-from-launching-cause-marketing-campaign-stop-sign

I think probably my favorite and most over used quote is:

There is surely nothing quite so useless as doing with great efficiency what should not be done at all.

Peter Drucker

I use the quote far too frequently but in 25 years developing software this remains the most frequent sight I see, more products fail for not meeting the most basic customer needs than for any other reason. And yet when I say this, it generally gets scoffed at, until you start asking how many people have worked on products that have been abandoned or shelved mid development. Teams rarely believe their product is at risk of being cancelled, or are too far removed from the customer to appreciate that the user liking and using the product is infinitely more important than whether they are efficiently re-using a section of code. We have created a mindset that ‘done’ is delivering code.  A product/feature/story is only really done when the customer is using it.

Product Ownership does not need to be a single person in that role, but it should be a mindset within the team.  Ideally I’d love for this to be a shared responsibility. Unfortunately in my experience a true appreciation of Product Ownership is as scarce as Hen’s Teeth, and generally unappreciated and vastly underpaid, those that do it well make it look easy and doing it badly or being indecisive can really destroy a product so it can be a risk to spread the responsibility beyond one person.   I have heard people talk of teams where the teams do it well and they don’t need a PO, but I have yet to see this for myself.  Because of this experience I think of the Product Owner as the most important ‘hire’ for the team, getting the right person in this role can be crucial to the success of the product.

A good PO these days is hard to find…

So why is a good Product Owner so hard to find and what makes the role so difficult?

1: Differentiating what is needed from what is wanted

A significant part of the role is identifying what is needed to solve your users problems or to fulfill their needs, to enable them to be better at their job, or to maximize their fun or relaxation.   The role is about understanding the problem and creating a vision of how that could be solved – not the technical solution but discerning the true need or true problem.

Henry Ford With 1921 Model T
Henry Ford stood next to his ‘Faster Horse’

 If I had asked people what they wantedthey would have said faster horses.

Henry Ford

The reason this skill is so tough is that users rarely know what they need, typically a user’s vision is constrained by what they currently do. As a result many products become re-works of a paper system or re-engineering an old system.  A poor product owner gives a customer what they want or what they ask for, a good product owner listens and watches and blends wants and needs to solve the customer’s problem and give them what they need.

tree_swing_development_requirements-scaled1000

I often seen backlogs that are full of stories that are unfiltered customer requests, it is lazy and it is easier to do what is asked. But to find what is needed typically requires experimentation, feedback, conversations and observation. It is far harder to build what is needed than it is to build what is asked for.   Similarly this can manifest itself when department managers decide what their team needs or wants without involving them in the discussion, a good Product Owner will spend time with the users of the product and ideally see how they use it.

A Product Owner with the creativity, the initiative and the Vision to create a great Product is worth their weight in gold,

2: Understanding what is required to create a successful application

A second aspect of the role is the one I see most frequently overlooked. Perhaps because of the emphasis on 1, the need to understand the business, I see people choosing someone from the business to become the Product Owner, their knowledge of the business is seen as their primary qualification and in many cases their only qualification for the role.  And worse they are often asked to do the role in addition to their normal job.

However, a great Product Owner understands not only what to build but is familiar with the development process, they understand the ebbs and flows, they understand the implications of technical debt, automation and testing. The understand how crucial it is to have working software in the hands of users as soon as possible. I am sorry to say that business POs often lack this knowledge and experience, they will mistakenly perceive a desire for a fully working product rather than appreciate the value of early feedback. Many are plagued with the last bus syndrome, trying to include every imaginable feature rather than working towards a minimum feature set to get feedback and derive value early.

rocket-flat-design-concept-for-project-start-up-and-development-process_1561-39

Personally I’d invariably trade an experienced Product Owner with zero business knowledge for an expert in the business with zero software delivery experience.  Business knowledge can be gleaned from effective conversation, observation and feedback. The understanding of a good Agile Software Development lifecycle is far harder to learn and there is no substitute for experience.

Typically the best products result from experiments, reviews and feedback, a willingness to be flexible and respond. The other disagreeable quality of a Product Owner taken from the business is that their knowledge is about how the work is done now, and they are often blinkered to the possibilities.

Remember that the Product Owner sets priorities and interprets the Vision, they have more influence on the product creation than anyone.  Their choice of priorities can profoundly impact the value, and the quality of the product. If they lack the understanding of the importance of testing, feedback and good software principles it can lead to conflict and disharmony in a team.

3: Communicating effectively with both technical and business stakeholders

Finally there is a need for effective communication.  We always talk about effective communication to the point that it becomes background noise.  But the importance cannot be overstated.

A great Product Owner, listens, they observe, they probe and they reflect.  The ask for feedback and they read between the lines, they watch body language, they see and hear what isn’t said as much as what is said.   When it comes to understanding the user they have great attention to detail and they look intently for pain points and points of pleasure, they are looking for a way to serve their users in the best way they can. Most of us think of communication as speaking, but for a Product Owner watching and listening are so very important.  Empathy with the user, the customer and the ability to communicate using their terms and understanding their domain and conversing with them in a meaningful way is crucial, and if you don’t understand the terms develop an attitude of attentive student ask questions and show you are interested and are learning.

A great Product Owner learns to say ‘No’ powerfully respectfully and does so in a way that conveys they understanding to the person asking, a great Product Owner should not be seen as an obstacle or a hurdle but a steward of good decisions. The word ‘No’ should be delivered in a way that leaves me feeling confident that the Product Owner will deliver the best product within the parameters and leaving me confident that this decision is right even if it is not what I initially wanted.  The Product Owner should be able to convey the implications of saying ‘Yes’ so that I understand why I am being told No.  A great Product Owner has any number of tools that can help people see this and yet we regularly see backlogs full of feature requests that will never see the light of day because the PO doesn’t feel capable or sufficiently empowered to say NO!

no

But the PO must also communicate with the development team, they must understand technical development terms, to have a grasp of the technical implementation, even if they do not have authority over the ‘How’ I’d expect them to have a vested interest in understanding it.  They also need to be able to communicate the business needs and the business terms in a meaningful way to the development team, This requires a versatility in speech and communication that is unusual to say the least.  Being respected and understood by both the business and the technical team is a major feat, and as we all know any cloistered group speaks in three letter acronyms that only they understand and the audible sign when they have to explain to an unlearned outsider can demoralize the best of us.  Do not underestimate this ability.

But there is more, they need the creativity to communicate design ideas or if the ideas come from others the scope to understand that creativity, to imagine what could be and express that to the business and to the technical team.  And then we get into the really tricky realm of the stakeholders as opposed to the users, this generally is the group that funds the product, they want to see progress, they want to see good stewardship of their investment, they may ask for forecasts and may even press for commitments.

We have now loaded our Product Owner with the need to communicate with senior people that make financial decisions, to express Risk and Forecasts in a manner that it concise but meaningful, we want to be transparent and informative, but confident.  If we are using forecasts especially mathematical forecasts we had better understand them and be able to back them up with explanation and confidence.  A Product Owner my stand their ground in the face of authority and speak truth to power. A Product Owner that makes unrealistic commitments or promises, will lose the confidence of her team and her stakeholders in a flash.

If a Product is to be sold it is likely that you will need to be involved in Sales and Marketing, which brings a whole host of other skills and communication issues to bear, understanding the implication to the market, and how you measure that and how you engage with that is a new realm of understanding and confusion.

A great Product Owner is a master communicator, they have an insatiable desire for knowledge, to understand and be understood.

Summary

As you can see the skill set of a great Product Owner is monumental, and yet the good ones make it look easy.  If you have a mindset suited to Product Ownership it is likely you already have good communication skills and enjoy learning more domains.

It is likely you are the sort of person that thrives on the delivery of a product and revels in the feedback, enjoying the flexibility and change, is unmoved at the thought of redoing something twice or even more to get it right.

Solving problem is a thrill and being able to see beyond the obvious and draw out information from users and then present something back is a joy.

That doesn’t mean it isn’t incredibly difficult, overwhelming at times and sadly unappreciated, and very often underpaid.

At some point the industry dismissed all these skills as unimportant and we see a flurry of Product Owners that write stories exactly as dictated by users, that input data into forecasting tools without the vaguest notion of what the forecasts mean or how they are calculated.

As I said at the start a great Product Owner is the lynchpin of a great Product, we should be seeking them out and rewarding them appropriately, you will be amazed at what can be achieved with the right person in that role.

 

 

Advertisements

Never talk about politics!

I grew up in the UK but I have lived in the USA for a little over 6 years in total, which equates to around a quarter of my working life, so whilst I still feel very British there is an element of the mid-Atlantic creeping in. That is to say I feel like I have grown a level of understanding for some of the quirks of American culture and am a little more sympathetic to the perception of the UK culture from the American side of the pond.

us-uk-flags-union-english-18622380

However being so overtly British I get to hear the same questions repeatedly and some of the misinformation is a little troubling at times.  Especially when it can be fact checked so easily.  Since this is my soapbox I’ll indulge a little before I get on to the topic at hand.

First the USA did not win the war of 1812 please take 5 minutes to read wikipedia.  Second, the UK NHS: I have been in the USA for 6 years and in that time I have worked for two employers both of whom tell me that the health insurance they provide is the best there is. My colleagues tell me it is better than anywhere else they have ever worked. I have no reason to doubt that this is great Health Insurance, and apparently it costs around $27,000 per year – mostly paid by my employer and that is in addition to the social security deductions which are approximately 8% of my paycheque.

In my experience the quality of service offered by the ‘best‘ Health Insurance is approximately identical in quality of healthcare to that received from the NHS. Yep you heard me, I find no discernible difference in quality of care.  There are certainly differences, I have to pay a co-pay to see my Doctor here in the US which is free in the UK.  Doctors in the USA want to push you to take every test under the sun so they can bill the insurance, where in the UK they assess if there is a need first. In the USA if there is a referral it is on you, whereas in the UK your doctor would follow-up. The Doctors’ surgeries here seem to be a bit more lavish and they need an army of staff to administer the insurance bureaucracy but as far as wait times, quality of medical treatment and accessibility of treatment I see no difference.

So I do get a little upset when I say people describing the UK medical system as having poor treatment and long wait times and something to generally be afraid of.  Think of it as having the best medical insurance you can buy, and then imagine that it is free to you, I can see why that is so incomprehensible when you are used to spending nearly $30,000 per year on that service. I am sorry to say it so bluntly, but the USA spends on average 4 times as much for what is very much an inferior system for most people.

Okay I’m off-my NHS soap box now.

Capitalism or Socialism concept

But the third and most troubling perception that I am regularly confronted with is the notion that the UK is a ‘Socialist‘ country and the USA is a ‘Capitalist‘ country.  This notion troubled me a lot and got me thinking, but first let’s clarify the definitions:

Socialism:   political and economic theory of social organization that advocates that the means of production, distribution, and exchange should be owned or regulated by the community as a whole.     

Capitalism:  an economic and political system in which a country’s trade and industry are controlled by private owners for profit, rather than by the state.

Essentially the extent to which you are a capitalist or socialist country is determined by the extent to which the government interferes with the free market, either through spending or through legislation.

Measuring Capitalism

Spending is pretty easy to assess as we can see what proportion of GDP comes from government spending and how much from ‘the free market’  However, legislation is much harder to measure and by definition any intervention in the market is ‘socialist’.  E.g. Defence, immigration, policing, taxation, tariffs, subsidies, etc.

I think most people realize that pure socialism is fatally flawed and equally flawed is pure capitalism, so it is really a question of how little or how much government is needed and how much can the market provide on it’s own. We all have a reasonable expectation that infrastructure, defense, police, jails etc cannot be provided by the market and that the whole country benefits from education and healthcare for the poor as the benefits are far reaching to the economy but how much of the rest is open to debate.

Let’s take the USA, the US spends a staggering 35% of it’s GDP on socialist activities, that is more than a third, and is incredibly socialist in it’s government policies and legislation, just recently there have been some very high profile trade tariffs, a trade tariff is direct manipulation of the free market by the government – it is the very definition of socialism. Lobby groups regularly persuade the government to invest in particular parts of the country or legislate for the benefit of certain industries.  Both the UK and the USA bailed out banks and the USA bailed out the car industry and corn farmers.

By contrast the UK spends 41% of it’s GDP on socialist activities, and also heavily regulates the free-market with employment laws, they provide tax-breaks for entrepreneurs and subsidies for ‘green’ businesses to name a few, but notably didn’t bail out the car industry or steel industry or mining industry.

51c8d01b2deda.image

In my anecdotal experience and to be clear this is opinion based on only very limited education in Economics and Politics, neither the UK nor the USA has any claim on being capitalist countries,  both may claim to be slightly right of center but are both squarely ‘Mixed economies’ and have found a balance that is slightly further from Socialism than Capitalism but not by much. And whilst the UK spends more, my observance is that the USA regulates more and is far more interventionist in investing, bailing-out, propping up and otherwise supporting USA based industries.

TL:DR Summary: 

The UK and USA are broadly similar in terms of the degree to which they are Socialist or Capitalist in practical terms, but in my observation the UK is more willing to intervene for the benefit of the people – especially the poorer and the USA is more likely to intervene for the benefit of business.

What has this to do with Agile?

So what does that have to do with Agile?  Well it strikes me that there are a great many parallels.  If we equate Socialism – a planning heavy form of governance, where plans are made by a few experts:- with ‘Waterfall’  and  Capitalism – a responsive form of governance where the market leads and the many respond independently of governance:- with Agile,  then maybe you can see where I am headed.

download (2)

In small scale both Waterfall and Agile succeed, but as we scale both suffer in different ways.  In Waterfall as in Socialism the planners become further removed from the market they are serving and are less responsive to particular needs and more and more out of touch.  a great deal of overhead is needed to align the vision from the top and unsurprisingly they are often so far removed they get it wrong, corruption sets in and effectiveness (the true productivity) plummets.

By contrast in Agile as in Capitalism works very well in small scale but as we grow the decision makers are not able to see the big picture and whilst they are responsive to what they can see, they fail to see the larger system and optimize for themselves rather than the larger organization and problems set in with misalignment. There are some aspects of a business that simply don’t work by being responsive and need to be planned and organized.

Governance

So where does that leave us?  Well at heart I am both a capitalist and an Agilist so I am biased, but the way I see it as we scale with Agile and in business in general we discover that we need governance, some degree of consistency, infrastructure and support and most of all a clear direction.  But I believe we should keep that governance as small as practical and only govern that which we cannot govern ourselves.

In the case of big government I believe that includes socialised healthcare because normal market forces do not apply when it comes to our health and so the market cannot effectively provide what we need, I also believe that we should invest heavily in socialised education as better educated workers make everyone wealthier.

When it comes to Agile teams I don’t think the teams should do the hiring or decide pay and they don’t generally want or need to be bothered with administration or infrastructure, I feel that is governance that they should be spared, similarly I think ‘health care’ such as vacation, benefits, and support (HR) is governance. Start-ups will need to deal with all of this but at scale we shouldn’t have to.  Nothing controversial so far, but where we may start to see differences of opinion is the level of governance needed for teams.

In my opinion we achieve the best results from small teams, that are given clear direction and are empowered and enabled, that means direction not a director, so team leaders, project managers or any other similar role is bad for teams, it is unnecessary governance and is in my opinion fundamentally anti-agile.

Build projects around motivated individuals. 
Give them the environment and support they need, 
and trust them to get the job done.

The best architectures, requirements, and designs 
emerge from self-organizing teams.

That doesn’t mean we don’t need managers or leaders, but we don’t need them involved in the work.  In Scrum we empower Product Owners to set direction and priorities but they stay out of the HOW, we empower Scrum Masters to coach us on process and guide us on improving flow, we even empower them to remove impediments on our behalf but we do not empower them to tell us HOW to do the job.  In my opinion Project Managers (when they are deemed necessary) should respond to information provided by the team and not the other way round, they are a consumer of information only! They should convey no authority.

12625104-no-managers

Where we need managers is NOT for doing the work, a suitably cross-functional team should be able to do that without an anointed leader.  What we need managers for is the ability to create those cross functional teams, and do this by listening to what is needed, hiring and enabling the forming of those teams.  We need leadership to provide clarity of direction, clarity of culture and clarity of values. We need managers to help us by enabling us grow as individuals in our individual careers in parallel to our goals for the team. We need managers for ensuring that we as an organisation are planning for the future so we can focus on delivering in the present.

If you feel you need a manager to manage the team doing the work then in my opinion you have failed elsewhere, it is a sticking plaster to a bigger problem, all you are doing by instilling team leaders/Project managers or team managers on a delivery team is masking a bigger problem elsewhere, possibly in hiring, training, education or communication.

The prime role of leadership is ensuring clarity, they have the big picture, making sure their employees see it too should be their number one goal, any other governance in the day to day job is an unnecessary overhead and a smell that there are problems elsewhere. The corruption inherent in larger systems needs to be cut out at the source not covered up with a layer of management. If you are hiring the wrong people then fix your hiring process, don’t hire people to manage problem staff. If you are struggling with consistency or maintaining values then it is an issue for education and clarity, putting a manager on as team is not the solution: enforcing values is not the same as instilling values.

90ee2b65615c3fda2b2c4190697c34d4

In Agile, like Capitalism, we want government to be as small as possible and only get involved in things that we either can’t do ourselves or are necessary but unrelated to our day to day work. Unnecessary bureaucracy and governance are well, unnecessary.

Give them the environment and support they need, and trust them to get the job done.

Hire the right people and let us do our job, educate don’t regulate, enable don’t enforce,  but most of all trust us, don’t try to control us. Set a direction, then get out of our way.

 

 

Who is interviewing who?

How I’d like to do it.

My advice would be to concentrate first and foremost on creating a place where people would want to work, then marketing your organisation to the candidate, they should really want to work for your company, that way you start with a better candidate pool, immediately giving you a better chance of finding the best employees.

Then – even if it feels impersonal, a series of consistent structured tests (IQ and Psychometric) and then formal structured interview questions where the results and responses are noted and then referred onto an independent panel for a decision on hiring. Forget the gut-feel, forget the technical questions, forget hostile interview techniques, they really don’t work. Throughout all this ensure the candidates are treated well and made to feel important.

Sounds like hard work, it sounds like it undermines the hiring manager, it sounds incredibly time-consuming and bureaucratic, perhaps even expensive. But if your goal is to consistently hire good quality candidates it is going to be hard work and you will have to accept that there are some things that cannot be effectively and consistently assessed in an interview situation.

My final thought is that if you have got your hiring right, it is very likely that the most capable, most experienced and most reliable person for a role is the one currently in it. Don’t lose them.  Look after good employees they are your company’s most valuable asset.  Treat them well and do whatever it takes to keep them.

recruitment tips

And next time you are in an interview situation, ask yourself who is interviewing who?

Typical interview styles

The interview itself.

What I have observed is that interviewing is generally composed of one or more of a very small number of techniques:

  1.  Free-form, gut-feel unstructured or semi-structured chat and questions between candidate and hiring manager.

  2.  More formal pre-defined questions structured and consistently asked to all candidates.

  3.  Some variety of standardised test, essentially IQ based.

  4.  Questions posed by a technical expert with a desire to highlight his superiority rather than assess your capability.

  5.  A technical test or series of technical questions intended to be pragmatic and fair.

  6.  Aggressive panel questioning

  7.  Psychometric testing: verbal/numeric/diagrammatic reasoning or personality tests.

  8.  Presentation by interviewer on why the candidate should work for you.

There are studies and statistics that rank the effectiveness of the different techniques for selecting good candidates, I won’t pour them out here – I am not an expert and I’d just embarrass myself. But in my experience 1 is the most common, often combined with 4 or 5. But logic states that 4 is a waste of time and puts off candidates, and studies show that 1 and 5 are actually very, very poor indicators of ability and capability for the role and do not result in long-term success.

So what works? 

2, 3 and 7 are by far a better method of assessing candidates, followed by an independent panel-decision based on the documented evidence taken from the interviews – the interviewer should not be allowed to make the decision independently as they display bias (subconscious or otherwise).

But 2, 3 and 7 are hard, it requires yet more work on what is already a tough and time-consuming process, so very rarely gets done.

The reciprocal nature of an interview (8) is so often overlooked, if you want the best people and you want to get the best out of them, then not only do you need to decide if they are right for you, you need to convince them that your business/team is right for them. You should be putting as much effort in to impressing candidates as they put into impressing you. You are competing for them in a buoyant market.

recruitment2

Doing it right.

As an interviewer, my best experience has been for a company that did a combination of 2, 3, 7 and 5. We put a lot of effort into interviewing, but the majority of people still failed the combination of tests, especially the technical test. The test felt ‘easy’ to us and some candidates did well, but the results didn’t match the apparent skills of candidates, in hindsight I think it confused the process. The problem is that technical tests are not effective at assessing ability during an interview, there are simply so many other factors at play.

Relying on structured questions, IQ tests and psychometric tests may feel clinical and impersonal, but very likely the best way to find the right candidate. But ego plays a role and when hiring for a team, we are only human and so many hiring managers want to rely on their own instinct, even if evidence demonstrates this is unreliable, so it is hardly a surprise that many hiring managers favour their instinct over a structured process.

What makes a good interview?

My experience of recruitment is largely anecdotal, I am not a professional interviewer or HR expert. My limited experience of interviewing has been as a candidate, a hiring manager, or sometimes even as a subject expert. I’d estimate that over my career my experience is approximately 8:1 in favour of being an interviewer over being an interviewee, but I have been on both sides of the table often enough to know how it feels from either perspective. 

Over the last 5 or so years the amount of effort I have put into recruitment has been considerable, especially considering it is not really meant to be a significant part of my role. I’d estimate that I have hired an average of one person ever 2 months or so.   I even like to think I am pretty good at it,  although as you will see I am probably mistaken in that opinion.

What is striking though is how much time this takes, very anecdotally I’d estimate that depending on the quality of the CVs that I receive, on average only 5% will make it through the screening and interviewing to getting an offer(probably less). But the 95% that get rejected still consume a lot of time, and of the 5% selected we don’t always get it right, and I’m pretty sure quite a few good candidates get missed. The process is far from ideal.

recruitment

But what makes for a good interview?

As a candidate I have had interviews lasting less than 15 minutes (where I was offered) and interviews spanning 3 days, for a graduate recruitment programme, and just about everything in between. I have had good experiences and bad.

Some, in fact most interviewers seem to forget that the candidate is also interviewing them, and that the candidate is deciding if they want to work with you in the same way you are assessing them – it is not a one way decision by any stretch. Such is the lack of understanding and sheer arrogance of some that I have been asked extremely obscure technical questions that provide no clear value, I have been challenged(insulted) to gauge my response, I have had panel of interviewers quick-firing questions and had interviewers who were clearly reading my CV for the first time during the interview.  Why would any good candidate have any desire to work for you after an interview like that?

I haven’t kept accurate records, and I appreciate this is anecdotal but I’d estimate I have turned down close to three job offers for every one I have accepted over my career. Now I am well aware that I am fortunate to have in-demand skills at a time when the market is booming, I have also had a lot of rejection.  Similarly, as a hiring manager I’ve had too many candidates turn down offers, or more frustrating get a better offer before we could complete the hiring process.

The hiring process is so expensive and so important I am surprised at how often it is treated in a cavalier manner.   Why oh why would you be so arrogant to treat candidates with anything less than the respect you would expect them to show you?

To be the best, hire the best… for you.

I have recently been reflecting on the impact of our choices when hiring new staff. Over the last few years hiring has been a major activity for me, and so I am particularly interested in what the impact of these hiring decisions has on the team and the organisation.

I have a number of experiences that I feel are relevant and two particular opinions I have recently heard that I would like to discuss.

The first was from a blog post: http://zachholman.com/posts/0x-engineers/   in this the author is critical of everyone chasing after the type ‘A’ engineer, it makes an interesting read and refers to a popular belief that the good software engineers are worth 10x as much as the ‘average’ engineer.  I don’t intend to get into the basis or accuracy of the claims, but I am satisfied that it is a generally well accepted opinion that there is a significant difference in ability, and value of output between those deemed average and the top end of the scale, I have heard figures ranging from 10x as valuable to 1000x as valuable from quite well respected authors.

But ultimately the author compares software engineers to restaurants and concludes that most of the time he would be content with an average restaurant as we can’t always all eat in the best restaurants.  This is the point where I try hard not to be dismissive. The analogy is suggesting that most of us are content with ‘Good’ food and don’t need ‘Great food’ but the reality is that we are not only comparing quality, we are comparing relative quantity AND quantity, if we use his 10x value estimate then what we are comparing is a 1/10th of a ‘Good’ meal to a whole ‘Great meal’  We’d need to eat (and pay for) 10 ‘Good’ meals to get the same quantity/quality (value) of food.

He does have some good points about a good team being better than a star player and I’ll come back to that but I for one am not content with a tenth of a meal.

By contrast I looked at Work Rules! by Laszlo Bock (SVP People Operations at Google)

Lessons from WORK RULES! include:

* Take away managers’ power over employees
* Only hire people who are smarter than you are, no matter how long it takes to find them
* Pay unfairly (it’s more fair!)
* Default to open: be transparent, and welcome feedback
* If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

Laszlo advocates hiring only the best, by hiring the best you get the best output, you certainly have to pay more but you don’t have to pay 10x the salary to get a 10x software engineer, it makes financial and practical sense, a small team of high achievers must be amazing and they clearly are for Google. But…

Here is where the real word kicks in.  Most of us don’t work for Google or Apple, we will not attract the best of the best, most organisations are unable to employ an entire team of 10x engineers, many of us are lucky to hire a few high achievers, when location, salary, benefits, and image are factored in, we can be selective and choose the best of what is available to us, but a good engineer is hard to find.

So I am saying that I don’t want a team where the primary qualification is a pulse, and I am highly unlikely to be able to hire (and retain) an organisation full of 10x engineers.  My world is the grey area somewhere between.

This brings me to what has been an inevitable consequence of the real world – a mixed team.  I didn’t like the restaurant analogy so I will go with cars.

cars

Lets say I have a team of five developers, as a very general rule a team will travel at the pace of the slowest member, and whilst you may be able to improve the speed of the slowest a little, the high performers are stuck at the slowest speed and may well be getting bored and frustrated.  It is no good one or two members zooming-off, knowledge doesn’t get shared resentment grows and very quickly you are at a standstill with a dysfunctional team. An effective team moves at one pace – the pace of the team, and as the original blogger wrote, a team that works well together can actually be far more effective than a single star player.

And this is where things get more messy, as either a Scrum Master or a Department Manager the goal is the long-term development of the team, I value all the team and I’d like to see everyone have the opportunity to develop and get better, a single star-player held back is bad, I don’t want to see that, but equally I am aware that an effective team can be amazing, and then again a dysfunctional team is a disaster. I want to grow and build a team that are greater than the sum of their parts not a group of individuals moving at the pace of the slowest.

So I find myself both agreeing and disagreeing with Laszlo, yes I want a group of the best engineers, but that isn’t going to happen, I don’t live in silicon valley and I don’t have that budget, and even if I did then I’d still prefer a great team of engineers. I believe that a team working well together can achieve far more and far better software than even ’10x’ individuals.

I aim to get that by hiring for the team. I will still aim to hire a team where they are smarter than me if I can but my primary goal is to find someone good that will enhance the existing team, that means I value the ability to communicate over their technical depth, I value their willingness to learn and to question over their certainty of their own knowledge, I value a desire to give customers what they want over a desire for a perfectly engineered solution. I suppose I am saying I value the team over individuals – even star players.

But I have a dark side too, anyone that is holding the team back needs to go, whether they are disruptive or not pulling their weight or simply because they don’t mix well with the others. I think we should be aggressive in hiring the best people for the team but equally aggressive in removing obstacles whatever form they take even if it means changing the make-up of the team.

I don’t want to close before addressing the other items on Laszlo’s list.  I want to voice my agreement over the other points,

* Take away managers’ power over employees

It really makes no sense to hire smart people and then tell them what to do, we hire smart people because they know more than us in their area of expertise – Let them use it!

* Only hire people who are smarter than you are, no matter how long it takes to find them

I agree with the caveat mentioned above, we don’t all have that luxury and for the most part it depends heavily on the next point.

* Pay unfairly (it’s more fair!)

Double what you are willing to pay and be selective. But don’t stop there! Retention is as important as recruitment, don’t lose someone good by being stingy, if you discover you have hired a star, give them a pay raise immediately, I can guarantee that when they go it will be for only 5%-10% more than you currently pay – don’t let that happen and offering to ‘match’ after they have one foot out of the door is far far too late. Let them know you value them now and make it hard for a competitor to lure them away.  Don’t worry if it upsets other people, if they know that reward is based on ability and performance they will respect it even if they don’t like it.

* Default to open: be transparent, and welcome feedback

I am a huge believer in transparency in development, so many projects fail because problems were hidden ignored or deferred or where customers were excluded until it was too late and too costly to change. Be honest and open and learn to see that finding a problem early is a good thing, even if you’d prefer not to hear it.

 * If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

This goes with the first point but let the team lead the way, they likely do know best, and make work a place they want to be, if a team of engineers is happy and enthusiastic you will see an amazing improvement. And trust them.

Trust the team

I shall add that as my own piece of advice for success with software development.  Trust the team, trust their judgement, trust their opinions, trust their concerns and trust that they will do the right thing. In my experience a good team will reward that trust ten-fold.

In my opinion if you cannot Trust your development team it is a failure of management as you have hired the wrong people.