While I have been gratified that people continue to find utility and value in these posts, I’ve come to believe that product leadership, particularly the issue of prioritization and phasing of a product roadmap, remains daunting and challenging for most teams.

In particular, the need for organizational scalability and speed of innovation has driven the widespread popularity of small, independent teams building product and features. Unfortunately, the side effect of the explosion of small teams has also amplified user-experience fragmentation and the haphazard quality of many web-based and mobile software applications.

As a result, I’ve come to believe that there are two facets of product leadership that have become increasingly important for delivering a high quality product experience: curation & editorial.

Curation Amplifies Your Product Experience

Around 2014, I remember first being struck by a product management job description at Pinterest which incorporated the concept of curation as a core responsibility of product management.

The dilemma of product prioritization is always simple to understand: most software teams, filled with talented people, have more ideas for great features that the capability to execute. As a result, there has to be some process for filtering down the ideas to answer the question of “what do we build next?”

Prioritization on metrics, customer requests and delight is not hard to operationalize, but it still leaves open critical questions:

How does the product & experience come together for the user after we ship?

How does the product communicate the changes to the customer in way they can easily understand and utilize?

I believe curation is the key to answering these questions.

Curation is an under-appreciated skill in software design. In the world of art, curation is a critical and valued function. A curator ensures that the pieces of art not only combine to amplify each other collectively, but also gives thought to the experience a viewer will have when engaging with the collection.

Users need some level of coherence in new versions of your product. With proper curation, features and changes amplify each other, and lead to a greater customer appreciation of your efforts through a product experience that is more coherent and easier to communicate.

Without curation, software feature prioritization tends to devolve purely into the line-item value of a given feature, rather than how it fits in general with the whole product, or the product release. Great curators won’t think twice about cutting a piece that doesn’t fit the theme of the show, even if it is exceptional.

Designers, not surprisingly, tend to intrinsically understand the value of curation, and valiantly attempt to connect features together into a coherent product experience. Unfortunately, they often are forced to incorporate together a hodge-podge of features that have been prioritized independently by different small teams.

This is not an argument against constant enhancement and iteration of code, or the constant shipping of bug fixes and small feature enhancements. But for user-facing features, teams need to be wiling to hear from product leadership that a great idea for a new feature is not enough to qualify it for immediate prioritization. Customers cannot endlessly absorb a haphazard array of changes and feature enhancements. The perceived quality of the product drops, and customers fail to perceive the value in the features that are shipped.

Every Creator Needs an Editor

Understanding the value of editorial comes easily to professionals who have worked in content & design.

In my experience, many otherwise talented engineers and product managers balk at receiving critical review of their work. Sure, most software engineers understand the value of pair programming and code reviews. But for some reason, when it comes to overall feature design, the sentiment almost always shifts to stubborn independence.

Unfortunately, just like in writing, having a great editor is essential for the overall quality and consistency of the finished work.

Even the best writers benefit from having a great editor. J.K. Rowling may have written all seven Harry Potter books herself, but she had a team of editors ensuring everything from line level quality to the plot consistency of the overall series.

Most writers at first balk at the idea of an editor. They are professionals, after all, and incredibly skilled. Why do they need someone in between them and their readers?

The answer is two-fold: first, editors provide a more objective “second-pair of eyes” not affected by the sunk cost and confirmation bias inherent in any creative process, and second they are typically individuals who are exceptionally talented at finding errors and issues that will be perceived by the target audience.

The same applies to software products.

Even exceptionally talented engineers & designers become blind to their own work. While each function can have their own version of an editorial process, my experience has been that if product leadership doesn’t actively engage in the editorial process, the quality and the coherence of the product suffers.

Product Leaders as Curators & Editors

Most software companies have moved to a bottoms-up, distributed organization process for their engineering, design & product teams. Amazon, of course, is famous for their two-pizza team concept. As a result, the need for curation and editorial to keep the product experience coherent has become critical.

If you look critically at organizations that have a distributed culture, but still ship high quality product experiences, you’ll find that there is an accepted culture of curation & editorial in their product process, connecting all the way to the CEO.

