What is more motivating than traditional ‘incentive’ packages?

• Autonomy
• Mastery
• Purpose

The new “operating system” for business.

Between getting settled into the new project and speaking to old friends at former companies (some of whom are now unemployed, while others only wished they were), I’ve been thinking about a number of things that seem to have dovetailed together in a way I wasn’t expecting.

First and foremost is career management. Long a favorite topic of mine, what I’ve been thinking of recently is how sadly common it is for a boss to be totally useless when it comes to helping their employees with career management plans. More than a few of them don’t think it’s part of their responsibility (which I find inexcusably lazy), but even more of them seem to simply not think of it.

This got me thinking of the series I wrote at Christmas, “A Christmas Card to My Bosses: Thanks to Three Very Wise Men.” While I wrote blog posts on the great lessons I learned from each John, Robert and Dave, the thing that I didn’t state explicitly (but which was implicit) was that each of them cared about and was focused on making sure the people on their staff were getting the career development support, encouragement and pushing that they needed. They were all acutely aware of the role they played in developing their people; they took that responsibility seriously and they executed against that.

I see so many talented people who do not have that. And when they finally have someone actually demonstrate some interest and some focus on helping them define and reach their career objectives, they are often so stunned they can hardly believe it.

Why is it so hard? Most people who have been successful enough to be the boss have accomplished that because they know how to manage their own career, so why is it so hard for them to help give guidance and advice to someone else on how to do the same? It shouldn’t be — and I don’t buy that it usually is. I think the reason most people don’t do it is because they don’t make time to do it.

An important thing to keep in mind: statistically speaking, most people do not leave their job, they leave their boss. So are you doing what you need to do to keep your employees engaged and supported so that they stick around? If not, why not?

So that’s my challenge to bosses everywhere: have you worked with each of your direct reports to make sure you understand their career goals (at least as much as they do)? Have you worked on a plan for them that will help them make progress towards those goals? Are you checking in with them regularly to make sure that they are staying focused on at least some of the accomplishments they need in order to stay on track?

Part of being a leader is helping make sure the people you are leading are getting where they need to go. If you aren’t doing that, then where are you leading them?

The “interesting” conversation I had afterward was because one of the attendees (in a private conversation) busted me for never once using the word “Agile” in my presentation. I’ve told him that it was deliberate, and here’s why:

What’s in a Name?

“Agile Development” is bullshit in and of itself. I don’t like or use this phrase because it’s a dangerous misnomer. As I’ve written about before, either your entire organization is going to be “Agile” or none of it is. You can’t just have “Agile Development” and expect that Project Management, Design, Testing and everything else won’t be impacted. The trouble is that Agile is all too often discussed, described, evaluated and generally understood as it applies to development only, leaving other aspects of the project lifecycle out in the cold.

The Methodology Myth

I have been in startup development environments for my entire career. And if there is one concrete, immutable fact I have learned it is that no startup environment is mature or stable enough to completely adopt and implement any pure methodology within any discipline — not requirements, not development, not project management, not testing. It simply does not happen — nor should it. While most development environments will dabble with some aspects of Agile, the fact is that — like all process — it is typically really a hybrid between a couple of different approaches, in combination with some home grown goodies, that is all tossed together to come up with something that fits the organization. Any other approach is folly.

You Say Potato, I Say Potaaaaaaaaaaaaato

One of the problems that has evolved over the years when it comes to Agile is at the heart of it’s value. As a methodology, Agile is specifically about results more than form or procedure. As an execution-oriented person in startup environments, I praise the focus on results. However, as a project manager, I also have to say that I have seen far, far too many developers use the methodology as an excuse for being lazy and sloppy about writing documentation. I used to debate with one of the Development Managers/Architects at JetBlue all the time: he was a huge advocate of adopting Agile methodologies, and I would always tell him that he needed to be careful of the language he used, unless he wanted to see a backlash from project and functional managers who’d been burned by this in the past.

He Said, She Said

