Answer by Yee Lee:
Facebook calculates a "social closeness" score for every pair of nodes in its social graph. They use this social proximity score to rank each person's friends and this ranking is reflected throughout the site — it's used for determining which people's posts show up in Newsfeed, which mutual friends are shown on Profile pages, which people's Likes and social ads are shown in the right rail, etc.
Since the FB social graph changes every day (e.g., as people add new friends), the social proximity score needs to be updated regularly.
The actual scoring algorithm itself is proprietary to Facebook, but is likely based on traditional social graph distance metrics developed in academia. E.g., Facebook might take into consideration factors like:
- # of friends in common that each pair of people shares (e.g., the number of unique 2-edge paths between any two nodes in the graph)
- the total # of friends that each person has (e.g., if Person A only has 20 Facebook friends and shares all 20 with Person B then A might be considered "closer" to B than, say, to Person C who has 2000 friends and shares 20 mutual friends with A)
- # of interactions between a pair of people (e.g., if Person A and Person B regularly share mentions/comments/likes with each other, then A might be considered closer to B's friends than, say, to Person C's friends where A and C never comment/like each other's posts)
- the type of interactions between a pair of people (e.g., if Person A tags Person B in a photo, that might be a stronger signal of closeness than just having some friends in common)
- pace and recency of interactions between a pair of people (e.g., if Person A has recently checked-in to a location with Person B, that might be a stronger signal of closeness than if they checked-in a year ago and haven't been seen together since)
There are lots and lots of graph structure and interaction signals that can go into a social proximity score! Note that similar techniques/algorithms are utilized by just about every company that works on social apps and communication products. E.g., Google utilizes this type of scoring/ranking when they suggest email addresses to include in the "To:" line of a GMail message. E.g., Zynga utilizes this type of scoring when they suggest friends to invite to a social game.
Startups are hard. And hiring great technical staff members may be the most difficult and important challenge in a startup.
So how do we hire the right people? Start with the end in mind — i.e., have a clear definition of who you’re looking for before you begin. Most hiring managers start by trying to breakdown the technical “do-er” roles in a company (engineering, product, design) into lists of specific knowledge or behavioral requirements. I don’t think it’s enough to just find people who can check the boxes of “knows Cocoa” or “expert with Photoshop” or “wrote Pivotal Tracker stories”. Founders and early-stage startup team members need to have an extra dose of character because they’re not just building a product, they’re forming a culture. Here are four characteristics to look for in each technical role that has a direct hand in building a startup.
(Note: This post is a follow up and extension to http://framethink.wordpress.com/2013/02/25/five-behaviors-of-awesome-engineers/ with many thanks to Laura Klein and George Lee for inspiration and feedback.)
- Craftsman — pride and deep understanding of work
- Goalie — defender of the codebase, uses test-suite as a protective shield
- Macgyver — builds the minimum viable version quickly and then iterates forward
- Coach — mentors others and is coachable
- Artist — weaves beautiful, delightful, enticing designs into and throughout a product
- Literalist — must get ideas/concepts down on paper or screen-pixels in order to understand and discuss them
Eye of Sauron — notices 1px differences in baselines and kerning
- Toolmaker — creates guides, libraries, templates, etc. for other team members to follow
- Shortstop — covers all the gaps, thinks through corner cases and potential dead-ends
- Occam — cuts flows like a razor, down to the most simple path
Empath — guided by deep caring and viscerally feeling the pain of the user problem
- WeebleWobble — absorbs input/feedback; bounces back from any knock, converting it into action
- Guru — customer use-case and domain expert
- Mad Scientist — sees the big world-altering vision, plots experiments to probe the path forward
- MC — confident and persuasive public presenter
- Logician — skillfully works the development process to deliver on-time, on-budget
Answer by Yee Lee:
Of course I regret it, how could you not?!
I was at PayPal pre-IPO and had a chance to work withand . Back then, PayPal's product development process was very Product-driven and as a young PM. I loved that about the place; it was an exhilarating job/experience.
When I was getting ready to leave PayPal in late 2005, I remember having a conversation with Steve about product management positions at YouTube. He said, "Y'know, we didn't really like the way product managers and engineers interacted at PayPal. So here at YouTube, we want engineers to lead product decisions. So we kinda just want PM's to take notes on what the engineers decide and make sure that stuff gets done."
I mulled that over, thought that sounded terrible, shook my head, and told Steve that maybe we should chat again when he was ready to bring on-board a *real* product manager. I WAS (maybe still am) SUCH AN IDIOT! I had an opportunity to talk with the founders of YouTube about being one of the first (if not the first) PM and I didn't even engage in the conversation because I had held precisely one (1) product management role before in my life and therefore assumed I had it all figured out… Sigh.
In hindsight, I think careers in Silicon Valley are so dependent on luck, timing, and who-you-happen-to-know that a lot of us probably have gone through these kinds of near-misses. In fact, I think that's one of the things that makes the Valley special — the business ecosystem is connected enough here that just about everyone knows someone or has a friend-of-a-friend that experienced major personal career success. That proximity to success creates a lot of readily available role models and exemplars that drive the aspirations of the whole Valley. It's not just the top universities, the long tradition of technical innovation, and presence of venture capital or other legal/support functions… Other countries have tried bringing all those factors together into "innovation hubs" and not been able to replicate Silicon Valley. It may be because they're missing the social-connectedness and success role models that we have!
I think the regret of a few missed-opportunities is a small price to pay for working in the greatest innovation center on the planet!
Answer by Yee Lee:
Remember: the purpose of a backlog story is just to cause the right conversations between team members. So, it's difficult for an outsider to gauge the "goodness" of a backlog just by looking at the story headlines.
In some cases, 1-liner story could be all you need to remind team members of a whiteboard conversation they had. Usually, though, you'll see a lot of back and forth interaction between team members while they groom a story as it moves up the backlog. E.g., if you follow a backlog over several sprints, you should see:
- A story starts off in the Icebox or low down in the Backlog as a 1-liner or a very simple description of the desired user experience
- As the story moves up towards the top of the Backlog, you may see, mocks/attachments, implementation notes or sub-tasks get added to the story — indicating that the development team has been grooming the story and thinking about how to implement it
- Ideally, the conversation about "how" will feedback into the "what" of the story and you may notice that stories with broad scopes get broken down into multiple smaller stories that will each get prioritized.
- By the time a story gets close to the top of the Backlog, it should meet a few criteria:
- Granular enough that a single individual can implement, e.g., no intra-team dependencies for a single story.
- Developers have discussed/groomed sufficiently so that they understand exactly what needs to be done, e.g., if you ask multiple team members what the story is about, you'll get identical answers
- Each development team member has a good enough idea of how they would implement the story that they can give a confident estimate. Side note on story estimation: development team members typically are pretty good at estimating story points up to the equivalent of a day's worth of work. Any points estimate that indicates multiple days of work should be taken as a red flag of story uncertainty. High-performing teams will take the time to do multiple rounds of estimation, breaking down stories until they all fit under a low points-ceiling.
Here are a couple public examples of backlogs for on-going, active projects…
The agile backlog used to build the Jira Agile app (how meta):
And if you google around for "public backlog" (in quotes), you'll find other examples.
I loved reading about Kapta’s insightful software service that helps organizations align day-to-day actions with strategic objectives and wanted to revisit the topic of SMART objectives that I wrote about back in 2007.
Kapta’s CEO, Alex Raymond, has some great insights about what makes for a good organizational objective. Specifically, I like his notions of:
- Ambitious — “The goal should be bold and exciting, something for people to rally around. Not impossible to reach, but still aggressive.”
- Inclusive — “Everyone in the company needs to understand how they contribute to each goal. Otherwise, employees can lose motivation and clarity.”
Adding those notions to the SMART framework, one would obtain “AI SMART” objectives:
- Ambitious — aim high
- Inclusive — everyone can contribute
- Specific — concrete, actionable
- Measurable — we’ll know if we hit the mark
- Attainable — realistic to achieve
- Results-oriented — produces a meaningful impact
- Time-bound — by a certain due date
I’m going to start using this framework for assessing goals. It’s the start of a quarter… I hope this is helpful for all of you out there setting quarterly objectives and OKR’s!
I’ve been using a Nexus S (now updated to Android Jellybean 4.2.2) and an iPhone 5 (now at iOS 6.1.2) on a daily basis for a couple months now. Much has been written comparing Android and iOS already, so I’m just adding my anecdotal experience to the wood pile. I’ve found myself increasingly thinking of the Nexus S as a “work” device and the iPhone as a “play” device. Here’s why:
Android for Work
- Google integration — I rely on Google apps like Gmail, Google Calendar, and Google Drive extensively, both personally and for work. It’s super easy to sign into an Android phone with multiple Google accounts. Once signed in, all email, calendar events, contacts, and docs associated with your Google accounts immediately become available on the phone.
- Voice dictation — Google-powered voice dictation is incredible. I find myself often dictating entire emails now — it’s so much faster than thumb-typing on the phone!
- Swiping keyboard — the swiping keyboard that’s built into the latest versions of Android is much more accurate (and fun to use!) than the regular touch keypad. I discovered it accidentally when one of my fingers slipped across the regular keyboard once and haven’t gone back ever since. Between swiping and voice dictation, the Nexus S has become my preferred mobile device for text-entry while on the go.
- Google Now — a question I wonder nearly every morning is: “should I take 101 or 280?” to commute to work. Google Now proactively figured out my commute routes and now one of the notifications at the top of the Nexus S every morning is an alert from Google Now that tells me which is the best route to take this particular morning. I love that. It’s magical and useful to have my mobile phone smartly offer assistance.
- Portable wifi hotspot — the Nexus S’es built-in portable wifi hotspot turns on really quickly and has been a more reliable connection for me than the iPhone’s wifi tethering. I’ve been using both devices on AT&T’s 4G network, tethered to a Macbook Air — the Nexus S would often provide hotspot connectivity in places where the iPhone would refuse to connect (for some reason, the iPhone refuses to allow tethering while in “4G” mode, not “LTE”).
- Aggregated notifications — the way Android aggregates and displays email notifications in the “windowshade” is super useful. I like being able to take action (like archiving an email) right from the windowshade.
iOS for Play
- Camera and camera apps — the iPhone 5′s tap-to-shutter lag is barely noticeable and I think the native iOS camera app does a good job of handling light-metering by tapping on dark/light areas of the viewfinder. The iPhone camera seems to take better photos and videos, in general, than the Nexus S. Also, my favorite video and camera apps are all on iOS, too: Videokits, Facebook Camera, Manga Camera, Looker, Instagram, Snapseed, and Photosynth, etc. I also really like the “swipe up” to go into camera mode
- Shared Photostreams — my parents and in-laws have iOS devices and want to see the latest photos of their grandkids; what better way to share than with iOS’es built in Shared Photostreams? I find that I share way more photos this way than I do through social-network sites… I tend to pick and choose which photos to share on Facebook or Twitter because I don’t want to bombard online friends/followers with dozens of pics taken at, say, a kiddie birthday party. But the grandparents are more than happy to receive all 50 photos in a Shared Photostream — they “like” every single one! :-)
- AirPlay — this is really the killer app of iOS for me: being able to AirPlay any content (whether it’s photos/videos from the camera roll, a YouTube video, a song from iTunes, or a Netflix movie) from the phone to a bigscreen TV. The seamlessness of the experience is awesome. I love how the iPhone has become an integral part of the living room experience.
- Games — there are still just a ton more games and apps available in the iTunes App Store than on Google Play. Most of the big titles from Rovio, Electronic Arts, or Zynga are available on both. But many educational and kids games are still only on iTunes App Store. That makes a critical difference on which device gets shared with kids on the couch.
So, net-net I’m using the Android device more for day-to-day productivity and the iOS device more as a media and gaming device. In a way, this actually lines up with Steve Jobs’ reported focus on taking over the living room. Both the iPhone 5 and Nexus S are beautiful devices with well-executed operating systems. Looks like both Apple and Google are hitting their strides, respectively, though I doubt that they’d intended to segment the market for mobile OS’es by work vs. play… Still it seems to have come out that way for me, personally!
Anyone else “dual-holstering” both and Android and iOS devices these days? What are your thoughts?
I recently joined TaskRabbit as VP Engineering and the experience has reinforced lessons learned from prior startups about the importance of having a systematic way to recruit, retain and promote great engineers. One way to help recruit, retain, and promote more effectively is to identify and define a consistent set of behaviors that the company expects of engineers. I’m constantly amazed at how many companies fail to do this for their technical staff.
When it comes to defining explicit objectives or desired actions, it seems like many companies take the time to specify those kinds of expectations for marketing, sales, or product management team members. But when I ask engineers at other companies how they know if they’re doing a good job, I often hear answers like: “we’re generally supposed to kick ass and ship code” or “we just do what PM’s tell us to do.” IMHO, having a group of prodigious coders or friendly team-players on the engineering staff is a good start, but not sufficient. And leaving engineers with ambiguous or undefined company expectations borders on neglect!
I’d like to push more companies into defining clear, specific expectations for how they’ll assess engineers at all points in their career life-cycle — from being pitched as candidates, to being on-boarded as new hire, to getting rewarded as a high performer (or being counseled out). Ideally, the way a hiring manager describes an engineering role to a recruit should match the role expectations that the company places on that engineer once they’re on board. And the way promotions happen should further reinforce those behavioral expectations.
To give an example, here are the five behaviors that we expect all TaskRabbit Engineers to exhibit:
- Culture Fit — TaskRabbit is driven by a very lofty vision and company values. We take those really seriously and folks don’t tend to stick around at the company if they don’t visibly buy into the vision and values; even if they’re brilliant at their particular functional role.
- Craftsman — We want engineers to really understand the underlying mechanisms that their code relies on. The majority of TaskRabbit’s codebase is in the form of Ruby-on-Rails apps. Mature Rails developers will appreciate just how easy it is to get yourself into hot water by including gems without really understanding what dependencies those gems are creating under the hood… Whenever we can’t find a gem that does exactly what we want, in the way we want, we take pride in developing our own gems and contributing them back to the Rails community, e.g., makara, storehouse, sudo.js, and more.
- Goalie — We don’t have a QA team, so our Engineers are the first and only line of defense against bugs. We expect engineers to write their own feature tests and bugfixes, to deploy code only after integration and acceptance testing, and generally to think a lot about how code might break. That kind of goalie defense against bugs and regressions is an important part of an engineer’s job at TaskRabbit.
- MacGyver — Like the TV show character, given a tight set of timelines and resource constraints, we expect engineers to be able to successfully identify the minimum-viable development investment that will make a meaningful impact for users. This is really another way to say: we solve the classic Time-Quality-Features tradeoff by de-scoping/decomposing features. We explicitly are unwilling to compromise on time or quality (i.e., we deliver on a pre-set weekly sprint cycle and we hold the quality bar really high for ourselves). So, within a given sprint, we always focus on paring down to the smallest possible unit of customer value.
- Coach — TaskRabbit’s initial web and iOS apps came out of consulting engagements with Pivotal Labs, where we did a lot of pairing. Coaching and mentoring each other has become an important part of our engineering practices and we really value people who are willing to actively teach their colleagues and learn from each other through 1-on-1 pairing as well as All-Hands meetings. We specifically like to see engineers standing up in front of a crowd, talking about and demo’ing their work.
Every new recruit hears about these five expectations so they can make an educated decision about what they’re getting into at TaskRabbit. Our engineering team members talk to each other about their jobs using these terms. And these five behaviors are baked into our self-assessment and peer-reviews.
By enumerating these five desired behaviors and weaving them all through out TaskRabbit’s engineering practices, I’m trying to create a more consistent and reliable way to recruit, retain and promote an A+ team.
Feel free to borrow these if they’re helpful… YMMV, of course, with transplanting these expectations into your company’s particular culture. But I think the most fundamental point is to put some thought into defining a consistent set of behavioral expectations for your technical staff.
Thoughts? Comments? Let me know!