Since Justin and I are the same age (mid-30′s), it’s probably easy to assume that my source of pissiness was the same as his: Get over yourself, you big babies.

In point of fact, though, my source of pissiness is him being pissy about these survey results. Because, while I may have nearly two decades on the participants of that survey, add me into the group for whom that would make a difference. And while my reasons may not look the same on the surface, I’d venture to say that they probably aren’t as far off as some of my old fart peers might assume.

During my entire career, I have only spend three and a half months working at a company that was neither a startup nor a tech company. You know why I only lasted 3.5 months? Because the 30 year old company had a 30 year old culture that hadn’t seen any modern influences since the Nixon era.

What became crystal clear to me in that environment — an environment, by the way, when even during the NYC public transportation strike, when some of us had absolutely no means of getting to the office at all (depending on where you lived) vehemently prohibited anything as ‘lax’ as working from home — is that the technologies and business practices a company adopts speak to who and what they are as a business. Culture informs everything; and you learn a lot about a company by its rules and policies.

Here is what it says to me about a culture, if a business blocks access to social networks:

• You don’t trust your employees. If you have employees who are abusing the problem, then grow a set, fire them and leave the rest to do their job in the way that makes most sense for them.
• You are not allowing your employees access to valuable tools for business. Whether it’s current events, industry news or general networking with peers in other companies, Twitter is the single most powerful tool I have in my daily arsenal. Facebook is a close second. I get complex questions answered faster, find out industry-specific news more quickly, and generally manage to navigate my knowledge worker day far more effectively with Twitter than I ever did without. If an employer didn’t let me have access to it, I wouldn’t work for that employer.
• You are sticking your head in the sand and may as well paint a great big target on your ass. If you are restricting access to social media, then you are deliberately choosing to ignore changing trends in the marketplace around you. As an employee, any employer who deliberately did that would be someone I would think twice about working for, because I would read that as an indication of their attitude toward change and innovation in general — which has huge cultural implications for where and how I spend my day each and every week.
• You are being capricious. Blogs are as much social media as Facebook is. Are you going to block access to those, too? If so, that would include most major news outlets (after all, NYT is on WordPress), and source of current events. And what about Delicious, Digg, StumbleUpon, Yelp, YouTube, Flickr, Trippit or LinkedIn? They are all social networks. You going to block them, too?
• You are misallocating resources. Does your IT team really have nothing better to do with their time than to lock down the firewall to prevent me from getting to Twitter or Facebook? IT talent is expensive (I know: I’ve spent a well-paid career in that space), if you can’t think of something better for them to do than that, they you are not the type of company I want to work for.
• You are missing the point. Facebook (and text messaging) is how that age group communicates. Cutting them off from that would be like cutting me off from email and expecting me to be as fast, as accurate or as deft at navigating my day. Just because you and I have different preferred methods of communication does not make yours more valid than mine.
• You are setting a bad precedent. If you are summarily blocking social media, what other innovations can I expect that you will dismiss as having no value, despite the fact that your staff could find them profoundly impactful?
• You are fighting an unwinnable battle… which just makes you look lame. Business 101: Pick Your Battles.  The more time goes by, the more of your employees will have the same ability to ‘waste time’ via their smart phone as they do via a web browser. Are you going to confiscate their phones when they come to work, too?

So yes, if I was exploring working for someone, one of the things I’d want to understand was their social media policy. Absolutely. Just like having the ability to work from home when necessary, I consider that essential for my ability to be able to do my job well.

For those of us old enough to remember the internet before the web, I recognize that what is transformative about social networking is that it has made things that used to be hard much, much easier. I, for one, am not going to volunteer to hop in a time capsule and go back to making things harder again. Not if I can help it.

I remember making a mental note of the idea, because I liked it and wanted to keep it in mind as part of our plans for developing our business over time.  To me, it seemed like a logical extension of the Results Only Work Environment (ROWE) concept, which has proven very effective at large companies like Best Buy, while having always been — at least to some extent — a natural part of my career DNA at almost every company I’ve ever worked.