Another problem with the language we use to describe Agile (in combination with the myth that it is or should be a dev-only consideration) is that, grammatically speaking, the word agile and the name Agile are often used interchangeably, even though they are not identical. This is particularly problematic when it comes to non-tech executives who hear “agile development” and think that means they are just going to get their project executed more quickly. All too often, I’ve seen Agile evangelists “sell” leadership teams on the idea that Agile is the way to go, without ever really explaining (in business-speak) what that means, what that will take and why it is of value. Even worse, most of the time, those evangelists actually think they really did explain it well.

Pragmatic Agnosticism

In the end, however, my biggest reason for not including the word “Agile” in my presentation is because, when it comes specifically to the core project management disciplines of communication, documentation, change management and entry/exit criteria, methodology agnosticism is key. This is never more true than in a startup where things are guaranteed to change before you have your Gantt Charts unpacked. Some of the tactical details may be different — whether it’s roles and responsibilities, sequence of events, etc. — the the underlying tenets are the same. And any project manager who says that communication, documentation and change management are fundamentally different in an Agile environment vs. a Waterfall environment are blowing smoke.

In the end, project management is a disciplined centered around the concept of integration. And integration is about effectively combining the efforts and products of multiple different disciplines into a final product of value. That can’t happen without communication, which includes at least some degree of written artifact (often around entry/exit criteria), and managing the inevitabilities of change. So, in a 45-minute presentation, it made more sense to me to skip over the great and eternal methodology debate, and move straight on to the basics that universally apply, regardless of what approach a team is taking to getting the work done.

I’m not entirely sure that the person I was speaking with agreed with my approach. And, in hindsight, I should have taken a moment at the beginning to state that I was going to be speaking from a methodology neutral standpoint. Definitely my over-sight there. I’ll be more conscientious of that in the future.

But people who want to get religious about a methodology can espouse whatever they like, but in the end, you have to be pragmatic in order to deliver a project (much less a recurring series of projects). And zealotry is never pragmatic.

How We Say What We Say

One of the challenges social media evangelists face is based on the language we use. As with all emerging technologies, the language is new and it’s not compatible with standard, well-worn executive jargon — worse yet, it has the unfortunate tendency to be too “cutsie” to be taken seriously by business leaders.

In order to get past the knee-jerk language reactions, stop using tech-speak and start using business-speak. The business already has a language, so use it. Evangelists can’t expect that the population at large is going to adopt a new language for a technology for which they are not yet onboard. Technologists and evangelists need to remember to speak the language of business.

The value of using the business’ language is clear in everything from initiating change, to clarifying the value of social media, to measuring the impact. In and among all of the ROI debate on social media one key is often over-looked: businesses already measure their efforts. For social media to be understandable to that business, it needs to be measured using metrics those executives already understand, expect and are comfortable with.

The Push-Pull Between Entrepreneurism and Process

As companies grow, entrepreneurism gives way to process until people can sleep walk through their day. Unthinking action is unthinking business. If your business is being run by unthinking people, then your business isn’t innovating.

Innovation is key. Even more importantly, innovation is different. Improving on a competitor’s product is not innovation. To truly innovate you must create something new, you must do it first, and you must own the market space.

Innovation Is Not Just for Products

In order to have innovative products, organization’s can’t fall into the trap of doing things the way they have always done. Instead of highly-connected leaders, most organizations have a collection of independently run fiefdoms. Lawrence calls these “Un-Knights at the Round Table.” In order to have the internal organization necessary to support true innovation, internal silos must be broken down, and all players must re-engage with each other.

One example Lawrence gives of how internal organizational patterns can benefit from social media is in its ability to “shorten the ramp.” Getting new employees up to speed quickly on new roles, projects or teams can be radically improved in organizations that leverage social media. Instead of having to spend six months learning who’s who and where to find what, an organization with an internal social media eco-system (facilitated by robust search capabilities) can provide opportunities to catch up quickly and start contributing to the team’s value much faster than traditional on-boarding processes facilitate.

In Conclusion

Social media has transformative capabilities, but the true transformation is in the people using technology to facilitate change, not in the technology itself. Like so many other lessons learned in social media: no matter how sexy the technology may be, business transformation is driven by people.

