Daily standups are socially naive

There’s been a lot of writing lately about how boring and awkward daily standup meetings are. There’s no doubt that they are boring and awkward. And there’s no doubt that management sometimes abuses them to make sure the engineers come in to work “on time” (i.e. on the managers schedule, rather than a maker’s schedule).

The typical recipe for a standup meeting is every team member says “what they did yesterday”, “what they’re going to do today”, and “any blockers they have”. One thing I noticed at SlideShare was that engineers were very bashful about the “any blockers they have” question. They didn’t want to be perceived as blaming others, so even if they were blocked on something that someone could fix they often wouldn’t mention it. This is probably smart of them. If you want someone to do something for you, don’t start out by making them look bad in front of their manager!

The “reporting” aspect of saying what you had done yesterday was also a double-edged sword. It for sure provided social pressure to accomplish something every day. But it also made engineers feel low-status and closely-watched. When engineers answered this question, I could tell from their tone of voice and body language that it didn’t make them feel like they were kicking ass, but that they were feeling like they were reporting to a boss. I could tell that they were talking to me, even though a daily standup is supposed to be about communication to the team.  In the workplace, status is very highly linked to how closely you are monitored by your superiors. Junior engineers are often micromanaged. Tech leads report to managers on a weekly basis. Founders report to Investors on a monthly cadence. And Investors report to LPs every quarter.

So out of the “3 questions” advocated by the Agile process, two of them were incredibly politically/socially naive. Which I find interesting, engineers are often stereotyped as being like that. By my engineers were a lot more socially and politically adept then the people that came up with those questions!

In the end we cut it down to one question: “what are you going to do today”.  This seemed to work pretty well. It’s a managers job to know what people are doing and to notice if people are stuck and keep saying the same thing. Making engineers feel in control is more important than making life easy for managers. If you want to hire good people and have them do good creative work for you, they have to feel like you are helping them kick ass.

At the same time, it’s important to recognize the high cost that an all-team meeting has. Even a 10-minute meeting is expensive if 10 people attend it! And there’s no way of getting around the fact that night-owl engineers will feel like a standup meeting is an attempt to get them to come into work earlier than they’d like. So even with only one question, daily standup still feels like a plot to subordinate engineers more than a tool to help them.

In my next startup, I will definitely replace the daily standup meeting with a slack channel where people say what their plan for the day is. I always spend the first few minutes of the workday thinking hard about what I should do that day, and writing that down. Adding a social aspect to that process via chat software sounds like an appealing way to start the day. Especially when you compare it to sitting through yet another boring standup meeting!

Ex-SlideShare Mafia on 2 Continents

A fair number of startups are starting to come out of the team that made SlideShare. One interesting twist is that the team was in both New Delhi and San Francisco, so startups are popping up on two continents now that have a little bit of the SlideShare secret sauce mixed into their recipe.

The biggest by far is Bash Gaming (already acquired for a higher price than SlideShare, in India, on less invested capital. Way to raise the bar Lalit Patel)!

Two startups are educational institutions: Startup Village (co-founded by Vishnu Gopal, the first engineer who worked on SlideShare) is an incubator where you can get a degree while starting a company. Holberton School (co-founded by Sylvain Kalache) is a 2-year full-stack engineering school with no teachers and a project-based curriculum based in downtown San Francisco. SlideShare always had a strong educational component, so this theme makes sense to me, but it is still pretty amazing.

Then there’s the Octopus Watch, an icon-based scheduler and watch for young kids that is currently doing amazing on kickstarter and was co-founded by Omar Alouf. Your kid wants one. And there’s PingPad (founded by Ross Mayfield, who was VP of BizDev at SlideShare). It’s a mobile app that allows users to easily author documents together. Of course the founder of SocialText would want to have another swing at document-based collaboration! Even SlideShare’s first accountant now has a startup: an ecommerce site with a focus on recycled furniture.

We live in amazing times where smart engineers with small amounts of capital can build great things. I can’t wait to see what the SlideShare diaspora makes next!

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!

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!