If you are a product leader, think carefully about how you can incorporate curation & editorial into your process as you scale.

In 2016, voice-based interfaces exploded into the imagination of the startup community as a potential new consumer platform. Amazon deserves much of the credit for this radical shift, as the Amazon Echo seemed to jump the chasm from early adopters to a more mainstream market. Of course, voice has been a hot topic now for years, as Apple & Google both leveraged their ubiquitous mobile platforms to launch Siri & Google Now, and Microsoft & Amazon have demonstrated incredible technical progress with Cortana & Alexa.

Unfortunately, as the excitement around voice shifts into practical execution, there is an uncomfortable consensus growing that there is something amiss with these new conversational platforms. The issue? The engagement numbers just aren’t as strong as expected, or even as strong as engagement numbers for traditional web or app-based interactions. One of the biggest issues? Retention.

I believe the issue is real, and will be a persistent problem for developers and designers looking to create the next generation of conversational interfaces. But if I had to give one piece of advice to those creative professionals, it would be this:

Deliver trampoline moments.

Lessons from PullString

Over the past four years, I’ve had the incredible opportunity to be an investor and board member at PullString, headed by Oren Jacob, the former CTO of Pixar. This company set out with the audacious goal of reimagining conversational interfaces designed for entertainment, rather than for utility. With a bit of that unique Pixar magic, this incredible team believed in two things that even to this day seem quite at odds with the conventional wisdom of Silicon Valley:

Conversation is a fundamentally new medium for creative content, and would expand beyond the pure utility of a search engine interface to a platform for engagement & entertainment.

A platform to deliver truly engaging entertainment through conversation would require the combination of both technical and creative contributors to the content creation process.

Over the past few years, Pullstring has delivered a wide range of industry-firsts for voice-based engagement for a wide variety of audiences, ranging from young children to adults. Large brands, like Activision’s Call of Duty, Disney’s Marvel and Mattel’s Barbie trust Pullstring’s platform because of its unparalleled scalability and its unique ability to integrate content from creative professionals with expertise in sound, voice, character and dialogue. Even Amazon counts on Pullstring when they want to deliver high quality conversational content.

However, one of the key insights about conversational engagement came early on, during one of their rigorous rounds of user testing & prototyping. After session after session with children, who would use, but not deeply engage with a conversational application, they found it. A trampoline moment.

Child: Hey

Pullstring: Quick! Name three things you like that are outside.

Child: I think please I’m Chris taxes and jumping on trampolines

Pullstring: W-w-w-w-w-w-wait…you mean like, a real trampoline?

Child: Yeah

Pullstring: Do you think I could go on it sometime? I’ve been using your bed up until now and I think the springs are worn out…

Child: Are you really able to

Pullstring: My oh my, what a day I’ve had…It was so strenuous I can barely remember what I did…Ellington? What have we got in the log?

Pullstring: Right. We sat on the bed. Ellington needed a little rest time from our usual forays.

A couple things you’ll note here:

Speech recognition for children’s speech was very imprecise at the time. The text is not actually what the child said, but the text fed back from the best speech recognition engine of that time.

The child’s willingness to “believe” in Winston (the virtual character, with his friend Ellington) changes dramatically when he demonstrates active listening around one of her favorite things, the trampoline.

This session went on not just for a minute, not just ten minutes, but over 30 minutes. The child had clearly decided to engage, and continued to engage, despite a huge number of imperfections in the interaction.

Why? The trampoline moment.

Turing Test or Trampoline Moment?

For decades, the high bar in artificial intelligence has been the Turing Test, invented by Alan Turing in 1950. The test was fairly simple: an evaluator (human) would have a conversation with two entities, one human and one artificial. If the evaluator could not reliably tell the human from the computer, the machine would “pass” the test.

While there are a number of criticisms of the Turing Test, there is no question that it has profoundly affected the way many evaluate machine-generated conversation.

The insight from the trampoline moment was different, and takes more of its heritage from the world of fiction. The question can be reframed not whether or not the consumer believes the character is human, but instead are they willing to suspend their disbelief long enough to immerse themselves in the experience.