When the bubble burst back in 2000 it was because speculation had driven realistic performance expectations, sanity and reason out the window (keep throwing endless piles of money at most people, and eventually most of us will get stupid). The industry itself, as well as those watching and investing in it, had bought into its own hype, and then it was crushed under the weight of it’s own hubris and lunacy. (Not unlike what is currently happening to the financial services industry.) Critical lesson: watch the hype and don’t drink the KoolAid. (A caution I would also issue to the current level of hysteria going on in the social media space.)

What this meant, of course, was that companies that had not yet become profitable or did not yet have a self-sustaining business model were S.O.L. VC money evaporated over night. Gone were the massages and catered lunches and lavish holiday parties. Suddenly we were awash in pay cuts, layoffs and absorbing the workloads of people who’d left because we couldn’t afford to replace them.

We were lucky. At that point, we were still a services company (though we were working on our product; it just wasn’t done yet), and that bought us a little bit of time. Not a lot, but — as it turned out — enough. And we sold our asses off. Everything we did for clients was billable. Everything was custom. Everything was a one-off.

Naturally, this presented problems in the scheme of things, because while this was providing us with live-saving revenue, this was not at all scalable. And our leadership knew it. So we continued to push forward with our plans to transition into being a product-based business that offered additional, ancillary services.

The troubles here were strategy, communications, education and execution. For those of us who were living on the services side, we had a culture that was services-centric — not product-centric, and there is a huge difference. In a services-centric culture, your answer to clients is always “yes.” And clients expect your answer to always be “yes.” It never occurs to either of you that the answer could or should be anything else. There is a culture of expectation that must be transitioned, and it must be done thoughtfully and carefully in order to avoid alienating the very people who are keeping you in business.

Now, to be sure, you aren’t going to have a business if you get in the habit of saying “no” to your customers, but there is a big difference between being an order-taking organization whose response to “Jump!” is always, “How high?” and an organization that provides expertise and consultation to customers, as suppliments to a core product offering. The culture, the relationship, the value brought to the table are all very different. And shifting from one to the other is a significant change that needs to be managed carefully in order to keep both your staff and your clients onboard.

Furthermore, our problem was compounded by the fact that the product team was very insulated from the rest of the business. That include socially. They literally sat in a different building. The two groups barely knew each other, so not only did both sides feel misunderstood and taken for granted, but we did not have the opportunity to really find any solid common ground. The services teams thought the product teams were snobs; and the product teams thought the services teams were cowboys. And we were probably all at least a little bit right. But what we weren’t seeing is that each group had a different mission, and that we were each very much in-line with what we needed to be doing at that time.

What we didn’t do was actively execute against a long-term strategy to bring both teams in-line with each other. To whatever degree that did ultimately happen, it was more by brute force of circumstance than by much in the way of active planning or cultivation. Looking back now, so many of the conflicts, headaches, and missteps are painfully clear. And, since hindsight is 20/20, I see so many opportunities that were missed, that would have made all the difference — both when it came to the internal culture, as well as in our relationships with clients.

Of course, looking back, I also now realize that this was one of the early seeds that sparked my interest in change management. This was a big change that had do-or-die implications for the business. The sense of urgency and relevance needed to be truly understood by the services team to get their buy-in, and it simply wasn’t. Without that comprehension, managing client expectations was an endless series of bungled missteps that were constantly needing to be corrected. The services teams needed a roadmap; and we didn’t even have a compass.

Another reason that I love startups is that, given enough time, I know that I’ll have the opportunity to tackle this type of problem again, and be able to apply some of the hard-won lessons from last time to doing it better.

And then I got a job — that ultimately turned into a career — at a start-up. Pay dirt!

The transformation that sparked in me is still an endless source of amusement among my friends. It took me a while to realize why, but eventually it was clear: the problem with school is that there was an upper limit on what I was capable of achieving. It was an artificial cap on how well I could be scored. I found that inherently disincentivizing. In business, however, there is no upper limit. You can take something as far or as high as you can push it (given the right environment, of course).

And, even better, in a scrappy, entrepreneurial, risk-taking startup (especially one trying to survive an economic downturn) someone who is hungry, talented, teachable and willing to dive into the deep end of the pool head first has tremendous opportunity for growth. The first three years of my career were the most educational, exciting and energizing time of my life — all of my years of school combined couldn’t compare to those three years. Everything was new, everything was interesting and I never once had the slightest bit of doubt that I could conquer anything that came my way.