This debate has recently been kicked into the spotlight, thanks to Netflix fairly high profile stand on this position — what started off as a simple presentation (see below) describing their corporate culture, quickly turned into a big debate on the specifics of their vacation policy.

A recent article in Business Insider, Henry Blodget inspired a great deal of commentary when he asked readers what they thought of the idea — most of the responses are in opposition to the idea of a no-policy policy around vacation days. On Entrepreneur.com, author Tanya Payne added a fairly dismissive comment by asking, “Is Netflix run by a bunch of hippies?”

I’m fascinated by this debate, in large part, because in my experience as a white collar, tech professional is that — whether or not it’s “official,” every place I have ever worked has done precisely this. The reality, however, is just that: this is not something that places with hourly staff, or huge organizations are likely to find either appealing or even terribly practical.  So, for me, the question is not, “Does a ‘no vacation policy’ policy make sense?”  But instead, “When does a ‘no vacation policy’ policy make sense?”

As someone who works in a geographically independent profession on dynamic, project-specific, virtual teams with entrepreneurs and small organizations, this is sort of an obvious no-brainer. Even more importantly, what I like best about the idea of a ‘no policy policy’ when it comes to vacation time, is the fact that forces team accountability: either the person taking a vacation makes the necessary arrangements to be covered while they are out, or the person who hired them has to acknowledge that their staff is not mature enough to handle the responsibility of being treated like an adult — in which case, whether or not that person should stay needs to be asked and answered.

I also like that it eliminates what can seem like arbitrary favoritism in a crisis. Several times in my career, I have seen different sides of this equation, and all of them support the reasoning behind a no policy approach:

• A co-worker’s husband had a massive heart attack and, as a result, she was out of work for about a month. She had neither the vacation nor sick days accumulated to cover her time off, but no one for a second questioned that. She needed to be home with her family, and — even more importantly — now that their income had just suffered a massive (and indefinite) hit, the last thing she could afford to do was to have to chose between paying the bills or taking care of her husband and kids in the wake of a family crisis.
• As I was leaving another company, my final paperwork indicated that I had a negative number of vacation hours, based on my accrual rate and the amount of time I’d been with the company. However, the person handling it “wasn’t going to make a big deal” about it, and let it go without docking my final paycheck the even out the number of hours in my vacation bank.
• During a particularly high stress time in my years with another company, my boss — being both perceptive and prudent — recognized that I was overly taxed and at the end of my rope. With a non-negotiable Thursday morning instant message, he effectively kicked me out of the office for the following week and told me to clear my head, get some rest and that he didn’t want to see me until a week from the following Monday.

In each of these cases, the “official” policy said one thing, but the culture of the organization over-ruled it when circumstances arose. I think that doing this is far more dangerous — and potentially rife with conflict — than simply stating, “We do not count your vacation hours. Be a grown up. Plan accordingly, and work with your team to make sure your responsibilities are covered.” Because at least that policy sets the expectations.

The problem with exception-based end-runs around official policies is that you can’t prevent them. But, worse yet, they are fickle. It depends on the people involved, their relationships, the timing, their responsibilities, etc. That is where I see the vast majority of unfairness playing out, because there is no way to stop someone from working out a special arrangement because of “special circumstances.” The trouble with that, though, is who defines what the special circumstances are, which ones warrant a special deal, and what happens when someone else’s “special circumstances” are dismissed as less worthy of special arrangements?

Of course, the flip side in my universe is that I am a workaholic who seeks out high-chaos environments where no one ever only works 40 hours per week. I also specifically work in smaller organizations with a lot of flexibility, where working from home is standard, and where expectations are different. If there is one thing I learned working in the airline industry, it’s that there are different rules for hourly customer service teams than there are for backoffice salaried teams. Is that fair? Probably not. Is it avoidable? If it is, it’s probaby only possible while an organization is still small. (And even then, I’m not sure I’d be willing to bet the ranch on that.)

So, while I find the debate over the no vacation policy issue intersting, I guess what I mostly find is that it’s ignoring a tremendously important factor: it depends on your team, your culture, your services and your business. As with many things, the smaller the organization, the easier some of these things are to manage this way. Often times, stricter, formal policies arise out of a need for clarity that comes from too many different managers managing too many different teams that have too many different people. Clarity is a security blanket.

