My wife is a big fan of Lush soaps, and I've noticed that the cans of lush products in our shower had stickers with people's faces on them.
This is what Lush's website has to say about these stickers:
"What has held us together for over 30 years is the pleasure we take from our work. Pouring a soap, mixing a cream, creating a fragrance, or rhythmically pressing 1,000 shampoo bars by hand give our lives meaning. This makes us proud of what we produce and so we like to put our own individual 'mark' on each product before we sell it. The face sticker smiling out at you from every LUSH product tells you when it was made, the 'best before' date, and who was proud to make the product, by hand."
This is a great way to personalize a product and engage with customers. I wasn't surprised to read that this attitude extends to Lush's social media strategy, which uses tools such as Facebook and Twitter to engage on a personal level with their customers. The linked article describes how this approach is handily beating the "Post corporate messaging on Facebook" approach being used by Lush's closest competitor, The Body Shop.
This got me thinking about software, and how we organize teams of people to build it. One of the most important factors in producing high quality software is to ensure that each member of team building it is intrinsically motivated and takes personal pride in the entire product they're producing. In other words, that each member of the team is willing to put their face on a sticker and proudly slap it on their work.
When building complex software systems with large teams, potentially across several different partner companies, one of the keys to bringing together a successful project on time and on budget is the cohesion of all the team members. The biggest pitfall in these large projects is often that each team member or partner company concentrates strictly on the piece of the system they are building, and disconnected silos of functionality end up forming. The left hand doesn't know what the right is doing, and when it's time for all the pieces to come together, they don't!
The way Lush operates ensures that a specific person is responsible for (and proud of) an entire product that they're delivering. This is in contrast to other companies that may see each employee as a siloed station along an assembly line.
Similarly, successful software projects have team members who take ownership of the project as a whole, and not just their silo. People in the mindset of putting a sticker with their face on a product will keep track of dependencies between the different silos, perform testing across multiple partner companies to ensure that the bridge between each component is reliable and proven, and ensure that they're proud of the entire product their team is building, rather than just their specific functional area.
This is one reason that I believe in assigning vertical areas of ownership to each member on a team. If a single person is responsible for an entire feature, from the UI to the middle tier logic to the database, they will know exactly how it is supposed to work, which design makes sense, and will drive the feature to completion and testing. Most importantly, it guarantees that the feature works end-to-end, and drives features to become real and working as fast as possible. Of course, even in the vertical approach, designers will still work primarily on the UI, and a SQL expert may do the bulk of the DB work. The key is that each vertical feature has an owner looking after it, regardless of the owner's particular skill set.
In horizontal areas of ownership, where one person owns the DB, another owns the cloud services, and another owns the UI, a siloed attitude of "that's not in my purview" can arise. There's also no driving force to making a feature work end-to-end, as people can see their part as "complete" even when it isn't wired up and working.
As a project lead, I want to see Jim's face on a sticker slapped on to the "Login" feature, and Mary's face on a sticker slapped on the "Post to Facebook" feature. That lets me know that those features have dedicated owners who take pride in the entire user experience of each part of the application, and who focus on delivering a real, working feature, rather than a disconnected component.
What does your team do to put your faces on the products that you build by hand every day?