Ah, the hubris of youth!

Of course, there were downsides. Like many young people, I didn’t know my limits and was constantly pushing the envelope in ways that I probably shouldn’t have (and in ways that I’ve since learned not to do). Whereas many 26-year-olds may be more inclined to do that with parties, I did it with work. I ended up missing a lot of important events in the lives of friends and family because of that.

I was also still extremely idealistic about a great many things. Instead of The Pragmatic Contextualist, an appropriate blog title would have been something along the lines of The Snarky Idealist or Bring it On and Get Out of the Way! (Which, ironically, is still how some people tend to view me, though I have toned down considerably with age.)

But that idealism was invaluable to me, because it made me fearless: if anything is possible and I’m extremely capable, then what do I have to be afraid of? I don’t tend to be very risk-adverse in general, but I have become more cautious with age (though, not quite enough for either my husband or father’s tastes). Back then, though, it would never occur to me that I wouldn’t figure out a way to succeed at whatever I did — which meant I was a hopeless volunteer junkie.

My biggest rush came from fixing problems, and in a post-bubble burst start-up, there were plenty of things to be fixed. So I had an endless supply of opportunity, and endless confidence in my own success. Happily, I also had bosses who went from having nothing to lose by letting me try, to truly believing in my ability to make a positive difference.

As was inevitable, a few kicks in the teeth later, and I stopped being quite so cocky. The pragmatist in me was ultimately born of those experiences, and the eternal idealist retreated to the back, only to come out for the occasional political event.

One of the biggest, most valuable lessons I learned was how to deal with chaos. More recently in my career, I had a bizarre moment when a senior IT Director — who was easily 25 years older than me — groused that we were working in “the most chaotic environment” he’d ever experienced in his life.

I wanted to laugh and call him a weenie (I restrained myself — though barely). The environment we were working in at the time was easily the least chaotic environment I’d ever experienced, and his inability to roll with the punches made him a particularly weak and frustrating leader in my opinion, because he got frazzled very easily, whined constantly and was tremendously rigid. It never occurred to me until that moment that my ability to handle chaos was all that unique.

Naturally, one of the dangers of getting a bit too used to high volumes of chaos is that you can become a drama junkie. This did happen to me, and it took me a while (and outside circumstances) to curb it. But what I have seen of most drama junkies (and trust me, I wasn’t the only one I knew) is that, the older we get, the less tolerance we have for that same constant fever-pitch of insanity.

This is another reason that I have often recommended aimless twentysomethings seeking career advice to explore startups: because by the time people are settled in their career, married or have kids, startups can be a bit too rough on the lifestyle. So if you’re going to do them, best give them a shot while you’re young, energetic, single and have as few external obligations as possible.

But when I look back on that time now, I am profoundly grateful. I was drinking from a fire hose, and it never occurred to me there was any other way to work. I got to sample a spectrum of potential opportunities and figure out which ones held some appeal, and which ones didn’t. If I had found myself in a more stable, structured environment back then, I can’t imagine where I’d be now, because the lessons I learned there, and the all-you-can-eat-buffet of opportunities that I had available to me at the time are how I found my way into a career.

In the scheme of things, I look back on the most pivotal, impactful decisions of my life and the day I left the famed O’Reilly Publishing — which is where I thought I’d wanted to work for years — and went to MarketLive (at the time it was still called MultimediaLive) was one of them. And since then, I have found myself encouraging twentysomethings who do not know what they want out of a career to look at startups, because as long as they can develop a bit of tolerance for chaos (which I firmly believe everyone should do), they’ll usually find opportunities they never knew existed.

What do you think? Are startups a good or bad place to start out your career?

Specifically, I’ve been thinking about how early career choices can really set the stage for the directions we take in life. As is often the case, many of the largest influences on our lives are not obvious until many years later. And while I am as likely as anyone to take them for granted, every once in a while something will happen to make me stop and consider the series of events that brought me to where I am now, and what the unintended consquences of seemingly small actions or events have ultimately provided.

