Despite moving to Austin, my allegiance to the Baltimore Ravens remains as strong, and maybe stronger, than ever. It’s been an exciting offseason with lots of power moves and now training camp is in full swing.

For third year Quarterback Joe Flacco, this appears to be his coming out year. The Baltimore Sun ran a story about him the other day noting that this offense is now Joe’s offense. He’s taking command. He’s inheriting responsibility. He’s taking ownership.

He’s taking more command and making more adjustments at the line of scrimmage. He’s looking to become more effective in the red zone. And he’s tutoring new backup quarterback Marc Bulger when everyone thought it would be the other way around.

“I want to be able to just run the show and go up and down the field, blow out points on the board and come out successful,” Flacco said after a 75-minute practice featuring rookies and veterans coming off injuries. “That’s what it’s all about.”

That’s the mark of a leader and something that anyone who aspires to leadership is required to do at one point.

Since being in Austin, I’ve been exposed more and more to the startup life – something I used to live in as the Director of Technology at b5media, a company that used to be a blog network but now is something, well, frankly, unidentifiable.

As a result of my new exposure to a startup culture, I’ve already talked to a few companys to get a feel of how they do business. It reminds me of those early days at b5media. Four founders, making decisions by committee, and hoping for the best. Sometimes consensus was a blocker to real innovation.

This mode is common for early companies. Small group. Everyone needs to be on the same page to do anything. And they suffer from paralysis of no decisions. No one is willing to take charge and lead.

At b5media, once we took our first round of VC money, Jeremy Wright, became the CEO. He was forced into a role of trying to get consensus but not suffering from the paralysis of required consensus. Many times, those of us in those leadership roles diverged in opinions and advocated different directions. It was Jeremy’s role to distill this feedback, foster the discussion, and then ultimately take ownership of the situation and make his call.

Sometimes it was the right choice. Sometimes it wasn’t.

Imagine this. It’s a third and long situation. The Ravens offense is backed up on their own 10 yard line due to an unfortunate series of downs involving an incomplete pass and an offensive holding penalty. They are down by 13 points with 6 minutes left in the game. The safe call, and the one called in to Flacco by Cam Cameron on the sideline, would be a slant play down the middle to a slot receiver or tight end.

As the offense lines up, Flacco sees the defense showing blitz and crowding the middle. Understanding from experience that this is a situation fraught with disaster and the need for a big breakout play to energize his offense, he calls an audible. Ray Rice on a draw play – bait the offense to continue to see the pass, but then destroy them with an off tackle run. Rice runs for 24 yards and gets the first down and better field position.

If it wasn’t for the leader having the confidence and insight to see the minefield upon him, he might just go with common wisdom or, more naturally, the wisdom of his advisors. However, he decides that he has the information he needs to make a big play, owns the call and gets a win.

While it’s common for young startups to operate on consensus, sometimes it requires someone with enough balls to make a tough call and own it. A good team will support that and have their leaders back regardless. If they don’t, they shouldn’t be on your team.

Photo credit: Keith Allison

It was very interesting. Back in May, my friend Pete Jackson, who works for Intridea, started making a point of introducing me over to Twitter to one of his friends in whatever city I happened to be travelling in at that moment.

It was in this way that I met Sean Cook, the manager of mobile integrations at Twitter in San Francisco and, when I was in Austin visiting in May, he made sure that I met Aaron Scruggs of Other Inbox who has since become a pretty good friend.

It was after that meeting with Scruggs in May that he connected me to one of the smartest guys I’ve ever met, Jason Cohen. Jason is one of the two founding partners at Capital Thought, an Austin-based incubator. Jason has also built several companies and parlayed two of those into healthy exits. I’ve come to have a tremendous amount of respect for his technical and business savvy.

Jason described to me the concept for a business that he was working on along with Cullen Wilson. A premium, WordPress platform that would cater specifically to the customers who want to make sure their blog is always taken care of from a maintenance and upgrade perspective, but also would offer significant value adds that nobody else is providing in a WordPress-optimized environment.

I’ll get to what all those buzzwords mean in a minute. Stick with me.

