SlideShare: The founders have left the building

Some news to share: Amit is moving on from SlideShare. This means all SlideShare founders have left now (Rashmi and I left several months ago). Rumor has it he’s going to be doing something high-impact and really exciting …stay tuned for more details. ;->

It’s a bittersweet moment for founders to leave, much like watching your child go off to college. Building organizations and parenting are pretty similar: the goal is to make something that will outlast you, something that will stand on it’s own two feet and go into the world. Baby SlideShare is all grown up!

SlideShare continues to grow, and in the last few months many of the features that we had worked on for a long time finally became available. Providing analytics free to all users delivers a ton of value that should help every SlideShare user understand where their traffic comes from.  Slide authoring (powered by HaikuDeck) takes SlideShare into the realm of presentation CREATION in a very elegant way. And shipping an IOS app to compliment the Android app completes the transition of  SlideShare into the mobile era. LinkedIn is continuing to invest in the product, and the results are showing. LinkedIn is also continuing to invest in the team, centralizing development in San Francisco (until now it has been split between San Francisco and New Delhi).

The continued traction that SlideShare is showing (it’s now poised to break into the ranks of the top 100 websites worldwide) is also a real joy to watch. Who knew that a bunch of PowerPoint presentations would be such a global cultural phenomenon?

I’ve worked on SlideShare from 2006 to 2014, a solid 8 years. It’s been a fun ride, and I made a lot of great friends, got a few grey hairs, and had a lot of crazy experiences.

Much love to the team and the awesome SlideShare community. As Jeff @ LinkedIN  likes to say, Next Play! Rashmi and I are taking it easy but are also having fun experimenting with some new ideas, as well as doing a bit of angel investing. I’m going to try to blog a bit more too, let’s see how that goes. :-)

One-question daily SCRUM

A daily standup meeting (or “SCRUM”) with the team is an important part of agile development. But done wrong, these meetings can be demotivating and can reinforce traditional command-and-control management practices (which don’t scale and don’t work well with creative people).

The three questions that are “supposed” to be asked in standup meetings (according to most descriptions of Agile Project Management) are
1) What did you get done yesterday?
2) What are you going to do today?
3) What are you blocked by / need help with?

The problem is that the first question (“what did you get done yesterday”) sucks. It is important that the feel of a SCRUM meeting be peer-to-peer. And in respectful peer relationships you are not reporting achievement bullet-points to each other. The very act of reporting “what did you get done yesterday” puts people into a political mentality. The search for trivial tasks that can be done to make an impressive-sounding achievements will begin. This question just sucks in terms of the effects it has on a team, and has no place in SCRUM.

“What did you get done yesterday” is a question that seems like it was designed to solve the problem of a lazy manager. Anytime you find a process like this you should kill it, because it’s sapping the motivation of the team. Managers should work harder to get the information they need: team processes should be tuned to the information needs of workers.

The question of “what you are blocked by” is also problematic. I’ve noticed that explicitly requesting this information doesn’t work well. It makes people feel like they are complaining or ratting out their colleagues to say that they are blcoked by something that someone else is doing (or failing to do). If you focus on the work that’s being done.

The third question, “what are you working on today?”, is where the magic happens. It makes concrete the fact that people are in charge of what they want to work on. It is forward-looking so it is useful for planning purposes. And it often contains within it the answer to the first two questions. So in a slideshare SCRUM that’s the only question we ask.


Most adults (or even most children) _really_ don’t like being told what to do. In order to feel motivated and engaged, we need to have *agency*. Iin other words, we need to be able to make  meaningful decisions about the work. This is doubly true for the smart and internally-motivated people that join most startups.

On the other hand, you are a startup founder in a rush – to build the product, to gain market acceptance, to defeat the competition and scale when its time. How can you get the product doing what it needs to without micromanaging the team? How do you get each individual to rally behind the current challenge?

One approach I’ve used at SlideShare is to articulate the 1-3 metrics that each team is working towards. Your team should know that their job is to move that metric in the right direction, and they have wide discretion to do whatever it takes to achieve the objective.

Easier said than done, right? It’s actually damned hard to come up with 1-3 metrics that define success for your team. And to make it even harder, it has to be something that the team can actually impact, not something that feels like it is in the hands of fate.

For example, maybe as an internet business you live and die by traffic. But your team may have little control of the number of unique visitors that hit your website. If this is the case, then making this the metric is setting your team up for failure. They probably have much more control over what percentage of registered users complete their profiles or become long-time repeat visitors, for example.

If you can orient your team around shared goals that are captured by metrics, then SHUT UP! Don’t dictate the “how”: that’s micromanagement. Let the team figure out (independently or together) how they will achieve the objective. Give people space to make their own decisions, to exercise their own initiative. They’ll surprise and impress you!

These 1-3 metrics have to be more important to everybody than the thousands of other chores and tasks that compete for their attention. Everyone on the team should always know what metric the team is working on, and the current status of the metric (is it getting better? worse? why?).

The metrics need to be available to your team on a daily basis (an automatic daily email works well for this). As a leader, you should notice and comment every time the metrics go up and down. The email will be iterated on constantly as the numbers that drive whatever your goal was are discovered and instrumented. Eventually it may contain a lot of numbers, but they will be the numbers that the team thinks they need to do their job.

Laser-like focus on a few metrics is the goal. But reality intrudes There’s always critical maintenance work to be done: bugs to be fixed, customer service issues to be handled, site downtime to be reduced. Your team is under this pressure, and feels a responsibility to respond to it. This is ESPECIALLY true in an early-stage startup, where it can feel like just keeping the ship from sinking requires all hands on deck and every-day course-correction.

One way to fix this is to have some members of the team who are on firefighting detail. Their job is to deal with all the random crap that reality throws at you. Anything that is a fire that needs to be dealt with RTFN. As long as everyone takes a turn firefighting, it means the rest of the team can focus 100% on the key metrics.

Moving numbers is hard! It’s way easier to ship new features than to have a measurable impact on user behavior or revenue. By focussing the team on an important metric, you are making them work harder. The fact that you are focussed on a SHARED goal helps here. No one individual is signing up to move mountains. You’re all trying to do it together, and you will succeed or fail as a team. People want to actually have an impact on the world: it’s your job as a leader to provide an environment where this is possible.

When you set shared goals like this, you’ve turned working at your startup into something like a shared quest or an adventure. And you’ve provided a platform where your team can (together) have an impact on the outside world, and impact that 1)Is important, and 2)that they can actually see. I think that’s pretty cool!

Software as a work in progress

I was interviewed by CIO magazine about the technology behind SlideShare. The article was called Successful Tech Startups Offer IT Tips. There are some nice tips from Groupon,, and ZenDesk.

Here’s a excerpt from the interview:
SlideShare is at the point now that it tweaks its Web-based application dozens of times per day. “The combination of having very good measurement of user behavior with the ability to make small changes to the site means we can iterate extremely quickly,

Cloud interview on the windows azure blog

I talked to the folks who are in charge of the windows azure blog, and they were kind enough to publish it. I tried to focus on what the real benefits and challenges of cloud-based systems are (especially for startups), instead of the faux issues of control and security that seem to be the focus of many of these conversations.

As far as I’m concerned, the issues with the cloud come down to disk speed, network speed, and cost control. Disk speed, because it’s hard to run a big-ass MySQL database on a virtual machine with poxy IO performance. Network speed, because it’s hard to quickly move gigabytes of data into the cloud. And cost control, because it’s easy to get sloppy and waste money when you can scale your infrastructure (and your costs) at the push of a button. Remember the spider-man credo: with great power comes great responsibility!