14 AUG 08
Featured Articles & Posts | Razume.com - Your Resume Review Community
The wisdom of the crowds applied to resumes
TAGS
• resume
• recruiting
• crowds
Recruiting Costs: A Manager’s Opportunity : ERE.net
How to manage costs in a recruiting department:
TAGS
• recruiting
• metrics
• economics
• finance
• rpo
Paylily - hybrid timesheets
A product for managing timesheets (paper, online review, approvals, …)
• tempstaffing
• recruiting
• temp
13 AUG 08
The Most Important Service Level Agreement : ERE.net
An important point in the hiring manager/recruiter relationship

The Software fauna is made of several species. Most of the time those species coexist peacefully. Sometimes they even collaborate. But also sometimes they fight for the same piece of territory.

That’s the feeling I had while re-reading “The Inmates Are Running the Asylum” by Alan Cooper. It triggered a series of thoughts (that translate into a series of posts). This post is part of this series.

The Need for Blueprints

In the first part of his book, Cooper analyzes the issues in the development process. Among them is the fact that “Without blueprints, software builders don’t really have a firm grasp on what makes the product “done”". Of course, in Cooper’s world designers are coming at the rescue and provide this blueprint.

There is a great truth in there: without blueprints the whole process is in big trouble. However, it seems Cooper forgets that software development is a sports team. There is not ONE blueprint in a project, but several, as for construction by the way. The blueprint for the infrastructure of a building is not the same as for the electrical wiring. Same thing in software: you will have a technical blueprint (often called software architecture), a functional blueprint(sometimes called product architecture), an interaction blueprint (the one provided by designers) and a business blueprint (provided by product management). If any of these blueprints is missing, you’re in serious trouble. Not for the same reasons, but in serious trouble still.
Truth be told , when Cooper wrote his book, interaction blueprint was largely ignored and that’s what triggered his writing. Still, design is not everything. It is important. It is crucial. But it is not everything.

Who Owns Desirability?

Cooper is very clear in his answer to this question: designers. (see Chapter 5)

Here again, Cooper is making complete abstraction of the fact that software is a team sport. He prefers to see it as “designers rule” (or should rule).

In my previous post on desirability, I present desirability as a combination of 3 elements: features, usability, and sexiness. Well, designers certainly own parts of this, but not all 3:

• Goals and Features typically come from Product Management. They are the ones who understand the needs of the buyers and users of the product. They have done market research, discussed with many customers to understand what challenges they are facing, and then picked the ones they will address with the product.
• Usability is squarely in the realm of interaction designers or HCI experts (Human-Computer Interface). They are the ones who understand the cognitive challenges associated with using a computerized solution. They are the ones who have this unique set of skills that can translate the goals identified by product management into user interactions, and a user interface that fulfill these goals.
• Sexiness is shared between marketers, graphic artists and interaction designers. Graphic artists will know how to add that pizzazz to a well-crafted interaction. Marketers will know how to emphasize a particular “pizzazzed” interaction so to put the focus of the buyer/user on it.

What makes a product desirable? Desirable as “I want to buy it and to use it”.

As I mentioned, re-reading “The Inmates Are Running the Asylum” by Alan Cooper triggered a series of thoughts (that translate into a series of posts). This post is part of this series.

While Cooper focuses mostly on usability, what really makes a product desirable actually goes along 3 dimensions:

• The features that are supported by the product
• The usability of the application
• The “sexiness” of the user interface

Remove one and you’re losing some level of desirability.

Ex-SAP Now-Gartner’s Thomas Otter also has a very interesting post on a related topic. In Chess, Design and Software, he starts from designing Chess pieces and derives from there the characteristics of good software. Comments in brackets are mine.

These are good principles for software.
1. A purpose [incorporated into features]
2- easy to use, lots of unobtrusive clues [usability]
3. stable
4. repeatable. (more industry, less craft)
5. great look and feel [sexiness]
6. work well with others
7. A means to an end [incorporated into features]

Features

Features are what users employ to use the application. Features allow users to achieve their goals. That’s their only raison d’etre. That should be their only reason d’etre.