We started talking about me joining up with them to take this idea to the bank. Shortly after moving down here to Austin, I joined the team and we’ve been working hard over the last couple months to get to the point where we could reliably take on new customers and talk about our idea publicly.

Today is that day.

So, you’re still probably wondering what the hell WP Engine is and why it’s important, right?

Let’s talk security for a minute. There have been significant security “incidents” in recent months. Most people on the outside simply see “WordPress hacked! WordPress hacked!” – I’m looking at you Chris Brogan, Robert Scoble and Frank Gruber (Techcocktail). In the WordPress community, we know the real issues in these cases were not WordPress but the hosts that the blogs were on. Still, people saw WordPress hacked.

We take this very seriously and have partnered with a provider that has multiple levels of security including Intrusion Detection Systems (IDS) outside of our boxes. We have gone to great lengths to keep our customers connecting to us in very secure ways and keep a close eye on the activity happening on our boxes. This is all very important because if an attacker could get through our outside defenses, chances are they couldn’t do anything malicious without us knowing about it.

Our infrastructure is also built with optimization and blazing, fast speed as a core expectation and deliverable. We don’t overload servers and have the means to see potential performance problems before they arrive. With our dual nginx-apache server configuration, we are able to handle sustained high-volume traffic as well as spikes that are the pain point for WordPress bloggers who suddenly get a story featured on a prominent site.

For the people who claim WordPress doesn’t scale… I call bullshit. We believe we know exactly how to make WordPress scale.

But we’re not just a hosting company. If we were that, we would be our competitors. We are also working on additional features such as “Curated Plugins” which are plugins that are entirely open source, that are popular or in demand from our customers and have been vetted from a security standpoint. These are plugins that we support 100%. This does not preclude customers from using other non-supported plugins, and we don’t dictate what bloggers can have on their blog as some of the other hosted WordPress solutions do. We just say, “Hey, if you use one of these, we’re gonna have your back”.

So last night, we were yukking it up about how PHP has re-invoked the GOTOoperator, a programming mechanism that, we thought, died with the BASIC programming language of yore. Coding in BASIC was very procedural and not very rich in its abilities.

One of our number suggested that PHP, since they regressed so badly with the GOTO operator inclusion, should also adopt line numbers in code as well. :) This conversation devolved into all the cliché buzzwords of our time and eventually, it was suggested that what we really need is a “BASIC Cloud Framework API”.

Putting aside BASIC, which is not really practical or desirable, the concept of a Cloud-based Framework API, whatever it actually is, is not all that undesirable. If you think about it, we already have a Cloud-based API for APIs (yes, I realize this is very meta) with the super-cool Gnip which we covered last year when they launched. Social services channel their data through Gnip and Gnip provides a single API layer for data access. And it’s built in the cloud.

Similarly, up until a few years ago, Javascript was painful to write because developers had to write code for all the browsers and all their nuances. That was before Javascript libraries — or APIs, if you will — like Prototype or jQuery came along providing the developer with a single layer of javascript programming that would work seamlessly on all browsers.

The concept of single layer APIs is not a new one. Why can’t we have an API for cloud-services as well?

Think about this. Right now, anyone wanting to build an application has three options. They can build out a server cluster or farm that physically scales and, by proxy, ends up costing a lot as physical hardware costs a lot. A second option would involve a virtual cluster made up of virtual machines. You still need hardware, but each server souped up with up to 32G of RAM can theoretically host tons of virtual machines all acting as a physical server. An entirely virtual solution is hosting applications in “the cloud”.

Cloud computing is not without it’s challenges. I’ve challenged the reliance on it in the past, and I still do. However, with cloud services like Amazon’s EC2, S3 or Google’s App Engine, it becomes entirely possible to not only store data in the cloud, but also run and maintain entire services in the cloud.

The problem is, each of them require different things. Amazon has a suite of developer tools that are needed to build against their cloud offerings. Google App Engine only supports Python, Ruby or Java.

There should be a way to abstract this development to a single layer — or API, if you will — to take advantage of this.

Laugh it up, chuckles. A cloud-based framework API is not all that ridiculous of a concept. The world once thought the earth was flat as well.

