In search of the viral loop

Cross-posted from Zolo Labs.

Just finished reading Viral Loop. As we think about the distribution side of things for Zolodeck, I figured it couldn’t hurt to read about how a bunch of companies achieved massive scale.

It’s a good read… and certainly describes how things were done at companies like Hotmail, Twitter, Facebook, Hot Or Not (remember?), Bebo (remember?), MySpace (remember?), eBay, Flickr, PayPal, and even Tupperware (yeah, really).

It isn’t, however, a book of recipes. I didn’t really expect a book to be able to just tell me the 10 things I can do to fix distribution, I guess, and on that count the book was merely describing how awesome it is when you do achieve massive scale. Not how to get it.

Still, a very decent read, and did trigger a few thoughts for what one can do to address this. A lot of people in the startup space know this already, but it’s been sinking in for me more and more over the past few months: distribution is the more important of the two key things a startup needs to solve (the other being product/market fit, or product in general). And also that distribution is the harder of the two problems, and more than product, it is distribution that will make or break the company.

As I said, we’re thinking a lot about this for Zolodeck… and since this is so important, we’re erring on the side of over-measuring things to ensure we can keep a pulse on what the distribution story is looking like. What else can one do at such an early stage?

The Power of Habits

I just finished reading The Power of Habit: Why We Do What We Do in Life and Business.

It’s a great book. It has three parts – about us as individuals and our “habit loops”, about the organizations and communities we live in and how habits affect them, and finally about how our habits affect the societies we live in.

While a big part of the book explained that habits are hackable (as in, by understanding the habit loop, we can influence our habits), the most interesting part to me was about how product development can be improved from this understanding. All good products become habits – think about this and about all your favorite products.

I think this is an important take away for startups – the trick is to crack the habit loop for the product you’re building. If you can make your product a habit of your users, you’re golden.

Rekindle this blog with Venture Deals

I’ve been away a long, long time. In fact, I thought I was done with this blog. I had even moved onto a different blog (s-expressions), which of course, lies fallow these days… sigh.

So, for the past year or so, I’ve been stepping away from day-to-day coding at my current job at Runa. I’ve been getting involved in more and more of the business side of things as the VP of Engineering. And thanks to that, I’ve really learned a lot more. I wanted to write about some of that, so I figured I’d revive this old blog… so here goes. BTW, today’s post isn’t about Runa 🙂

Just finished reading Venture Deals, by Brad Feld and Jason Mendelson, and it’s a great introduction to the basics of the VC industry. I’m finally beginning to understand things like liquidation preferences, pay-to-play, employee stock-option pools, anti dilution, and a lot more. Not only is the content great, but the style of writing is very readable… highly recommended!

An organizational pattern: Make it about the people. Really.

This post is inspired by two bodies of literature. One is about Lean Product Development, and the other is by a man named Ricardo Semler (and his two books – Maverick, and the Seven Day Weekend). These two bodies of work re-inforce each other strongly. If an organization could be born that truly, at a very fundamental level, implement the tenets of what they’re proposing – then what an ideal place it might be!

I think both these schools of thought start with their emphasis on the importance of people. How cliche! But seriously, these guys *really* mean it. Toyota has long focused on empowering the workers at the frontline – they get to decide a lot of what the manufacturing process is and how it’s changed/improved and so on. In fact, they’re counted upon to innovate and change the standard processes every single day – it might as well be part of their job description. Semler similarly talks of letting the guys that actually do the real job of producing things that the company sells decide things like processes, work-schedules, even pay-scales.

Believe me when I say I have read a lot about Lean product development. The flavor of agile that I use with my teams is heavily influenced by several Lean principles – both on large software teams (40+ people) and in really tiny ones (3 people). All of this basically involves letting the people self-organize and come up with the best plan and process to get the job done. It has worked admirably – and it made my job as a manager easier as well – all I had to do was to remove roadblocks and facilitate what they wanted to do, rather than plan and track and all that. I understand it, I get it.

However, on first hearing how Semler takes these ideas to their (extreme) conclusion – I was a tad less enthusiastic. It was hard to fully trust the idea that people could be OK knowing what everyone else in the organization makes (in terms of compensation), or that if given the choice to set their own work-schedules (the seven day work-week/weekend) they’d not end up with a chaotic schedule. Or even that letting people attend any meeting that was going on was a good idea, or even more so – letting people walk out of meetings that were boring.