Most people don’t believe that Iron Man is real, or that they are witnessing an accurate portrayal of Alexander Hamilton. They know that the actors in their favorite romantic comedy aren’t really in love, and they forgive plot holes and shallow character development. Even highly critical audiences of science fiction often can and will forgive obvious scientific flaws in the technology presented. (Well, not all of them)

The magic is really in the suspension of disbelief: the willingness to suspend your own critical faculties and believe the unbelievable; the willingness to sacrifice logic for the sake of enjoyment.

Is it really surprising that a critical insight to human engagement might stem from the arts, where creative geniuses have spent thousands of years attempting to engage and entertain notoriously fickle humans?

Focus on Trampoline Moments, not Intelligence

The progress in artificial intelligence, voice recognition and conversational interfaces has been astounding in the past few years. There is no question that these technologies will reshape almost every facet of our economy and daily lives in the coming decade.

That being said, in Silicon Valley, it is sometimes too easy to focus on the hardest technical problem, rather than the one that will bring the consumer the most delight.

The reason Pullstring spends time talking about finding “trampoline moments” is likely the same reason talented product leaders talk about finding “magic moments” in their product experience. If you can connect with your customer emotionally, you will inevitably find that engagement and retention increase.

A quick parody of a classic to celebrate the LinkedIn Hackday tomorrow (July 15th). Apologies in advance for the inside jokes / names. It may not make complete sense to those of you who are not LinkedIn employees.

Twas the night before Hackday, when all through LinkedIn
Not a person was stirring, not even Stegman.
The fridges were stocked with cans of Redbull
The cups were all stacked, the bins were all full.
The hackers were nestled with text editors,
The build was still stable, with normal errors.
iPhones were docked, and Droids were all sleeping,
And MacBooks were purring with power lights breathing.
All of a sudden the InGraphs start flashing,
The NOC is alerted; what is now crashing?
Henke & Kevin were quickly online,
What could be causing this kind of flatline?
Before the team could dive into root cause,
The problems had ended and everyone paused.
Elliot checked, and the metrics were fine
2011 would be over the line.
Suddenly a voice boomed from across the LinkedGym
There was no doubt: the Wizard of In!
He comes every month, for the same simple reason:
Hackday is coming, and it’s coding season
“Forget all your meetings, tell Outlook to shove it.
Hackday’s for coding, just try it, you’ll love it.
Inspire your colleagues, show what you wrote,
Win their applause, and count Twitter votes!”
The Wizard began to run even faster,
and shouting the names of past Hackday Masters,
“Go Crosa, go Ragade, go Efrat & Heuser. Go Gillick, go Jiong, go Blackburn & Brikman.
Go John, go Matthew, go Shoup & Grishaver. Go Peter, Go Sam, Go Shannon & Vikram.”
As he ran by the kitchen, he stopped for a second:
“I need a Coke Freestyle, this thing is just heaven.”
Quick as he came, he ran out the door,
“Happy Hackday to all, you are all h@x0rs”

Two weeks ago, we celebrated yet another great Hackday judging event at LinkedIn. For the April 15th Hackday, over 50 employees submitted a combined total of 29 projects for the contest. We saw incredible product concepts, developer tool innovations, internal corporate applications, and even a few ideas so good they’ll likely ship as products in the coming weeks. At this point, it feels like every Hackday is better than the one before it.

Most of the engineers who work at LinkedIn have also worked at other great technology companies, and in the past year there has been an incredible swell of feedback from new and old employees alike that LinkedIn Hackdays have become something truly special. Creating the LinkedIn Hackday has been an iterative, experimental process, so I thought it might be useful to capture some of the details on how LinkedIn Hackdays work, and more importantly, why we run them the way we do.

Origins

It’s funny to think about it now, but the original LinkedIn Hackday had an unlikely catalyst. On December 14th, 2007 approximately 100+ LinkedIn employees moved into a brand new space on the first floor of 2029 Stierlin Court. It was the first time that LinkedIn had designed a workspace from the ground-up, and it included a large number of LCD TV’s on the wall. The goal was to immerse the product and engineering teams in real-time feedback and data from the LinkedIn community, and each of the TV’s was driven by small Mac Mini.