The reality is that often we (solution providers) tend to add features because of plenty different reasons (in no particular order):

• the competitor has it
• the customer (sometimes the user) asks for it.
• marketing dreamed about it
• engineering invented it
• management had an epiphany
• ….
• it helps the user achieve her goal

Yes, the latter is only one of many reasons why we add a feature, while it should be the main one. All other reasons are secondary and should be “cherries on the sundae” and add to the goal-achievement one.

When you add a feature that does not help the user, you are merely decreasing the desirability of your product/solution. As Cooper mentions in his book: “Product successes and failures have shown repeatedly that users don’t care that much about features. Users only care about reaching their goals. Sometimes features are needed to reach goals, but more often than not, they merely confuse users”. For Cooper, less is more.

What Cooper doesn’t mention though is that if you fail to add the feature that will complete a goal, you just decreased the desirability of your product in the same manner as if you add an unnecessary one. So less is not always more.

Usability

When we talk about usability, what we mean is that it is easy to interact with the application.

A product is easy to use if it follows what the user wants to do. In Cooper’s terms that means it follows the users goals. In software modeling methodology’s term that means being use-case driven (as intended initially by Jacobson). In Pragmatic Marketing’s terms, that means defining use scenarios.

Many products out there are more driven by tasks than by goals and that’s what creates usability issues.

Additional to goal-driven design, Cooper presents a set of qualities that interaction designers will develop in the design of interactions. These qualities are grouped under the term “politeness”. What is software politeness? Well it’s fully described in the book that I encourage you to buy.

Sexiness

The Sexiness I am referring to materializes mostly into the user interface.

This is the part that attracts us, that the user emotionally connects with. This is the “cool” factor (although arguably good PR can also accounts for that as can be seen here). This is why we all want an iPhone, even if we haven’t even touched it yet.

There is no doubt sexiness is a key element in the success of consumer software. However, I am living in the world of enterprise software and until recently sexiness had only one meaning: vaporware (or smoke-and-mirrors, or slideware, or…).

Enterprise software is serious. Sexiness is not serious. If it is sexy it is either 1) a consumer application or 2) an application that has so little features it needs to cover it with an attractive UI.
This thinking was true for software providers. It was true also for enterprise buyers and users.

With the coming of Web 2.0, consumer users started to get used to sexiness in software and they also started to bring their new habit -and their new expectations- in the office.
This is leading many software providers to rethink their practice and integrate better design in their applications.

There has been a lot of discussions in my space (HCM: Human Capital Management aka the less sexy Human Resource) recently on that topic. Here are a few of them: here, here, here, here, here, and here.

The argument I agree the most with comes, as often, from SystematicHR (emphasis mine).

there are good reasons to want a sexy UI, assuming that all is well behind the scenes in terms of functionality and technology.  First, a very sexy UI will create a desire in end users to try and use the product.  If the UI is engineered well to actually make the lives of the end user easier, then not only will initial adoption be higher, but long term adoption will also be better.  All technology is about adoption. [...] I also want users in the HR apps.  Sexy might be the best way of doing that.

He’s right on: It’s all about adoption. And sexiness is needed to get there.

I just re-read a classic of Product Management, UI design, and Software development books. The book titled “The Inmates are running the asylum” by Alan Cooper describes how the process we use to create software is flawed and how user-interface and interaction design is in the hands of developers while it should be in the hands of … designers of course.

Re-reading it after several years triggered a few thoughts that I will develop in separate posts:

• Desirability
• Designers vs. the rest of the world
• to BDUF or not to BDUF
• Process over People

In the meantime here are a few miscellaneous ones:

• If you’re married to -or have a friend who is- a software developer/architect/… and you have trouble understanding him/her, go buy the book and read it. Or if you are a software developer/architect/…, go buy it for your spouse.
  Cooper has an entire section on how software guys are different from the rest of the world.
  Once I have finished with my blog posts I will pass the book to my wife with the tiny hope that maybe she will finally understand me! (one can still dream, can’t he?)
• The concept of cognitive friction is something that anyone involved in the development of software should be aware of.
  In a nutshell, cognitive friction is ” the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes. Software interaction is very high in cognitive friction”