More surprisingly, the acquisition was something like Sixth Sense where you watched the movie trying to figure out what the ending would be just to be totally blindsided as the credits rolled. Yeah, it was that sort of satisfactory “ah, you got me” moment.

I have had a torrid relationship with FriendFeed culminating with a termination of my account, causing much angst and name-calling from the puppets who have pushed FriendFeed as the only way to have legitimate conversations on the web. From my perspective, and others, it was a noisy, troll-filled social platform that, though having good technical features like real time feeds, also provided an almost cliché approach to communication.

Where the web has become increasingly fragmented and dispersed, fans of FriendFeed often touted it’s aggregation platform as the end of disbursement, a concept that I disagree with. Such end of disbursement also marks an end to competition, if allowed, and a navel-gazing mentality that assumes nothing can be better. Competition in the market place is good, and I chose Twitter.

What this means to consumers is unknown yet. Facebook has a historic closed stance and, though opening up certain APIs such as Facebook Connect, and allowing developers to develop applications for Facebook, it still stands as a relatively closed system. In order to really engage with Facebook, you really have to be using Facebook itself or the mobile apps built for Facebook.

FriendFeed has a robust API that developers can access to distribute or repurpose the content within. It has failed in many ways by not providing a really great application ecosystem, but on paper, it is much more robust of an open system than Facebook.

Facebook has certainly taken pages from the FriendFeed book, however, making their newsfeeds real time, and integrating their “Like” feature. However, it still is not as quick or reliable, much less intuitive for the user.

In an ideal world, Facebook takes almost all of the real time, and “Group” functionality of FriendFeed and integrates it into Facebook. Lose the walled garden, and keep the API open for developers. Time will tell, however, as these two companies figure out how to be “In a Relationship” with each other.

More on this acquisition from other sources:

• TechCrunch: Facebook Acquires FriendFeed
• ReadWriteWeb: Facebook Just Bought FriendFeed
• Boomtown/Wall Street Journal: Facebook Acquires Non-Twitter, Oops, Friendfeed (Plus the Full Press Release)

Seven years ago yesterday, things got put in perspective real quickly. I was attending a morning panel session on raising capital at Accenture’s Reston, VA headquarters, organized by the Greater Reston Chamber of Commerce. The details of the panel have long since faded from memory. I remember local VC Don Rainey was on the dais — at the time running the VA office of Durham, NC based Intersouth Partners — because I was in the middle of asking him a question, when my wife Cecilia interrupted me (happens at home a lot; in public, not so much). She was managing the event, and stepped up to the mic to let everyone know “there’s been some kind of attack on New York,” and everyone had best just go and check on their families.

My recollection following that moment remains quite vivid. Very first thought (after the interrupting thing): what presence of mind Cecilia had, to quickly transition the context of the meeting to the important one — family — without causing panic. Then she and I immediately devised our plan: she would continue to try to reach our daughter in DC, while I would drive down to pick up our son at school. Come what may, our family would be together.

I remember how details of the attack were just trickling in over the radio — a plane or planes, one or both of Twin Towers — as we sat anxiously in our cars, crawling through the crush of cars trying to exit the multilevel parking garage. I remember the constant beeping of failed cell-phone calls from an overloaded system. I remember getting my son with me in the car, trying not to alarm him. I remember finally hearing that our daughter was okay.

I remember my heart going out to the thousands, and their families, who would never be okay.

What I was not thinking about were the consequences the terrorist attack would have on my startup at the time — client/server systems providing music and information in hotel rooms. (The hospitality industry sank like a stone after 9/11, as did our prospects for success.)

Then, at some time, days or weeks later, I remember an oddly comforting feeling of being united with people I’d never met.

Things had really gotten into perspective, for a while anyway.

Usually, a good launch product is the result of a perceived need. Or maybe a need not yet realized – it’s hard to say for sure. There’s some black magic involved in all that.

FriendFeed launched not long ago because there was an empty hole in Twitter – that was aggregation and conversation. FriendFeed figured out that, to be successful, it was going to target that emptiness in the highly popular Twitter experience.

Disqus and Intense Debate figured that, in order to be successful, they needed to target the missing piece in blog comments – that was reputation and reputation management across blogs. The two fight it out, post-launch, over which is going to differentiate it over the other.