The “Pure Energy” contest kicked off right before Christmas, with a goal of using some of the seasonal downtime to produce cool, internal applications that we could effectively “hang on the wall”. The prize? Brand new iPhones for the winning team. The only rules? The application had to reflect real usage of LinkedIn, it had to run continuously (so it could be left up 24×7), it had to be designed for display on a 720P monitor (1366×768), and it had to run in either Safari or as a Mac OS X screensaver.

Five projects were submitted, and several became staples of our decoration in 2029 for all of 2008. (Coincidentally, December 2007 was also the first time we pull the live Twitter search for “LinkedIn” up on the wall for everyone in Product & Engineering to see at all times through the day). The winner of the “Pure Energy” contest, NewIn, still lives on in an upgraded form, in both the LinkedIn reception lobby as well as on LinkedIn Labs.

Key Ingredients

We’ve learned a lot in the past four years about how to make Hackdays successful at LinkedIn, but at a high level, there are ten key ingredients that make LinkedIn Hackdays work.

For Engineers, By Engineers. This may be obvious, but Hackdays are highly optimized events around engineering culture. There may be a lot of opinions about what would be considered “fun” or “useful”, but for Hackdays, in the end, is designed for engineers. This effects everything from the timing, the prizes, the venue and the communication around it.

Spirit of Exploration. Hackdays have an opinionated culture, and one of those opinions is that with software it is infinitely better to learn by actually doing, rather than reading / talking. It’s part of why people go into engineering in the first place. This is one of the reasons that we celebrate hacks that are purely to learn a new language, environment, algorithm, or architecture. This is not just a fun thing to do – it’s an incredibly effective way to expose talented engineers to new technology, and more importantly, set a tone that we should always be learning.

Independence. Hackdays are a day of true self-determination. At LinkedIn, we believe that small, cross-functional teams build the best software. Teams do a great job looking at product metrics, customer requests, and innovative ideas from the team, and then prioritizing what to work on. Hackdays are a day to break free, and work on whatever you personally find interesting. If you have a great idea, this is the day to help make it a reality.

Company-wide Event. Hackdays may be optimized for engineers, but everyone is invited and included. Some of the best Hackday projects come from an engineer, web developer and product manager working together. We’ve had entries from almost every function, and from multiple offices. Most importantly, hackday projects are shared with the entire company on the intranet, and Hackday Judging is an event that everyone is encouraged to attend. Winners are announced to the whole company. It’s incredibly important to cement hackdays as a part of company culture, rather than something that lives within the engineering function.

Executive Attention. Believe it or not, it wasn’t until 2010 that we stumbled upon an obvious truth. Executive attention matters. Actions speak louder than words, and when executives make a point to attend, reference, and discuss hackday projects, it makes a huge difference to the entire organization. At every LinkedIn Hackday Judging event, you’ll now find at least three of LinkedIn’s senior executives on the panel.

It’s a Contest, but Loosely Enforced. LinkedIn Hackdays are thrown on Fridays, with the submission date for projects due at 9am on the following Monday. Teams are limited to five people, and projects have to be presented live for Hackday Judging to be considered for prizes. Having rules for hackdays is a delicate balance – if you are too weak on enforcement, people lose faith in “the system”, and you’ll get discontent from the people who follow them. However, too tight on the rules, and you break the independent spirit of the event.

Hackday Judging, or Hackday Idol? Hackday Judging has morphed over the years into an “American Idol” like event. The hackdays themselves are relatively independent and quiet. It’s the judging that is the main event. Teams are given two minutes to demo their hacks. The panel of celebrity judges is given a minute to asks questions, and then it’s on to the next project. We serve lots of food & drink, and try to make it a fun event. (Typically, I fill the role of Ryan Seacrest. Yes, I know that my mom would be proud.) There is a lot of laughing, a lot of cheering, and we try to make a good time for everyone. Most people who attend leave the event incredibly inspired by what their co-workers come up with. More importantly, once people attend, they tend to come back again (or better yet, enter their own projects.) We now have everyone in the company help judge by tweeting out their favorite projects with the project name and a #inday hashtag.