• Prototypes are prototypes. They are not a platform to build a product. They are a learning exercise. They have value.
• Keeley’s three qualities of software applications (described in Chapter 5) are very powerful to understand the different perspectives that need to be considered by a product manager for an application to be successful:
  • Capability: Can we build it?
  • Viability: Is there a business case? Will this be profitable?
  • Desirability: Does it fill a need? Are there users who will want that product?
• You can get customers with a product that lacks desirability provided your customers need the functionality you built and there is no alternative.
  But at the moment a competitor enters your market with a product that fulfill the needs and is desirable, your customers will switch providers as soon as they can.
• It’s extremely difficult to add desirability to a product. Putting lipstick on a pig does not make it more desirable.
• When designing an application focus on daily-use scenarios. Edge cases can be handled at development time. Even if they are not desirable they won’t impact the success or failure of the product.

It is a strange feeling to read a book -especially a good one- and see -or rather read- you are the centre of the discussion. Well, not exactly you. But a generic you. Or rather an entire class of generic-you.

This is what happened to me while reading Richard Florida’s groundbreaking book, “the Rise of the Creative Class”.

Why groundbreaking?

1. This book triggered debates in about every city in the US among the planners and politicians looking at developing or reviving their city.
2. This book describes the rise of a new class from a sociologic and economic perspectives, along with its impacts on the way we work, the way we entertain, and the way we should build our cities.

Why did I read myself?

• Thriving for challenges and exciting projects
  Oh Yes. Check
• Workaholic (40 % of Americans are)
  Check (Alas!). Probably goes with the love for challenges and exciting projects.
• Diversity and difference are must.
  Check. I would add diversity in races, in experiences, in backgrounds
• Character
  Check. We don’t like cookie-cutters. Probably goes with the requirement for diversity
• Talent is what attract us
  Check. When looking at a position or a project, who we will be working with matters a lot.
• Peer-recognition
  Check. Sometimes, it matters as much as money (if not more)
• Always looking for for learning and growth opportunities.
  Check

Look familiar? Go buy the book and have this unique feeling of seeing you as the hero of story.

Florida describes in great extent what is creativity, what is the creative economy and what is the creative class. I won’t repeat it here. To start with much has been written/blogged on that topic. Also it’s really worth reading the book in its entirety on this topic.

Florida also describes how this creativity impacts our life and the cities we choose to live in. Florida’s background is in public policy so the focus of his book is on how it affects the cities. He also provides a ranking of American cities.
I won’t blog on this part either.

What I will blog on though is how this affects work, employment and careers.

On top of what I wrote on why I pictured myself while reading the book here are a few other points:

• Environment is very important
  Whether we talk about the city, the neighbourhood, the office space, the creative class looks for stimulating and creative environments.
  In the workspace that translates into an open office design that is traffic-oriented and conceived to ease the flow of people and ideas, and a lot of communal spaces where you can hang out.
  It’s also an environment that stimulates through art, color design, and events and experiences.
  It’s an environment where there is not one dress code but rather a diversity of them.
• Individuals own their job
  People identify themselves with a profession rather than a company.
  People take charge of their career. They are the ones who plan their job or career moves. Those moves won’t necessarily be so to climb the corporate ladder. Increasingly, members of the creative class are looking for horizontal moves. Thus they can fulfill their taste for challenges and for learning.
  They are also the ones who take care of their education and skill acquisition. People spend increasingly more time reading, learning by themselves on their own time, and with their own money.
• Attitude towards work
  Members of the Creative Class requires flexibility in their schedule. For one, they want work-life balance, but also their life and their work are intertwined. They live during work hours and work after-hours.
  They do not take orders very well. They generally manage themselves pretty well and are more sensitive to peer pressure than hierarchical one. They don’t like orders but they like directions. Managing a creative requires more soft control than command.

My son is bright. Maybe even gifted. That’s on top of being beautiful, an excellent swimmer, very mature, and filthy rich in Webkinz’s world!

And he’s on a path for failure! Yes, he’s about to turn 8 and is already on a path that is leading him to become a drop-out at school.