In these cases, the timing of the launches was critical to the uptake. Twitter started experiencing significant problems and influential early adopters began getting itchy to be somewhere that scratched their itch.

Putting aside timing, the most important part of a launch is what. It’s feature-sets. It’s determining the balance between a fully developed roadmap of features and what is needed to “hook” early adopters and get them to stay.

Take Identi.ca, the new Twitter clone that is completely open source and is timely in that Twitter faithful are really, really close to burying the hatchet and simply abandoning it altogether. The timing could not be more perfect. Folks have been talking about distributing Twitter and relieving the strain of a centralized service at one time. Open sourcing the product does this, to a degree.

However, Identi.ca gets a big “FAIL” for its launch for a few very important reasons.

1. There is no coherent way to deal with “replies”. Folks used to Twitter realize that when there is a river of content, and that’s what Twitter is, there must be a way to manage conversations. There must be a way to keep up with followers who are talking to you. In my working with Identi.ca, there is no way to do that and, while that might be coming, it wasn’t there at launch. Very conceivably, I’ve been lost forever and I generally have tons of followers as an early adopter. FAIL.
2. XMPP doesn’t work. The one reliable way to reply that folks on Identi.ca were talking about last night was with XMPP, the protocol used for various IM clients including Google Talk. I could deal with replies that way if it worked but at some point, XMPP stopped working. I could receive, but I could not send. A one way conversation is a monologue. FAIL.
3. OpenID integration must be seamless. I was pleased to see OpenID supported when I signed up. Unfortunately, today, I could not login with my OpenID account. If I can’t get in, I can’t use it. FAIL.

Some would say I’m being too hard on this startup. Screw that. Perform or get off the stage. There are very obvious and defined features that must be included in a microcontent site at launch. I’m not saying an entire roadmap needs to be worked out. No, get a working beta up and get testers in there. However, without replies, without reliable “offline” access (i.e. IM, SMS or client integration) I’m not going to stick around. Finally, direct messages would be a nice feature.

While I have high hopes for Identi.ca, I will remain there only to squat on the name “technosailor”. Bye, guys.

The name of the venture is Mokonji and you can sign up to get in on the ground floor later this month. My philosophy on this is to release early and often so select invitees will have the opportunity to get in at a very early stage, kick the tires, and offer their feedback. I’ll be prototyping quite a bit on Twitter so follow me or the Mokonji user on Twitter to follow this hot piece of action. Or, check out blog where I’ll also be posting.

Matt makes a statement that struck me as so profound that it leapt off the page at me:

At one point in the Scoble interview Jonathan Schwartz says something to the effect of their startup program targets folks with more time than money, where their enterprise customers usually value time over money. I think this might represent a fundamental misunderstanding. While I think this argument could be made for the motivation of some segment of Open Source communities, the situation in startups is even worse “” time and money are both scarce.

Anyone who has worked in a startup recognizes that Schwarz’comment on startup is completely false. When I was working at Northrop Grumman and volunteering for b5media, I had no time and, let’s be honest – that’s really how most startups begin. Unless the folks at the helm of the startup already had capital and traction in the startup world, they need someway to pay the bills. Most folks in this situation work a “day job” ansd then slave away at the startup at night or on weekends trying to make it work.

Even once a startup is funded, this doesn’t really change. The pot of gold gets bigger and the strategies get more aggressive. Sure, you’re not working a day job and trying to make the startup work at night, but you face other challenges. Please don’t take this as complaining because I love what I do, but I still find it strangely ironic that folks sometime think us startup guys don’t really do anything but sit at home and surf the net.

My wife will tell you that I spend a large amount of time working late, spending time in front of the computer instead of going to bed with her. It’s not a cakewalk like some people might think it is.

I laugh at my dad who has no clue what I do. I tell him but he still doesn’t “get it”. He says, “People always ask me what you do and where you’re at and I just tell them, ‘I have no idea what he does but he does it well’.”

I’ve never been happier in my life. But anyone who thinks that startup guys have lots of time on their hands is fooling themselves. In some ways, there is more pressure to perform than in the big corporate environment. And I wouldn’t have it any other way.