We all know that the three most important determinants influencing the value of homes are location, location and location. Well it’s true of all real estate, including space on the trade show floor. We moved our booth at Web 2.0 Expo early this morning to a middle aisle with more foot traffic, based on our observations from yesterday. When we selected our booth initially, it wasn’t obvious from the floor plan that our booth faced a wall. We thought it faced “in” to the show, which is what the booths on the opposite perimeter do as well. We had a number of booths to choose from and what looked like bad booths because they were at the back, ended up being good ones because they were along the lunch/break/rest area where a lot of people congregate.

Now we’re in a middle aisle, near our friends from Sprout and across the aisle from Atlassian Software. I think the takeaway for people considering exhibiting at a trade show is to call the coordinator and try to get a feel for what the floor plan doesn’t convey. Ask questions. “Which direction will this booth face?” “Where is the lunch area?”

What does it mean when blist says that we want to democratize working with data, breaking our dependence on DBAs? Do I think the DBA profession is going away? No, not entirely, but their numbers will be fewer and their challenges will be greater. Complex systems will still require a DBA - either to model a 75 or 100 table schema or to keep a large database running. The democratization we’re talking about is empowering mainstream people to organize data models comprised of 1, 2 or 3 tables.

For example, an applicant tracking system can be simplified to two primary tables - applicants (people) and interview results. The two fundamental entities in a recipe blist are recipes and ingredients. Why shouldn’t a mainstream person be able to design data structure for these? Of course, they should.

One parallel way to think about this is to think about the demise of professional sportswriters. Decades ago we relied on sportswriters to tell us the basic facts - the outcomes of the games. As a youth I was a voracious consumer of baseball box scores in the newspaper. The next morning was the earliest I could get the details of the prior days games. Obviously today access to the outcomes and details of games is pervasive and ubiquitous. There are sites that have realtime boxscores - I can “watch” a game play by play if I want to. There are hundreds of bloggers who “live blog” key plays throughout the duration of games. One casualty of the ubiquitousness of this information is the ordinary sportswriter. We no longer rely on sportswriters to inform us of the basics. Sports writing has been democratized. Are sportswriters extinct? No, but their numbers are fewer and the ones who are able to survive do so by offering much more than the facts. Frank Deford thrives as a sportswriter because he analyzes, evokes, provokes and entertains. There will always be a need for the Frank Defords because very few of us can as eloquently tell a yarn around the subject of sports.

DBAs will still be needed for those things mere mortals can’t do with a database. But for your average, ordinary tasks involved with organizing data, I’m convinced we’ll all do that for ourselves.

We launched the blist service in beta in late January of this year. Since then we’ve been managing what I think of as the five tensions competing for our limited software development resources. They are allocating development budget between:

1) fixing bugs thereby making the application more stable

2) improving performance

3) adding new features

4) instrumenting the application

5) automating operations

You can’t ignore any one category for too long. Focus only on new features and users grow impatient waiting for bugs to be fixed and performance to be improved. Ignore instrumentation and it’s harder to know what areas of the application need more work and it takes more effort pulling together metrics to run the business. Ignore automating ops and your valuable software engineers end up spending too much time performing manual system administration tasks.

The right solution is to invest in each category. The difficulty is in figuring out the right ratio. Candidly, we haven’t figured it out either, otherwise I’d tell you. What’s most important is to constantly reevaluate the service and asking what area needs the most investment and have a development methodology that allows you to be nimble and change priorities often. Analyze the data. Ask your users. Read the entries in the community forums. Adjust. Apply. Measure. Adjust. Apply. Measure.

We’d love to hear from you. What must-have features are missing? What’s working? What’s not? What’s too slow. How can we make blist better for you?

This morning I had an informal discussion with a candidate who’s thinking about leaving Microsoft and joining a startup. He asked the question “How do you avoid adopting a Microsoft culture?” In hindsight, the basis for his question makes a lot of sense. I left Microsoft to start blist. Our website and many of my introductory emails to prospective candidates includes a statement that says something to the effect that “our engineers are mostly ex-Microsoft and ex-Amazon.” He also recognized that one of our board members is from Microsoft. So it’s understandable that he would think we’d have a Microsoft culture.

In that he has that question, maybe others do too. So here’s my answer, for the benefit of anyone and everyone who reads this post.

blist doesn’t feel anything like Microsoft. I only spent a year there and one of the reasons I was anxious to leave was so that Microsoft didn’t change me too much. We are conscientious about not introducing unnecessary layers of management or bureaucracy. Our first employee, a software engineer, celebrated his first year anniversary with blist recently and commented that it was the best year of his career, in large part because of the pace, energy and lack of meetings and bureaucracy. We have no program managers (yet). We have no SDETs (yet). Those roles won’t be vacant forever, but now is the wrong time for them at blist. Soon we’ll add a couple more engineers, and at that point one single, solitary program manager makes sense. I’m not opposed to program managers or SDETs, but the ratio needs to be something like 6:1:1 not 3:2:2 like at Microsoft.