How did we get there?

Let’s start by the preliminaries. Yes, I’m a proud father. No I don’t think my sons are the 8th and 9th Wonders of the world (well I do, but I do not brag about it). I am saying he’s bright because we are in the process of testing him. He’s now in Grade 2 and is at least at a Grade 7 level in Mathematics, and way above his level in English (not to mention he also speaks French and Japanese).

Until this year, every year we receive praises on his work and abilities from his teachers; at least half of his marks were “EXCEED EXPECTATIONS”.

This year things changed. He barely gets “MEET EXPECTATIONS” and we start to have comments like he’s behaving like a clown to entertain his friends and look cool.

At home he went from running to make his homework to not bringing back his homework at all.

The main reason for all this is that he’s bored! And because he’s bored he’s no more engaged.

Now you see where I’m going! (I hope so)

If you look at employees or colleagues who are not the stars in your company, how many of them are actually not challenged enough? Obviously it’s a difficult question to answer, but if you’re a a manager, are you taking the required  steps for identifying the untapped talent in your team? Are you providing enough challenges or just giving tasks to perform?

Even worse, are you transforming your A players into shadows of themselves (or pushing them to the competition) by slowly asphyxiating them with boredom?

That won’t work for everyone of course. Some B players are real B players. But can you afford not to wake up the talent hidden in the “B-player-in-a-A-player-body” (or is it the other way around)?

I like Philosophy. Maybe because I’m French and this is something we are taught to appreciate. Maybe because it forces us to analyze something we fail to notice or to understand, or brings a different light on something we think we know.

So, I read Philosophy books from time to time. One author I appreciate a lot at the moment is Alain de Botton, who, despite his name, is not French. The book is titled “Status Anxiety” and, as the cover describes is “about an almost universal anxiety that rarely gets mentioned directly: an anxiety about what others think of us, about whether we’re judged a success or a failure, a winner or a loser. This is a book about status anxiety”.

So what does it has to do with a blog that mainly talks about collaboration, interoperability, talent management, product management, and software?

Well, it happens that some of the causes of this status anxiety are work-related.

Meritocracy

Over the past centuries, and even more in the past few years, we have been increasingly living in a meritocracy. For instance one of the top HR exec has named his blog Meritocracy.net. To no surprise, he is now working at Google the poster child of the new economy.

In a meritocracy, each individual rips the level of benefits s/he deserves based on her work or her talent, i.e. based on merit.

de Botton sees 3 stories emerging from this trend

• the rich are the useful ones, not the poor
  Replace “rich” with “talented” and you understand how it relates to this blog.
  This is something we are seeing a lot in the HR space for the last decade. It has even created a new space/industry: talent management. I won’t comment in more details; there are enough stories out there on why talent matters in the enterprise world
• Status does have moral connotations
  Throughout the course of history, status has had wealth and power connotations but not so much moral ones. At least nothing like a scale (the higher your status, the better person you are). There were some philosophies where the rich were considered sinful and corrupt (think Karl Marx), but no direct correlation between wealth and status.
  “In a meritocratic world in which prestigious and well-paid jobs could be secured only through native intelligence and ability, money began to look like a sound signifier of character. The rich were not only wealthier it seems; they might also be plain better.”
  There has been a lot of discussions on the web on online reputation or Reputation 2.0 which in my opinion is along the same line as de Botton’s status
  The fact is that is everything around Web 2.0 has dramatically emphasized and accelerated this trend. Top analyst firms are losing ground and individual contributors are gaining weight in their capacity to influence based on this status. Sites like TechCrunch have built momentum based on the status of the contributors which is based on how good these contributors are.
  Similarly bad products with high marketing do not sell as well as they used to because consumers are more sensitive -and more aware- to the actual quality of a product. Lower quality products (whatever that means) have bad -or low- status on the web and that results in lower sales. iPod design is better than the competition, hence its status, hence its blockbuster sale numbers.