However, none of my initial resistance stood up to the five-whys test. The five-whys is simple – all 4 year old children know it. You keep asking why until no more satisfactory answers are available (apparently you do this five times). Most of the time however, you can’t really get past the second or the third one.

I would love to see an organization that were built on these principles – take the seven-day weekend. A team would be able to decide what days of the week they worked. Who said that only Saturdays and Sundays were allowed as holidays? If you can work on a Sunday to get that important deal, you could certainly take Tuesday off to relax and go shopping. Organizations supposedly do this today – with the idea of ‘comp’ time. But usually it is difficult to get it approved, and it isn’t a matter of course. It should be! Why couldn’t someone work a full day on Saturday instead of on Wednesday, every week? My initial reaction was that it would be too chaotic! How would the team get anything done if everyone was taking different days off – it would just be a mess! But really, if your team were given this option, you wouldn’t randomly disappear without coordinating it with the team, would you? Wouldn’t you and the team figure out what the best schedule was for everyone involved? I’m certain they would, and it would be different for each team, and it would work just fine. Everyone would also get some respite from the fast-paced life we lead these days, and have a day to themselves that isn’t necessarily on a weekend when life still stays rather fast-paced.

Let’s now talk about letting people set their own salaries. This is actually based on top of another very important principle – to really empower people you can’t hide information from them. In this case, the information is of the financial type. If the books were open about how much money the company makes, what its costs are, and what industry standards compensation-levels are for the roles of each person involved, then surely the team would make informed choices. Further, this will require each person to know what other people make – if not specific amounts but the ranges based on say experience levels and the job role. People are mature enough to understand these basics, and as long as these decisions are being made as a team, this can work just fine. There will be situations when someone wants to pay themselves way outside their range, but the team will correct for them – either they will make an exception for reasons they understand, or the person will find that pay level in a different organization. It happens today – but the power and information would lie with the team members.

Speaking of teams handling exceptions – this whole system rests on another crucial aspect of the philosophy – that of peer review. Performance reviews shouldn’t be done by immediate managers – that system is too easily gamed. Instead every individual must be rated by all members of the team that they are a part of, and also the people that report to them, and the people they report to. Only complete 360 degrees of feedback can ensure enough checks and balances for this democracy to succeed. This is true when silly things happen – someone is spending way too much on their expense account – to when serious things happen – someone wants to give themselves a fatter than deserved raise. People know when they’re trying to do something that isn’t necessarily fair, but when they also know that everyone will know about it and judge them for it, they will be less inclined to do it. There is no need of a draconian corporate police that throws a large policy document at people – the system handles itself in all such cases.

Part of the peer system, of course, is that the group hires their own team members. No HR department or some other team hires people and then sends them over to join a team. Instead, the team itself interviews and decides who to allow in. This is now common enough in several organizations, so I won’t go into it too much.

Another aspect of Semler’s ideas involve meetings – there are no compulsory meetings, and all meetings are open to any employee. It’s amazing – he says that if no one comes to a meeting, the agenda can’t be too interesting. And if that is the case, then whatever is being talked about or planned won’t ultimately be carried out very effectively. Again, when I first thought about this, I was concerned about the time when no one would come and listen to my brilliant idea about the next big thing. On questioning myself further, I realized that if I were to force people to listen to me and then insist that we go down a particular path because I said so, the result would certainly not be what I probably would hope for. However, if what I had to say appealed to people and they came and listened, then we could together take the merits of my idea, fix its weaknesses, evolve it with collective intelligence, and move forward together as a group of bought-in people. More importantly, if this were really the only way things got done in the organization, then no one would have to waste their time attending meetings about stupid things and, more importantly, no one would have to actually waste their time following along strategies that are bound to fail. (Any of you ever had to follow along as stupid ideas were being implemented?)