There were three defining elements of my early career that I have been noodling on, because they had much larger impacts on me than I ever would have predicted at the time:

• Getting your start in a startup. What is the value to launching a career in a startup environment?
• Being in the ‘wild west’ of a new market space. What does it mean to be in a new space?
• Transforming a company from being “a services company” to “a product company.” What are the differences and why are they important?

Undoubtedly, the first two of those are a bit sexier than the third. However, all three ultimately shaped me in ways I never fully realized at the time. The lessons learned were a bit rough sometimes, but when I compare some of my experience to that of my peers, I realize that I had the opportunity to be involved in some things that have served me extremely well and that I wouldn’t trade in for anything.

Over the next couple of days, I’ll cover each of these topics in a separate post (each one is too long to combine them).

The fact is, most experienced professionals have lived through enough project pain that they don’t typically need a huge amount of convincing that Waterfall is often inefficient — particularly for longer, larger, more complicated projects. In a fast-moving world, the risk of constantly changing requriements is ubiquitous, and a Waterfall project does very little to insure against that danger while still delivering a valuable product to users.

However, the problem with the “Agile Development” argument is that, in order to work properly, Agile can’t just be for software development. In fact, Agile can’t even just be for your project teams. Your entire business needs to be ready to adopt an Agile methodology.

The trouble is, this conflicts with standard business-model thinking. In his book “Maverick,” Ricardo Semler outlines the critical success criterial for modern business: “To survive in modern times, a company must have an organizational structure that accepts change as its basic premise…” He goes on to discuss the more ‘agile’ approach at his company, Semco, and why: “[W]e take an operation view of six months, because we found that in a conventional one-year plan people will invariably believe that conditions will improve just enough to compensate for the problems they know they’ll have in the first half of the year.”

How many of us have seem Semler’s point in action? In annual budget processes? In project planning? Somehow, some way we convince ourselves that whatever conditions that exist today will be “resolved” and we’ll be able to make up lost ground later. And so our plans are based on figuring that we’ve got a brief rough patch to get past, but once we do that, we’ll have 100% clear sailing. How often does that actually happen?

Of course, just looking out six months isn’t sufficient, either. At Semco, Semler and team have two plans: one with a five-year view to keep an eye on strategic planning, will the six-month view focuses on tactical execution. But isn’t this what we have come to recognize as the definition of “Agile Development”? A long-range goal that we approach in short bursts, one piece at a time.

But if we change “Agile Development” to “Agile Leadership” it not only allows us to approach application development with flexibility and agility, but also the way we look at the bigger picture. Development efforts — whether they are for back office systems, B2C web sites or client engagements — are a means to an end, not an end themselves. We recognize that changes to business conditions are a big part of the reason we get value out of Agile Development, but then we continue to approach management of our actual business as though it were static.

I was recently approached about a “four-year project.” Horrifyingly (yet predictably) enough, this was a Waterfall technical project (for a government agency). In technology terms four years is an eternity. The idea that any team (or group of teams) would be spending four years and tens of millions of dollars on developing and implementing a technical solution for anything is insane, because no matter how good your requirements are this year, by the time the project is complete (assuming it is actually complete in four years) the entire world will have changed. Four years is an ice age when it comes to technology, and it’s at least a lifetime when it comes to business.

So what would need to change if we applied “Agile” methodology to an entire business, intead of just the development teams? Consider this:

• Evaluate the business from end-to-end and examine how much is truly “operational” and how much is “project-based.” Your operating models, staffing, budgetary and expectations are all different for the different sides of the organization. And, in many cases, most people should have a mix of both to keep business moving while also getting new work done and keeping employee engagement as high as possible. But we need to truly stop and look at this, because without first understanding how much time people have to dedicate to project work, we never build realistic project schedules. How many project plans assume each team member spends 8 hours per day on the project? Does that ever really happen?

• All projects would be time-boxed to ensure that, even at their longest, nothing dragged on for more than six months. This could be done by breaking large-scale projects into multiple smaller projects all organized as a program, or by breaking a single long project down into phases. But no matter what, no one phase should ever last too long. And at the end of every phase, a re-evaluation is done before proceeding to the next. How often have we worked on a project only to realize half way through that the work was really no longer necessary? Aside from being an irresponsible financial sink hole, this is also extremely bad for team morale.