I think there are better ways to accomplish that clarity that are both more fair and more respectful, but a formal policy can definitely have its value. But then again, so too is there value in a boss recognizing that a member of his team is burned out and needs some time off, whether or not they have the official hours banked to take it.

I guess the real key boils down to three vital questions:

1. What kind of business do you want to run?
2. What kind of people do you want to hire?
3. And what kind of boss do you want to be?

It is probably only with a specific combination of answers that a no vacation policy can make sense. But, I’d venture to say that where it does make sense, it’d be hard to find a really good reason not to do it.

This post originally appeared as part of my Entrepreneur Evangelist series on WorkingPoint‘s Small Business Blog.

But every startup hits a tipping point, and it’s rarely articulated as clearly and beautifully as Steve Blank does in an article posted to VentureBeat today. The transition from a ‘scrappy startup’ to a mid-sized company trying to be more mature is always infinitely more painful a process than anyone seems to think is reasonable.

This surprises me every time I see it. In his story, Steve recounts watching a new CFO to a mid-sized firm implement a ‘no more free soda’ policy and inadvertently spark an exodus of the founding team of engineers. What’s more interesting, though, is that some of the comments posted on the story miss the point: the engineers didn’t leave the company because the company started charging them $.50 for a Coke. The engineers left because being charged $.50 for a Coke was a sign that the company was no longer the same organization that they’d previously been willing to sacrifice for.

That’s a subtle distinction, but a vital one. More than once, I and many of my colleagues, have been willing to take significant pay cuts to work in environments that had a culture (or other intangibles) that made the trade-off worthwhile. Eventually, though, most organizations change enough to where that trade-off ceases to be worth it. The part that is often upsetting, however, is that those changes are frequently sparked by someone coming in the door more intent on shaking things up than on understanding the culture they are walking into.

Steve’s story is one that I can relate to over and over again. It wasn’t until I had a truly remarkable executive come into our organization, and refuse to act precipitously, but instead insist on watching and interviewing the entire staff for his first 60 days, that I had the slightest hope of someone making positive changes without unraveling the cultural elements that held us together, even in the face of the chaos. So now, when I go into startups, many of which are at the transition point between early-stage/founding team, and their second generation, I have a five step approach I follow:

1. Recognize that, for founding teams, everything is personal. The people who build a new organization take on a lot of risk and chaos to do it. They have to believe in it. It’s almost a religious experience, and you can’t come in a year or two later and expect them not to take your changes personally. Because, whether it makes sense to you or not, everything is personal. They’ve sacrificed too much for it not to be.
2. Understand the evolution. You have to be a bit of an archaeologist when you go into a new business. Do not make assumptions about how they got where they are. If you look long and hard enough, talk to enough people, and do your research, you’ll find that even the craziest things you see have a reason for having evolved the way they did. Unless or until you understand that reason, anything you do to try to “fix” the situation runs the risk of alienating people unnecessarily.
3. Respect the sacrifices made by the people who came before you. Unless you know that the people who are there when you walk in the door are dead wood and you want them to quit, make sure you demonstrate some respect to what they were able to accomplish — especially if they did it under tough circumstances. The single biggest source of alienation I have ever seen has been when new people come in, hot-to-trot, making changes and the people who built the company in the first place are treated like morons who simply got lucky.
4. Work on depersonalizing the business. It is reasonable that early stage startups are often personal sacrifices for people — they need to be. But a maturing company has to pass the point where that is no longer true. Not all of the early stage team will be able to handle that transition, but many of them can and will if they do not feel kicked in the teeth by new leadership brought in from the outside. Slowly building in an ethic of, “It’s not personal, but this is where the business needs to go now” is actually often much easier than people assume it to be. Founding teams want the business to be successful. That was the whole point for their sacrifice. If you want or need them to stick around, then help them learn to take a step back and not see the evolution of the business as an emotional affair.
5. Facilitate relationships between the old guard and new guard. Not all of the old guard is (or should) make the transition to the new phase of the business. And not all of the new guard is capable of showing any respect for what the old guard has done. But if you focus on individuals, their talents, and understanding what drives them, it is often possible to help connect people in ways that build strong teams to move the company forward. But you must keep in mind that there is often an automatic lack of trust between both groups, a tendency to point fingers, and a common tradition of resentment that you must work through before you are going to see progress.