• The poor are sinful and corrupt and owe their poverty to their own stupidity.
  “if the successful merited their successes, it had necessary to follow that the failures had to merit their failures”.
  as de Botton mentions “to the injury of poverty, a meritocratic system now added the insult of shame”
  This is the dark side of a meritocracy. This is also the dark side of talent management that is rarely covered in the press and the blogosphere.
  The most advertised statement comes from GE’s former CEO Jack Welch who recommended that untalented needs to get weed out on a regular basis and created a policy to let go the bottom 10% each year.

Dependency

Another important cause of this status anxiety is its temporal aspect, which is somewhat linked to meritocracy as well.

Our status is based on our merit. If we’re talented we can gain higher status. Great!! But once we reached this higher status, we’re always at risk of losing it. de Botton identifies 5 “unpredictable elements” that our status depends on:

• talent
  yes, we’re talented. But does that mean we have full control over that talent? Are we always performing at our best?
• luck
  bad luck happens; and there is nothing we can do over it.
• employer
  being talented is not always enough to get promoted. Office politics still play a large role.
  The book has been published in 2004 and I would argue that since then we are starting to see a new trend (will it last?) that puts less emphasis on office politics. For one, companies with flatter structure tend to rely less on promotions to award status to employees.
  Also Web 2.0 with its social networks, and blogs allow for any individual to build a status outside of the realm of any employer.
• employer’s profitability
  being talented is not enough. If your employer is not profitable that talent is wasted.
  Same comment as previous point. Having a status independently from your employer also removes this dependency.
• global economy
  Economies have always had ups and downs. When it comes to a down (the famous R word), some individuals will lose their status although their talent or worth is not at fault.

The Azai, The Five Dragon Gods, Vorpal Bunnies, Knights Who Say Ni!

Do that names sound familiar? If not, maybe it’s time to learn more about them. Their leaders could be your leaders tomorrow.

These are the names of guilds in World of Warcraft (aka WoW) a Massively Multiplayer Online Role-Playing Game (or MMORPG). And their leaders are the future leaders of your organizations. At least according to this article published in May’s HBR (you need to be a subscriber to read the whole article).

The main idea of the article is that players who lead teams in the game are learning skills that they will be able to use in business situations, when they will become leaders in the organization

The authors focus on three main components of this leadership: speed, risk-taking and temporary aspect of leadership position.

That’s the latter that is the most interesting and novel to me.

As the authors of the article mention:

The idea of temporary leadership is alien to most business organizations. Companies usually identify people as leaders early in their careers. The selected few carry that designation with them through different jobs.

The idea is that 1) once you’re designated a leader, you’re a leader “forever” and 2) someone designates who the leaders are.

I will start with the point that, in those games, leaders are not designated but rather elected. Not that it has become a popularity contest. All team members want to win. They want to crush that Horde opponent. So they will elect the one leader that can bring them victory. It’s a well-known military effect: leaders emerge from battles.

In the enterprise, life is not always a battlefield. Still, if you have engaged and motivated employees they all want to win (the definition of winning varying from project to project). So they would elect who’s the best to lead them to victory.
Unfortunately this is done in only a few companies (Google comes to mind).
Only caveat: it requires engaged and motivated employees.

In those games, leadership is a temporary position. At one point in time, you’re leading, the week after you’re following another leader. Reasons vary: too much pressure, less availability, someone else better suited for the job at hand, …

This approach has many benefits:

• having been a leader makes you a better follower. You understand better what the leader is trying to achieve
• being a follower makes you a better leader. Your experience as a follower is still recent
• from an organizational perspective, you can “test” more leaders including the ones that wouldn’t have been considered. That can dramatically increase your leadership bench, and see who are the best leaders rather than the best leader potentials.

Could that be the model of the future for business organizations?

This post was triggered by Derek Cheng’s comment on a previous post.

I was arguing that "…in order to be successful in the long run, SaaS providers need to better understand how it works with an existing IT infrastructure… or with another SaaS provider."

I was referring of course to the integration piece that is often missing in SaaS apps.

Derek works at Longjump, a SaaS startup that provides sales and marketing solutions to the SMB market. Before going any further, while I am taking Longjump as an example, I want to clarify that they are doing worse than any other. Actually they are doing better than many.  Here is Derek’s comment:

In fact, we at LongJump do feel that there is a standardization happening at the information model. We offer an open REST-based web services API that virtually any other web service can connect to be it .NET, CGI, PHP, or even ordinary java/javascript.

Is offering an API the same thing as "working with an existing IT infrastructure? Well, partially.

The point is that an API, while a necessary building block to integration, targets primarily an audience of developers. What are the chances to find a developer in a smaller-than-50-employee company or in a company’s department? Slim. So, while an API serves very well that audience of developers, it doesn’t help much end-users or even IT buyers.

So, what do they need?

1. Use of standards. I am not talking of "technical" standards here such as XML, or REST-based Web Services, or WS-Security. Those standards are necessary and cover the plumbing aspects of integration.
   I am rather talking about domain-specific standards, like HR-XML for the Human Resource domain (disclaimer: I am President of the Board of HR-XML). These standards ensure that the the content of your transactions is well-defined and interoperable.
   Without those standards, what you call an Applicant in your API is meaningless for another application that calls it a Candidate.
2. Standard way of using standards. Like many implementers can testify, there are a lot of different ways of using standards: how you manage authentication and authorization, how you manage reliability, how you manage orchestration, how you manage responses, …..
   The Web Services Interoperability Organization offers some resources on that topic.
3. Predefined, out-of-the-box integrations. What really matter to the end-user and IT buyer in the end is an integration that works without them having to develop it. The API offers flexibility, but pre-built connectors to major applications are the only thing that offers the convenience that customers ultimately need.

So, thanks to Derek for his comment and I would be interested in knowing how others see this integration challenge.

If you’re in the SaaS business, you should read this post by Phil Wainewright. It talks about customization in PaaS and SaaS.

Wainewright explains very well what are the requirements -and the challenges- of customization; so I won’t add much on this:

• Yes, customization is a requirement whether you’re dealing with multi-billion, global organizations with thousands of employees or with local, niche companies with only a few employees. The reason why? Each single company has its secret sauce on how they operate and that’s what makes them successful (or not)
• Yes, starting from a blank slate is a bad idea. While all organizations have their specifics, there is much more that is common. So getting "constrained" in your customization is what makes implementations successful.

That’s it for the customization comments.

There are other points though that deserve comments as well:

LongJump’s typical customer is a 50-person company or department in a large organization and the flat-rate cost (irrespective of the number of applications deployed to each user) is $19.95 per user per month.

What’s interesting here is that the target market is "free" of IT. While it is obviously a software solution, the IT-buyer persona (to use my product management jargon) seems not to be involved. Quite usual for 50-person companies; less for large organizations who typically have policies in place to control what’s part of the IT infrastructure. And indeed that’s where we are; these applications services are not part of the infrastructure landscape anymore. Any department can use the tools they feel are the most appropriate for the task at hand without impacting the corporate infrastructure. We are getting close to what Nick Carr depicts in the Big Switch (book review to come).

What’s missing here is the big picture. Not the one about the IT infrastructure landscape, but the one about the Information Architecture.

Software is indeed becoming a utility, a service. But standards are still lagging (apart of the technical ones). Unlike electricity that can flow seamlessly from one device to another, information still face major issues when moving from one system to another, even as a service.

Thus in order to be successful in the long run, SaaS providers need to better understand how it works with an existing IT infrastructure… or with another SaaS provider.

Another part that deserves a comment is the following

These people — quite often industry analysts or product managers for enterprise software companies — insist that 50-person companies have neither the motivation nor the skill to embark on complex customizations. The conventional wisdom says that such companies are looking for cookie-cutter implementations of best practices that they can just get working with right away.

I’m reading at the moment the Innovator’s dilemma, a book by Clayton M. Christensen that explains how successful companies with successful products get pushed aside by newer offerings. It sounds to me like this is really the situation here: experts and managers overlooking or under-serving a market segment based on their current technology capabilities (and assumptions).

But, as Christensen explains, newer, cheaper technologies arrive and take that overlooked, under-served segment…. and then move upward! As explained on LongJump’s blog, they are targeting the SMB market … for now.

It will be interesting how they are doing in a couple of years.