• Consciously examine the value of ‘domain expertise’ versus ‘fresh blood.’ As a career project professional, I can tell you that most leadership underestimates the value of giving a project team a new project — even if it’s the second or third phase of someone else’s project. The assumption that it is better to keep the “experts” in place rather than to get fresh blood looking at a problem is often assumed instead of explored. And while there can be some value, is the value found simply because the original team didn’t do a good job of documenting their work? Or is it just a simpler resource model. In my decade of project management experience, I’ve seen keeping the same team on a project for a long time do more harm than good. And I’ve seen very little formal evaluation done to ensure the decision was actually being made instead of merely assumed.

• Strategic initiatives like new product development make an agile approach particularly valuable. Market conditions change rapidly and outside factors can move a low-priority, nice-to-have product from the bottom of the list to the top of the list over-night. If you’re planning too far out in too much detail and with too much rigidity, then you are not leaving your team the ability to react quickly enough to stay ahead of the curve. In fact, even worse, if your planning goes out too far, you end up inadvertently discouraging your people from staying abreast of the latest trends and changes, because they get into a ‘heads-down’ mentality, focusing on the long list of things they know are going to be occupying their time for the next year plus. This is one of the ways that companies lose their edge entirely.

Budgetting may be the biggest one of all, because we have been conditioned by most modern business practices to think in terms of quarters and years. Quarter-by-quarter planning is often too frequent to be efficient, but year-by-year is often too far out to be realistic. And, worse yet, it’s not far enough out to be strategic. It’s a combination of timelines that often work at cross purposes: we scramble like crazy for end-of-quarter numbers, and then we speculate wildly when building out year-long budgets. And in the end, neither is usually very valuable to getting things done.

How many organizations with large expenditures on gasoline and/or natural gas of some kind had to stop what they were doing in the middle of 2008 and completely level-set their budget for the year, because the unprecidented cost of oil had made all of the year’s original numbers (no matter how conservatively planned) entirely meaningless? Trucking companies, airlines, agribusiness, shipping companies, etc. All of them, because at the end of 2007 when planning the 2008 budget, you would have been hard-pressed to find anyone who would have predicted that gasoline would top out near $150/barrel. (Hell, most people thought they were being generous if they budgeted for $100/barrel.)

I have seen two common outcomes to this process: either everyone spends weeks creating their budget for the next year based on wild speculation and generally accepted (often inacurate) assumptions, and then they are held to it kicking and screaming, missing one opportunity for market adaptation after another; or the organization stamps the budget as “FILED,” puts it in a drawer and never looks at it again, rendering the entire exercise valueless.

And while the 2008 oil roller coaster is an extreme example, this type of thing happens on smaller scales all the time. And so we plan optimistically and then make exceptions for all the things our plan didn’t account for. Josh Ross has an interview (ironically, shot the day after the mother of all recent unplanned disasters: the collapse of Lehman Brothers) called We Design For Possibility and Retrofit for Risk. And although he is specifically talking about Web 2.0 and information security, in reality that title applies to business in general.

We plan aggressively, assuming all will go acording to plan, and then we try to put out fires that errupt en route to our goals. Instead of sprinting in shorter bursts that allow less time for disaster to erupt, we take a marathon mentality that gives the world around us time to throw obstacles in our path over and over again.

Like so many other normal, mundane facts of our daily lives, the way we approach business is still largely rooted in Industrial Age thinking — it’s a model for which the Waterfall method makes sense. The time and cost to build something new is so high that you better make damn sure you know what you’re doing before you start. But as we transition from, as Chris Anderson puts it, the ‘economy of atoms to the economy of bytes‘ we trade in more and more investment cost for higher and higher opportunity cost. If we don’t start pushing ourselves to thinking, planning and acting like products of an Information Age, we will continue to pay the price for a lack of innovation and agility. And the more time goes by, the more of our competitors will make the change around us, the more we have to lose by burying our heads in the rubble of the Industrial Age.