A different aspect of this meeting culture is – any meeting be open to anyone. And why not? I couldn’t think up of a single answer. My first reaction was – too many people in a meeting make it ineffective. I have personal experience of this – I have witnessed far too many meetings go on forever or be entirely ineffective because of too many people saying too many things. However, I don’t believe that the reason was that there were too many people in the room. It was often because of the quality of the people in that room – most were, quite frankly, less than able to pull their weight in the capacity that they had been hired for – but the team was not empowered enough to self-select the person out. (Any one know people like this?) If the fortunes of the company (and therefore compensation, job satisfaction, quality of the people that one had to work with, corporate culture) were truly in the hands of the people (indeed, they were directly responsible for them), then people would stop wasting time, and people would try to get the job done as quickly and as effectively as possible.

One other thing – even in organizations filled with super-smart and capable people – sometimes meetings run too long and without useful outcomes. I believe this is because of the way decisions are made in such places. I have seen, many times, that the person with the loudest opinion tries to win by using volume, or that two factions with equal volume argue forever. However, facts speak loudest. Organizations that use actual data to drive the decision making process don’t have to worry about opinions. Google is a prime example. Even things like the logo design is subject to real-usage data-analysis before one is finalized. There are no aesthetically driven shouting matches beyond a certain point. More importantly, data serves as the ultimate equalizer – it doesn’t matter if the CEO has a personal preference about something, the greenest engineer can win the argument in the face of data that proves his point. This makes for truly empowered employees.

See, it isn’t about the meetings – it is about the idea that no one leads by decree. If there is a proposed path that a group might go down, it needs to be democratically selected. It needs to prove itself to that group of empowered individuals that are looking out for themselves, and therefore the organization. It becomes impossible for dumb ideas to take hold – the brutal natural selection ensures no one even gives a damn, and so no one does anything about it. What a wonderful difference from so many organizations where dozens of people march towards the end of the cliff, and right off, because the ‘product manager’ had this great idea.

Such organizations that actually believe that people are their most important asset (cliche time!) and make it so through real empowerment are places where the Lean product development system isn’t some new-fangled idea from the east. It is often the most natural evolution of the collective thinking and creativity of the workforce. Conversely, and importantly, for lean processes to truly be their most effective – such empowerment is a necessary condition. The added benefit is that such places are joy to go to every morning.

For more, I highly recommend Maverick and The Seven Day Weekend. And all the lean development stuff.

The Entrepreneurial Thought Leaders

I’m a book lover – I own nearly a thousand books now, and I even read many of them. I think that since there’s just so much to do and learn, and so little time, books are a fantastic way to know about things we might never get a chance to actually experience. Television can also be educational but I dislike it because it takes too much time to get through things – you can read at a much faster pace.

However, if there are times when you’re sitting in a train while commuting, or just driving to some place, podcasts can be absolutely fantastic. I love that the Economist has audio editions of their magazine (absolutely true to the printed form, and very high quality, btw). I haven’t missed an issue for nearly a whole year.

I want to share another great podcast resource – from The Entrepreneurial Thought Leaders seminar series at Stanford. I’m hugely thankful to my good friend Adrian Wible for telling me about this and his persistence in asking me to listen to them. Almost each and every one of them is like listening to a precis of some really important and interesting business book. Most are by very successful entrepreneurs, or venture capitalists, or professors from Stanford. Brilliant material.

They’re also available from iTunes; and I highly recommend them.

The Cluetrain Manifesto

I just finished reading this book called The Cluetrain Manifesto. I read about it on someone’s blog a long time ago, and had it on my reading list for a while. Then recently, my close friend Kiran recommended it to me again, and so I picked it up.

I liked it! Sure, it is a little repetitive at times – the book is kind of a collection of essays by a group of four authors – and they cover overlapping grounds. However, for most people the book will be one of two things – a) a whack on the side of the head, or b) a reinforcement of what they might have been thinking.

The basic premise is simple – the Internet has changed the way markets behave, and companies need to respond and engage the new markets in this new way as well. Nothing new, huh? Still, how many companies are truly doing it?

In fact, from the above, it might even seem a rather dated book. After all, it was written in 1999, when it was a fact that the Internet was new, and not well understood, and companies were jumping onto the bandwagon. The authors explain that the Internet is not just some new medium to advertise on, or set up websites that dispense corporate-speak. It is a place where people (existing and potential customers) can talk, have a conversation. And these people talk about companies, and share experiences about them. They swap reviews – both good and bad, they analyze companies’ strategies, they come up with ideas for improvement, so on and so forth. It is up to the companies to participate in these conversations and gather what they should from them.