Businesses are made up of people. And not every person is right for every business at every stage. Some really do need to move on as an organization grows. But that should be a deliberate, well-considered decision, not a haphazard, expensive mistake spurred by a short-sighted, penny-pinching reason. Unfortunately, that’s the cause I’ve seen most frequently throughout my career. And it’s a bit tragic, because a lot of dynamic organizations have lost a lot of amazing talent that could have helped grow the business and make it successful.

(This post is part of my Entrepreneur Evangelist series and was originally published on WorkingPoint‘s Small Business Blog.)

• Prestige requires pandemonium
• Confidence requires congruency
• Fame requires flexibility
• Success requires surrender.
• Creativity requires curiosity
• Originality requires murder
• Serendipity requires strategy
• Dominance requires discomfort
• Matchlessness requires relentlessness
• Remarkability requires reinvention

Scott’s list reminds me of a principle called Open Beats Closed, by an old friend and former colleague, Joshua-Michele Ross.

Much like Scott, Josh posits that in an information economy — particularly that fueld by the social web — the old constructs, objectives and means of accomplishment need to be re-examined and, in many cases, tossed for radically different approaches.  What comes out of these changes are a new set of social guidelines that are based on how our social interactions currently work, instead of how they used to work 5, 10 or 20 years ago.  And while these are most definitely “social” guidelines, they ultimately must also evolve into business guideliness.

Scott’s list is similar, insofar as that most of what he is talking about is the relationship between two seemingly unrelated concepts (in most cases) as being essential to success.  What is great about this list, though, is that it makes you think.  If you read Scott’s entire post (Josh’s, as well), the examples he highlights are all very relatable, and it doesn’t take long before your brain is scrambling for similar memories that make the same point.

To my mind, this begs the following questions:

• What assumptions are you taking for granted today?
• What historical conditions are you still artificially imposing on your life and your business, and can you spot them and let them go?
• And if you do, what does that mean?

One of the biggest ones I see entrepreneurs stuggle with is the “dollars for hours” problem — building a “practice” that is centered around their time, rather than building a business that can run without them.  What assumptions are at the root of this?  And do they still apply?  If no, what is the underlying reality now?

I find both Scott and Josh’s points tremendously valuable because everytime I review them, I am forced to acknowledge that some of the things I spend my time on are not valuable.  While that is frustrating in the moment, calling that out is the only way for me to make both my life and my business better.  And isn’t that why I started my own business in the first place?

(This post is part of my Entrepreneur Evangelist series and was originally published on WorkingPoint‘s Small Business Blog.)

What is more motivating than traditional ‘incentive’ packages?

• Autonomy
• Mastery
• Purpose

The new “operating system” for business.

Online already are keynote coverage posts by Ricci Neer, for each Dion Hinchcliffe, Sam Lawrence and whurley. (Additional coverage of the first and second breakout sessions can be found on Ricci’s blog as well.)

Even better, though, is the video coverage of keynotes, thanks to Video Innovations.

Dion Hinchcliffe – How Social Media Can Enhance Enterprise Profitability

Dion Hinchcliffe – IA09 Keynote

Regular Broadband – 1 Mbps

Sam Lawrence – 20 Practical Ways to Use Social Software to Drive Profitability

Sam Lawrence – IA09 Keynote

Regular Broadband – 1 Mbps

whurley – Future Technology Trends

whurley – IA09 Keynote

Regular Broadband – 1 Mbps

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.

What was exciting was doing something new. Being a small group of people, pushing a boulder up a hill together was an amazing experience on so many levels.

Personally

On a purely personal level, it provided both opportunity and comradery that I absolutely soaked up like a sponge. There is no bond between co-workers like the bonds built while firefighting in the middle of the night for days on end. People are tired, punch drunk, but our brains were flying like trapeze artists trying to find solutions. And the best part? Every single time we eventually figured it out.