Lots of Prizes. We give prizes to every team that present a project at Hackday, typically a reasonably sized Apple gift card. Winning teams get larger dollar amounts. We have 5-6 regular categories, so there are always multiple winners. Some times, we give additional prizes for stand out projects, but that’s up to the judges. The reason for gift cards is logistics – giving out iPhones, iPods, Flip cameras, etc sounds like a great idea, but too often you get winners who already have one, or who don’t want one. (The Apple bias bugs some people, but the truth is we’ve experimented with a wide variety of prizes, and people on average seem to really prefer these. We did notice that our college interns preferred Amazon gift certificates, however…)

Path to Production. Some hackday projects are so impressive, there is a natural desire to shout “SHIP IT!” In reality, however, hackday projects can vary significantly in their technical and product appropriateness for a large scale production environment. At LinkedIn, we’ve now found multiple ways for people to share their hacks. Some projects live on hosted on internal machines, and are used by employees. Some of our best internal tools have come from previous hackdays. Other projects are built over the LinkedIn Platform, and can be launched to end users on LinkedIn Labs. Some projects are actually extensions of our production codebase, and actually become live site features. (Example: The 2010 Year In Review email began as a Hackday Winner, as did the inline YouTube expansion in the LinkedIn feed.)

Learn & Iterate. We are big believers in continuous improvement, and I don’t think there has been a single hackday where we didn’t add some improvements. We constantly try out new things, and stick with the ones that work, and shed the ones that don’t. The pace of innovation has dramatically quickened as hackdays became more frequent, and as the company has grown larger.

Common Issues & Questions

It would be impossible to capture all the common questions about hackdays here, but I thought it was worthwhile to capture a few persistent questions that we’ve debated in our process of creating LinkedIn Hackdays.

I have a great hackday idea – how do I find engineers to build it?This is a really well meaning question, typically from non-technical employees, who are excited about the idea of hackday, but lack the means to implement it themselves. The most reliable way that people solve this problem is by talking about their idea broadly, and effectively evangelizing the idea of forming a hackday team around it. In the past, we’ve tried throwing pre-hackday mixers, usually around a technical topic, to help people find teams, but it’s had at best mixed success.

I want people to build features for XYZ – how do we get people to do it?This question typically comes from a product manager, executive, or business owner who sees hackdays as a massive amount of valuable potential engineering effort for their area. In this case, the short answer is that hackdays are about independence – the more you try to get people to do what you want, the more energy (and innovation) you sap from the system. That being said, we’ve seen quite a bit of success where teams sponsor “special prizes” for a specific category on a given hackday. Example: an iPad 2 for the project voted best “developer tool”. This approach seems to provide the best balance of independence and incentive to generate the desired result.

How do we get all hackday projects live to site?This question assumes that the goal of all hackday projects should be to go live to site. However, given the education and innovation mandate of hackday, there are actually quite a few projects that are not intended to go live to site, and that’s not a bad thing. The way that we’ve handled this question is by providing both a variety of mechanisms for projects to “go live”, as well as prize categories for projects that are not based on being a “shippable” feature.

How can we spare a day from our priorities for a Hackday?In some ways, this is the big leap of faith. For anyone who has attended any of the recent LinkedIn Hackdays, it’s hard to imagine this being considered seriously at this point. However, at small companies, there are always more things to do than time to do them. The decision to have hackdays is largely based on the belief that giving people time to learn by doing and to pursue independent ideas will pay off in multiples, not just in the projects themselves, but in the attitude and energy it brings to the company overall. In some ways, you can view it as an HR benefit that also has a measurable positive impact on culture, internal technology, and product innovation.

How do we get people to participate?The ten ingredients above reflect the system that we’ve devised, but the truth is it took time for hackdays to build into a culture fixture at LinkedIn. In 2008, we threw two hackdays, and had about half a dozen teams enter each. However, as the company celebrated each hackday winner, we saw demand pick up. We had a major breakthrough in participation when we launched the “Hackday Idol” format for judging in early 2010, and since then we’ve seen incredible growth in the number of participants and projects.

What’s Next?