At Microsoft, teams are built top down. I prefer bottoms up.

Unfortunately, the power of political persuasion is necessary to succeed at Microsoft. At blist we value ideas, not politics. A good idea will get done. A bad idea won’t. If someone suggests a bad idea and we discover that in discussion, there’s no animosity or negativity. If someone suggests a good idea, he or she didn’t win - the idea did. We’re democratic, but it’s not a democracy. By that I mean we discuss big ideas but not the little ones. One of the benefits of having smart people is they usually figure out the right thing to do, including knocking down the the little issues and surfacing the big ones.

We don’t have very many meetings at blist. The only recurring ones are our sprint kickoffs and recaps. Other than that, meetings are usually spontaneous and don’t usually take place in a conference room. We usually just talk through an issue in real time. If you need help with something, wouldn’t you rather have immediate help instead of scheduling it for next Wednesday at 3:00? By the way, we never schedule meetings around people’s schedules. If you’re here when we meet, feel free to join, but if not, that’s OK too. We’ve never had a mandatory meeting. If the topic interests you, attend. If it doesn’t or you can’t add value, don’t attend. The result of this is that meetings tend to be quick and engaging. No one checks email on their iPhone. People don’t bring their laptops. It’s a discussion. Almost always something gets decided and you leave the meeting feeling like something was accomplished.

Our development approach is a blend of what you’d find in a startup and what you’d see at Microsoft. We do week long scrum sprints that are very agile, nimble and quick paced. We apply some self imposed rigor and discipline around our engineering practices. For example, you can’t check code into subversion without a formal code review. Those reviews aren’t cursory. They’re in depth. Good questions are asked. Algorithms are scrutinized. Teamwork emerges. I walk through the front door of our office 3 or 4 times a day and almost always I see a code review taking place, with two engineers sitting side by side, one pointing at the monitor, walking the other through the code. It’s refreshing to see. Physically our environment is communal. Sorry Joel (on Software), we prefer to work in an open area where we can communicate and collaborate freely; we don’t want enclosed offices at this stage in our life cycle.

Finally, two words are entrenched in our culture differentiate us substantially from Microsoft: proximity and diversity. The former - proximity - has to do with how close we want to be to our users. We want that proximity - to hear directly from people using our software about what’s working and what isn’t. The latter - diversity - is about how we define our roles. We like broad diversity in what we work on. Everyone wears a lot of hats. We’re all entrepreneurs. We aren’t constrained by the title on our business cards.

So if any of you have shied away from blist for fear its culture would feel like a mini-Microsoft, fear not.

In the late 90’s I headed up technology for an investment banking firm doing mergers and acquisitions (M&A). Our success attracted Smith Barney and we were acquired in 2001. I learned a lot about compliance and regulation while integrating into Smith Barney. Shortly after 9/11, the Patriot Act went into full effect. As a bank, we were required to know who our customers were. The regulation was called ‘Know Your Customer‘ - KYC for short. I won’t try to remember all the details, but essentially KYC meant that you had to have some sort of identification process and a “file” on each of your customers. It was designed to avoid anonymous banking transactions from funneling money to the bad guys.

Today I encountered ‘Know Your Customer’ in a different context. Late last week an employment offer was accepted by an individual who’ll be joining us shortly. As we do with all new hires, at blist we buy whatever gear you need to do your job well. When a candidate accepts a position, I just ask them to send me the laundry list of equipment they need to be here the day they show up. There’s no judgment. Do you want a Mac? Fine. You want a PC running Vista? No problem. Do you want a laptop with VMware? Ok. You need a 24″ monitor? That’s fine too.

The new hire wants what looks to me like a pretty vanilla, standard issue HP laptop. He courteously sent me a link to buy it online from HP. When would you think most computers are purchased? Yep, you guessed it - just before a new hire joins. I know this in part from my job heading up technology at the M&A firm. Twice we bought 400 PC’s to re-equip everyone with new hardware, but other than that we would always buy whenever we hired someone new. The PC manufacturers including HP have to know this. So how disappointing is it that HP’s online ordering system tells me that the vanilla, standard issue laptop I’m ordering will be released to build on 4/21/08 - two weeks from today. Adding for build time (2-3 days) and ship time (2-3 days), that laptop isn’t going to arrive within the customary 2-weeks notice period that people give when leaving their old job.

Maybe it’s just me, but it seems that the table stakes in the PC business are being able to have a computer delivered within 10 or 11 of days of being ordered. It seems really obvious. If most people give two weeks notice and most companies buy PCs when new employees join, then PC manufacturers would figure out how to hit this goal.

When you try to buy something on Amazon on 12/20 it tells you, “You have 1 day, 13 hours and 9 minutes to order if you want to receive your gift before Christmas.” Amazon gets KYC. HP not so much.