My perspective on the VC universe is heavily colored (naturally) by my life within the world of tech startups, which is where I’ve spent my career. I have personally lived on both sides of the tech startup coin: a bootstrapping, self-funded, hold-everything-together-with-duct-tape-and-bailing-wire startup and then a well-funded, organized, structured, VC-backed startup. Both were phenomenal learning experiences — both technically and when it came to business.

Bootstrapping

In my heart of hearts, if I had to admit to a preference of one model over the other, I would probably say that I enjoyed my bootstrapping experience more — though, to be fair, that’s easy for me to say. While we did have layoffs and two rounds of paycuts (woo hoo! to those who remember where they were the day the bubble burst invaded their lives, too), I never felt the pressure of our financial situation the way my leadership team did. Whether they were taking their paychecks late or having me buy servers for clients on their personal American Express cards (could not count how many times that happened), our situation may have aged them each more than they had ever thought possible, but they did a great job of insulating most of us from how close to the line we really were at times.

But our financial tight-rope walk is precisely why I look back on this time in my career as fondly as I did, because necessity is the mother of invention. (Which is also why I firmly believe that this economic downturn will ultimately prove to be good for the tech industry.) We had no choice but to be creative, scrappy and innovative. And we hustled our asses off. I have never seen a group of people work so hard in my life. I have never seen the kind of crazy, off-the-wall, no holds barred brainstorming or experimentation than we had back then. And it was because that was simply a requirement of our own survival. Never underestimate the motivational power of self-preservation.

Of course, there were also huge downsides (even aside from the aforementioned layoffs and paycuts). We had office space that was often a shambles; many of us were (literally) doing at least two different (near full-time) jobs; I personally spent two years on call 24×7; and we were often living life so close to the financial edge that our sales team would make deals that were a delivery nightmare (and since that was my end of the business, it was a constant source of resentment and frustration).

So it certainly wasn’t sunshine and flowers. But the Grand Canyon could not hold everything I learned during that time, and no experience since then has matched the exhilaration, the learning curve or the sheer intensity of that time in my professional life.

Venture-Backed

After leaving my bootstrapping existence, I moved to an extremely well-funded tech startup and quickly discovered what Little Orphan Annie must’ve felt like to go from the orphanage to Daddy Warbuck’s mansion. Even more than that, because the goal of the company from the outset was to be acquired, much of the focus of the COO (and ultimately me, as well) was to make damn sure we had our ducks in a row when it came to operational aspects of running a tech firm — development process, product management, knowledge management, etc. These were things that, in my previous life, took YEARS for us to be comfortable enough so that we could pay attention to them in any kind of organized way.

As someone whose adult life has been spent implementing both technology and process improvement in organizations, this was extremely exciting for me. I absolutely loved the idea of getting to build something scalable from Day 1, instead of trying to retrofit a solution after years of lost opportunity. And I was very aware of the fact that this was only possible because we had funding.

Naturally, there were other obvious financial benefits to this arrangement: I made considerably more money, our offices were in the uber-trendy SoHo neighborhood of Manhattan, weekly FreshDirect deliveries kept up all in snacks and Diet Coke, and not a single one of us ever had to use a recycled, out-dated, resource-constrained computer.

The flipside, though, was that the sense of hunger that had been pervasive in my previous startup was simply not there. And while our work was extremely innovative on a technical level, the teams were much more disparate. We didn’t have the cross-organizational sense of unity that comes from being in a sink-or-swim situation with a group of other people.

Which One?

I’ve thought about these differences a lot. Ultimately I ended up in the IT Department of a non-tech company that was — in many ways — a startups, as well. And it was actually a combination of the two experiences: the company itself was extremely well-funded (had to be because of the operational investment needed), but the IT Department was definitely outside the mainstream of the organization (like much of corporate IT), which tended to give it more of that ‘digital wild west’ attitude.

But what I find more perplexing — and how this all relates to both the SXSWi panel and Haque’s article — is that, more than I have ever seen before, you don’t hear discussions about the tech startup community that are not largely dominated by VC-talk. I find this to be truly sad, because adding VC funding into the mix of your startup changes it radically. And the truth is, it is probably a sexier sounding idea than it is reality for most.