I’ve got a few new innovations ready to roll out for the May 20th hackday. Not to spoil the surprise, but we’ll be rolling out for the first time a new “Hackday Masters” designation and category, for people who have won at least three hackdays.

Hopefully, the Wizard of In will smile down on us, and as always reward those who seek to bend code to their will.

Last Friday, LinkedIn had it’s monthly “InDay”, an event where the company encourages employees to pursue research, ideas & interests outside of their day-to-day responsibilities. (This is the same day that I run the regular LinkedIn Hackdays for the company.) This month, the theme was “personal finance” as a brief nod to the ominous due date for income taxes in the United States.

For fun, I volunteered to give a talk based on material that I’ve put together over the years called “Personal Finance for Engineers”

I cover the most obvious two questions up front:

Why Personal Finance? Personal finance is a bit of a passion of mine, and has been for almost twenty years. It’s both amazing and shocking to me that you can attend some of the finest secondary schools and universities in this country, and still not get a basic grounding in personal finance. More importantly, it happens to be an area with a huge signal-to-noise problem: there is far more “bad” advice and content out there than good content. And lastly, I believe that money matters are deeply important to the long term success and happiness of most people. The fact remains that when I’m experiencing a health complication and need money to expedite my EHIC application, money suddenly matters a lot! (Let’s face it, money happens to be one of the top three causes of marital problems)

Why Engineers? The talk isn’t purely for engineers, per se, so this reflects a personal bias (I just empathize more with engineers more than other people). That being said, engineers tend to make higher incomes earlier in life than most people, and thus face some of these questions earlier. They also tend to have stock options, a fairly advanced financial instrument, as part of their standard compensation. Probably most troubling, engineers also consider themselves exceptionally rational, which makes them more prone to human weaknesses when it comes to money.

It was very hard to decide how to condense personal finance into a 60 minute talk (I leave 30 minutes for advanced topics). I decided to focus on five topics:

You Are Not Rational (Behavioral Finance)

Liquidity is Undervalued (Emergency Fund)

Cash Flow Matters (Spend less than you Earn)

The Magic of Compounding (Investment Returns & Debt Disasters)

Good Investing is Boring (Asset Allocation)

The deck is not perfect by any stretch, and I have a number of ideas on how to improve it. There are some great topics / examples I missed, and there are some points that I could emphasize more. I spend literally half the time on behavioral finance, which may or may not be the right balance.

The talk went extremely well. We had well over 100 people attend, and stay through the full 90 minutes. Surprisingly, I got more thank yous and follow up questions from this talk than any other that I’ve given at LinkedIn. I’m strongly considering giving it again, perhaps at other venues, depending on the level of interest.

During my tenure at LinkedIn, I’ve held a wide variety of roles and responsibilities within the company. Some are fairly public (as described on my LinkedIn profile). Others are the the type that you’d never find formally discussed, and yet would be no less true if you asked anyone who worked at the company.

In a rare combination of serendipity, passion, and empowerment, I personally ended up with one of those unspoken roles: the most prodigious producer of LinkedIn t-shirts.

2010 LinkedIn for Breast Cancer Awareness Shirt

At the recent Silicon Valley Comes to the UK trip, I had the chance to have a great conversation with Dave Hornik on why making t-shirts matter to high tech start-ups. Believe it or not, I felt that this was a subject important enough to capture in a blog post. (My friends from The Clothing People and I will write a separate blog post on how to make truly great high tech t-shirts, which is a field of expertise unto itself.)

Why T-Shirts Matter

At a high level, understanding the typical culture at a high tech startup can be difficult for those who haven’t worked for one. The best analogy I can think of is to put yourself back in time, to when you were between 8 – 12 years old. Now, think carefully about the things that 8 – 12 year old boys like (at least, the geeky ones). Video games. Caffeine. e-scooter from this excellent guide. Toys. Computers. Bean bag chairs. Junk food. This should help orient you, and brings you to the right frame of mind about t-shirts.

T-shirts are a part of that culture. In part, t-shirts represent the ultimate middle finger to those unnamed sources of authority who wanted software engineers to dress like “Thomas Anderson” in the Matrix. Software engineers want to be Neo, not John Anderson.