Smaller companies are sometimes good at doing this. They actually know many of their regular customers by name, and gather plenty of feedback and ideas on what they could do more or better. However, there are plenty of companies out there, that even today, do not respect truly their customers, or think they can get away with being a corporation that doesn’t need to truly engage with their customers in a human-like manner. If you’ve ever been treated badly by a large company, say an airline company or a rental car company, then you know what I mean. Most people are pretty clear about the difference in service they should expect when they’re dealing with typical large corporations versus small, mom-and-pop outfits.

And that’s the point. Companies need to get off their high-horse of being a business, and become more like the normal people that work in them. After all, they’re customers too, from someone else’s perspective. Companies sometimes do this during the startup phases. And as they expand (when the distance between the producers and the consumers grows beyond a certain point), they lose this human-ness, and become a faceless corporation that is impersonal and forbidding. If the founders can truly inculcate this and the rest of the principles outlined in The Cluetrain Manifesto, they will find that it becomes another secret-weapon that can be wielded against their more traditional, large corporation-type competitors.

A decent read, I’m sure at least a couple of ideas will stick.

Lean Software Development and the Theory of Constraints

I’ve been trying to apply lean software development principles on my project for a little over a year now. So, when I recently re-read Mary Poppendieck’s Lean Software Development – An Agile Toolkit, I thoroughly enjoyed it and found I was nodding to myself a lot. I highly recommend reading this book because it explains in very simple terms what this whole lean process thing is about, and how it relates to software development. A knowledge of why Agile processes work and what they’re aimed at would help, but is not essential.

For those who don’t have the patience (or time) to read the full book – here’s my version of a summary –

– Strive to eliminate waste. Waste comes in many forms in the world of software development, all of these is waste – partially done work, extra processes that add no value, extra features that have little impact on business value, task switching because of multiple objectives or other reasons, waiting for something, having to go somewhere (to meet someone or fetch something) to get information, defects, and ‘management’ activities.

– Use a technique called value-stream mapping to understand where the process you’re using delivers value and (more importantly) to determine where it adds none.

– Amplify learning through feedback. This is easily done through short iterations and negotiating scope for each of them.

– Think about set-based development techniques.

– Delay commitment – decide as late as possible. At the same time, think about concurrent development.

– Deliver as fast as possible – this enhances learning, and delivers value at the same time. Use concepts from pull-systems and queuing theory.

– Understand the cost of delay – use a product model. Have an accountant on your team who can help with this, and make trade-off decisions in light of what the model says.

– Empower the team!

– Think about integrity – both conceptual integrity, and perceived integrity.

– Testing – TDD, automated functional testing, continuous integration – is key. Refactoring is key.

– Always optimize at a level higher than the perceived issue. Employ systems thinking.

– Embrace the idea of Customer Collaboration vs. Contract Negotiation.

I’ve found that as I started to apply lean software development methods, our processes started to become more and more natural, and that the team became more and more effective. As expected, the team members themselves began to look for new and innovative ways to optimize their workflow, and my job as a project manager became easier and easier from that perspective.

Speaking of optimization, I recall being introduced to the writings of Eli Goldratt by a really smart project manager I worked with in the past – Matt Gelbwaks. Goldratt writes about the Theory of Constraints – his books The Goal and Critical Chain are a really good start to the whole discipline. He has a really simple algorithm to optimize a system, based on throughput accounting

1. IDENTIFY the system’s constraint(s)
2. Describe how to EXPLOIT the system’s constraint(s)
3. SUBORDINATE everything else to the above decision
4. ELEVATE the system’s constraint(s)
5. If in the above process, a constraint has been broken, GO BACK to step 1 but do not allow inertia to cause a system’s constraint.

Applying the Theory of Constraints to improve my teams’ processes, while using lean software development ideas to drive agile practices has proved absolutely invaluable to me over the past year.

I’d be happy to hear from you if you tried similar things on your project… and about how they worked out…