During the SXSWi panel, Penelope Trunk made a fairly unpopular point (she has made a career of making contrarian points, which is part of what I like about her), but one which completely resonates with my experience: as soon as you take on a VC, you are no longer in control of your company. While Mike Maples (a VC) was quick to bat back her statement with a, “That’s not necessarily true” the fact is that most of the examples of late stage funding I have witnessed in my career support Penelope’s assertion.

While “serial entrepreneur” is a sexy title, it rarely fits: most entrepreneurs spend their career trying to grow one business. That means that most of them do not have the chance to collect a bag of lessons from one company to the next on how to advantageously structure VC deals when the time comes. Quite often, someone who builds a company and then gets VC funding late in the game finds themselves pushed to the outter edge of their business (if not entirely out the door) within a matter of a couple of years, if for no other reason, than because they did not have the experience necessary to know how to structure a deal with their VC firm that left them with enough control to prevent that.

Now, to be fair, entrepreneurs are visionaries. That’s their strength. They are often the best evangelists, but they are rarely operationally oriented. Over time, the sustainable growth and development of a business will typically require a shift from being entrepreneurial to being operational. And this shift will almost always require different people to lead it. So I’m certainly not saying that an organization’s founder is always the best person to lead the business over the long haul; but what I also know is that most entrepreneurs do what they do because that’s their passion. And there is something hopelessly broken-hearted about an entrepreneur who no longer gets to be central to their organization’s lifeblood. Entrepreneurs who want VC funding should think about that before they go down that road.

The Current Recession

In a tight economy with an immature space that has yet to develop solid discipline around sustainable business models, I certainly understand the appeal of a big bank account. No CEO wants to have to hold a company meeting to tell his employees that they are not getting their paychecks on time, or that when they do, they are going to be short by 15%. But really, when does VC-backing really make sense?

My funded startup would be one of those times when I think it did: the cost of building the infrastructure needed was too high and was going to take too long to be able to build without external support. The entire revenue model was based on a getting strategic partnerships in place and leveraging an economy of scale model that meant, first and foremost, we had to build that scalable system. Bootstrapping this (especially in NYC) would have been unlikely because we needed to give the team time, which is the most expensive thing of all when you are starting a new company.

Could it have been done without backing? Yes, but it would have taken a long time — which was not a luxury we had in this market space — and it probably would have had to be done by a very high-profile industry insider, who had the personal relationships necessary to make some of the most essential in-roads. The combination of necessary skills would have been extremely unlikely to find in a small handful of individuals. The solution needed a bigger team to make it work properly.

But I routinely see other funded tech startups that, in my opinion, are a bit lazy. Bootstrapped startups don’t get nearly as much attention, but they are the more realistic model. I attended a Core Conversation at SXSWi with the partners from Dogster.com and they mentioned something I love to hear: their business got started with two guys programming at a kitchen table at night, after their day jobs, for a year before they tried to live off what the business was generating.

Why do I love that reminder? Because it’s real — and, frankly, it’s what small startup businesses outside of the tech space have to do; tech is one of the only industries that starts off assuming that it’s even entitled to getting VC money, which I think is limiting hubris that continues to get the industry into trouble by fostering some really bad financial habits. In an era where chasing the glossy dollar sign has blown up in our collective faces and is taking the global economy with it, what I love to hear is that someone who felt strongly about something buckled down, busted their ass, made huge personal sacrifices, and made it happen.

So while I would not presume to weigh-in on Haque’s assertion that VCs are a significant part of the problem based on my current level of understanding (though, it’s easy to paint all segments of the greater financial community with black hats these days), what I will say is this: the tech industry success stories I think are the most inspiring, and the most worth listening to are the ones that did what they did because of passion, dedication and the ass-busting efforts of committed teams trying to make meaningful products and introduce revolutionary changes to the marketplace.

And while I do not summarily dismiss the possibility that type of drive could come with VC-backing, the value of the reward is often proportionate to the value of the risk. And there is no risk like the all-in, double-or-nothing gamble of a self-supporting team trying to take on the house. Which also means there is no reward like when that team manages to pull a natural twenty-one, either.

So which do you prefer? Or do you think it matters?