That built huge faith and trust in and among the team, because you quickly learned who was good at what, and who you needed to pull into a room when something was blowing up. I learned that technical trouble-shooting was an art form, and the fine-tuned dance we could do as a team when it came to examining the performance of complex systems would make the Bolshoi envious. To this day I find a kind of agonizing beauty in pulling together a talented team of people to trouble shoot a truly baffling problem; and to this day, I’ve never worked with full teams of people who were as gifted at it as the people I worked with in my early career.

And some of the most important people in my life to this day, were the people from that time and place in my life. I wouldn’t trade it — or them — for anything.

Intellectually

When you are trying to build something new that not everyone understands or cares about (or understands why they should care about), you have to learn to be very quick on your feet. You have to be able to discern what is truly important to them, and then draw them a map of why what you are offering will lead them to where they want to go. Sometimes it’s an obvious leap; other times it’s total bullshit. But either way, it’s an intellectual challenge that is invaluable to master, because you have to do it quickly, while you’re ‘on stage’ and you have to be sincere enough to be convincing.

It sounds like I’m saying that I learned to be a salesperson, doesn’t it? In truth, I did. To be sure, I don’t enjoy “sales” in general and I’d never want to make my career at it, but all business is selling. And if you want to be good at business, you have to learn this — the earlier the better. Whether you are selling yourself and your skills to a potential employer, or you are selling your product to a potential customer, anyone who can’t figure out what someone wants and how to give it to them won’t make it very far in business.

The sooner you learn this, the better off you’ll be.

Commercially

When I first got online way back in 1993, the internet was still a playground. It had not yet become ‘the new frontier’ of business. But I loved it, and since the web was beginning to emerge as a viable business environment, I knew I wanted to find a way to do that professionally. I just didn’t know how or what exactly that would mean.

Being in ecommerce from 2000-2005 was a great time. And targeting the small- to mid-sized cataloger and retailer (which was our demographic) was what kept us alive when the bubble burst. It also proved to be highly valuable for other reasons.

While other ecommerce software providers were busy trying to sell into the top end of the market — the Fortune 1000, who had millions of dollars to spend on a site — we were aiming at a higher volume of smaller clients. Of course, this was one of the reasons that we couldn’t continue to be a services company — we had to have a product in order for our business to scale this way. But it also meant that we had a much bigger pool of potential customers. All we had to do was to streamline our own processes to be able to take advantage of some economies of scale.

What is still one of my favorite parts of this whole experience, though, is when I remember back to conversations that we used to have with C-level executives (usually either CEOs or CIOs) about setting up an ecommerce site. Many of them were still unconvinced that it was actually necessary. The old school, brick-and mortar retailers and catalogers were often not ready or able to see that their world was about to be completely transformed, and that the internet was going to be the heart of the future of their business.

Often times there was an internal evangelist (and in family-run businesses, it was quite often the founder/owners’ twentysomething kid who was working in the family business and trying to push things forward) who convinced the CEO to at least listen to the pitch. But even after they heard it, they were still frequently not convinced that the internet wasn’t just a fad that would go away in a couple of years, and that any investment made in the meantime would ultimately be a waste.

Looking back on it, these conversations always make me smile, because they are classic examples of adoption resistance that all new technology breeds. At the time they were highly frustrating and (from my standpoint) ridiculously short-sighted. But now I think about them and chuckle.

To be sure, each one of the reluctant CEOs did eventually have to cave to their internal evangelist and outside market expectations of their customers who truly wanted them to make their products available online — whether they chose our product or not. And, in the end, they did all come to recognize that, over time, ecommerce was essential to the health of their business. But in some case it took a while.

That experience was illuminating for me, though, and it is probably the single biggest reason that I have very little patience for the whining currently going on in the automotive and newspaper industries. To paraphrase Ricardo Semler: if you bury your head in the sand, not only do you miss vital opportunities, but you also leave your ass in the air as one hell of a big target. Those who’ve spent the most time and effort burying their heads in the sand end up screaming the loudest when they get shot in the behind. And truthfully, I have no sympathy.

Any thoughts on other value to being on ‘the bleeding edge’ of a new space?

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.