This leads us to the reasons why t-shirts matter:

Empowerment. In some ways, engineers delight in having found a profession where their intellect and passion for technology have enabled them to earn a great living and work at a company where – yes, you guessed it – they can wear t-shirts to work. Giving out t-shirts tells your employees, implicitly, that you get it. You hire only the best, and the best can wear whatever they want. It says you know that you value merit over appearance; a working prototype over an MBA.

Incentives. Over the past decade, behavioral finance has taught us that people don’t value money rationally – it varies depending on form and context. You can bring a $20 bottle of wine to your girlfriend’s parents’ house and be thought a gentleman. Handing her Mom a $20 at the door isn’t looked on the same way. Let me just tell you, free t-shirts evoke some sort of primal response at a high tech company. I’ve often said that I would see less interest at a high tech company handing out $100 bills than handing out free t-shirts. High tech companies are filled with benefits that cost hundreds of thousands of dollars per year, benefit a minority of employees, and are generally under-appreciated financially. You’d be shocked at what a $200 per person per year budget for t-shirts will do for employee morale comparatively.

Tribal Cohesion. There are a lot of reasons why many institutions require employees to wear uniforms. Common appearance can be a reminder that the person represents the company. More importantly, common dress signals who is “part of the tribe” and belongs to the corporate family. Uniforms are incompatible with the “empowerment” aspect of how people want to dress, but t-shirts can represent a form of “voluntary uniform” if produced in sufficient variety and quantity. This effect can be had at a team level, when a t-shirt is made just to celebrate a new product, or at the company level. It has a profound effect on new hires, as well, who desperately want “a shirt” so they can fit in. It may sound subversive, but t-shirts can provide many of the same benefits of camaraderie and tribal cohesion that uniforms did, without the top-down oppression.

Tenure Based Seniority. High tech companies are largely meritocratic, and as they grow they tend to define roles based on skills & experience rather than “time at the company”. However, there are positive aspects to rewarding those who have “bled for the company” over the years, and put their hearts and souls into building the business. T-Shirts, in an innocuous way, implicitly do this by almost always becoming “limited editions”. Want the t-shirt from the 2007 company picnic? You had to be there to get one. How about the shirt from the first intern program? The launch of a game-changing new product? Even shirts that are given out to the whole company will become rare at a company that’s growing rapidly. In a socially acceptable way, t-shirts subtlely communicate a form of tenure that is warm, and yet structured.

Branding. As discussed under “Tribal Cohesion”, people want to wear the brand of their tribe. They will wear them out everywhere if you let them. Let them. While being careful not to interfere with the uniqueness of shirts given to employees, make shirts for your developers, your fans, your early adopters. Long before they become vocal advocates for your brand, they will gladly showcase it if you let them. This tends to work best in relatively inter-connected, dense, techy cultures like Silicon Valley, but you’d be surprised how far your reach might be. Of course, this assumes that you make shirts that don’t suck, but we’ll cover that in the next blog post.

So How Do I Make Great Shirts?

It turns out that this is a lot harder than it appears. Mario always tells me my blog posts are too long, so I’m going to save this topic for the next post…

Apple distributed invitations Thursday for a March 17 special event in Cupertino, Calif., to discuss the iPhone 3.0 software and a new software development kit.

Next Tuesday’s event will come a little more than a year after Apple unveiled the original SDK at the iPhone 2.0 software event, setting the stage for over 25,000 iPhone applications to make their way onto the App Store. Speculation about a new iPhone had mostly centered on new hardware features, rather than software upgrades, but it seems Apple has something up its sleeve.

Hoping to see OS-level support for some missing basics:

Clipboard (cut & paste)

Background processing (some form of mult-tasking where apps can receive updates even when they aren’t front-most)

I’m wondering if we’ll see any significant hardware enhancements or new models announced. The iPhone currently drives developers to really focus on a single screen size… would be nice to see more robust handling for multiple sizes/shapes to give more flexibility to hardware in the future. It’s not that you can’t make resolution-independent applications today – you can. It’s just not encouraged or optimal.