Dennis holds weekly office hours where anyone at the company can meet up with him and ask questions or voice concerns. In my first month, I met with him a couple times and asked him questions about how he raised capital, his relationships with investors, and his experience with startups. After our first meeting, he let me know that I could grab coffee with him anytime. Foursquare really seems like a small startup despite there being 120 employees.
In response to some questions below about how snippets work, it is not necessary to read the entire company's snippets. It is a Twitter model where you subscribe to people's feeds. I'm following the exec team, my manager and other guys on the web-client team, and a couple of my other friends.
I saw that some comments about wanting to work for Foursquare, and I just thought I'd leave a reminder that we're hiring =) https://foursquare.com/jobs/
A. The importance of overcommunicating.
Funny... I've had a friend who's been marked down at multiple companies for 'overcommunicating' - things like reiterating the todo list from a meeting out to everyone, and including people who couldn't be there but would be impacted, emailing a group with a question and to make sure everyone understands what the impact of XYZ will be. Most people hated it. Well, I was fine with it - I think there should be more of it, and I don't think most people really grok that in knowledge work, that's all you've got - communication. Making assumptions or ignoring/forgetting to notify some parties of XYZ have huge ramifications.
"Quit sending so many emails!" is about all he'd generally get. In at least one case, I suspect it was more about control of information than anything else - when too much info gets to too many people, it's harder to claim plausible deniability.
CC'ing a group "just to keep everyone in the loop" is overcommunication. Pulling out the details that are useful for the whole group, if any, and then sending followups with additional details to a subset of people is the effective way to do it. It's a lot of work and it's why so many people who effortlessly handle in-person communication have trouble with written/broadcast patterns, they just aren't used to putting the extra work in.
What I'm going to miss the most when real journalists aren't around anymore are the long-form articles and profiles that obviously took care and several interviews to craft. For example, the recently HN-featured profile of Jack Dorsey by Wired's Steven Levy:
But our discussion is sidetracked when the proprietor, Vincent Fung, starts a long and complicated explanation of the various tea options. Dorsey—like Jobs—is interested in Eastern thought, and after listening to a detailed rundown of the exotic choices, he approves Fung’s suggestion to try a dark and musty chunk of Pu-erh tea from China’s Yunnan Province. A few minutes later, Fung appears at the booth with a deep wooden tray and begins a carefully choreographed ceremony, pouring a continuous stream of hot water over tiny cups. Then he pours water on top of a lid that partially covers the bowl containing densely packed cakes of tea. Dorsey watches the ritual and appreciatively touches his finger to a worn corner of the tray.
This is how an in-person interview is meant to be conveyed to the reader… not as a transcript.
You have no idea how much work goes into something like this.
See the disclaimer at the top where it says the interview was condensed? A lot of information is hiding behind that disclaimer.
That means that to get these 7 good questions, the writer might easily have asked 21 questions.
That means that where you are reading 1-3 paragraph answers, the original answer was easily 10 paragraphs, because people tend to ramble when you ask them about their jobs, even when they're NOT being interview by the NYT. (Here's an experiment for you: Ask a friend or colleague one of those questions, do not interrupt them, in fact appear very interested, and count how many minutes the answer takes to unspool.)
That means that when you're reading a nice orderly progression of thoughts, the writer probably had to take bits and pieces from different answers because the interviewee thought of something later to append to the original answer, or emailed a clarification later, or reminded himself of something.
That means when you don't see words like "uh" and "um" and "like" and "I mean" and "I think" and "you know?", and when you don't see sentences that trail off into nothingness, and when you don't see run-on sentences, and when you don't see non sequiturs, that's because the writer has carefully removed them.
That means the writer doesn't mention that it took three hours, easily, to transcribe a 45 minute sit down, and more time for the follow up to clarify and fact check words that were mumbled or inaudible and not in the notes.
You don't want to call something like this "sloppy" unless you know what actually goes into it. You know how non-programmers often assume that very simple, easy-to-use software was similarly easy to make? How they don't think about the edge conditions that turn something that SEEMS like an easy two-week project into a three month project (http://www.joelonsoftware.com/articles/fog0000000356.html)? You know how people around here are always saying that non technical people make bad tech CEOs because they don't understand the inherent and often hidden challenges of writing code? Well, other fields are like that too, including journalism.
(Disclaimer, I write these sorts of Q&As myself.)
I got to see this process first-hand when he covered Weebly for Newsweek. (http://www.thedailybeast.com/newsweek/2007/05/20/meet-the-ne...).
It was an absolutely incredible experience. You met with the guy a few times, talked with him pretty openly about what you're doing, and he magically weaved a captivating story line out of it -- making everything sound way more interesting than you could ever hope to make yourself sound.
I'm sure there are a decreasing number of long-form journalists who take the time to research their story, but it's also worth noting that there just aren't that many journalists as talented as Steven Levy.
It's always funny when someone goes all New Journalism and stuff, but it's not always preferable. I liked the no-nonsense format for the interview in this particular case - as, no disrespect to Foursquare, I don't really care about the founders. I do find the company itself interesting, though.
I'm also happy to answer any questions anyone might have about foursquare culture.
i've worked at high-profile startups with founders who are very media-visible before and dennis is pretty special in my opinion. he seems to genuinely believe that all of us employees are important to making foursquare the best product it can be.
The only negative anyone ever mentioned isn't really a secret, and some people consider it a positive. They have always been pretty open about not wanting to sell the company, which might be great (Facebook was the same way), and is fine if you already have money, but reduces the chances your equity will be worth $100k to $1mm or so; it may increase the expected value (due to a lower probability but huge success event). It does mean the company is less likely to get bought by a company which marginalizes the product and team, too.
These are such great ideas. I get jealous when I see articles like this as I have never had the privilege of working in such an environment. Of course as the company gets bigger it is going to be tough stopping fiefdoms and silos but they are surely on the right track.
Disclaimer: I'm friends with the founders.
When you have 20? 100? 1000? The number of snippets one has to read goes up linearly as the company expands for each employee. That means that waste goes up geometrically for the entire company.
And forcing each employee to read from a few select people will never scale either. Soon you will want to add the head of research and then the head of HR (or just the HR guy, if you only have one) so that you can tap into everybodies network for recruits.
For a large company: create team alias, email it on Fridays.
Not that hard.
You could subscribe to a keyword, and pick up any snippets that mentioned it.
As someone who was running a service that could get in the way of engineers doing their job, this was a great way to get honest, grassroots info.