Today, the web is about marketing.  And one of the biggest influences in that shift has come from the world of search.  Findability is key, above all else.  And that means the topic of search engine optimization is one that every web professional has to be at least a little familiar with, even if it’s not your core business.

Every single week I have people coming to me to ask for help with their SEO, and the cold hard truth is that most of them have no idea what they really need, and are not prepared for what it’s going to cost (in either time or money) to get what they think they want.  As a result, these entrepreneurs are often tempted by unscrupuoulous parasites who troll the internet looking for hapless victims who can quickly and easily be separated from their money.

In his recent blog article, In SEO, There’s No Such Thing As A Guarantee, Brand5 CEO Mark Faggiano takes these spammers to task and issues a warning to those who might be tempted to bite.  Mark’s point is that, if you get an email from someone “guaranteeing” you top ranked SEO results, it’s junk and don’t buy into their promises.

For anyone (legitimate) who works in this field, this is often the very first conversation we have with prospective clients.  Why?  Because such “guarantees” are not possible.  There is too much outside of any one person’s control to be able to make promises like this.  Things change too rapidly and there is no way to ensure that what worked yesterday will work tomorrow.

Of course, this is also the reason that many people get sticker shock when they talk to a legitimate SEO about doing this type of work:  it’s time consuming, and so it is often very expensive.  Moreso than many entrepreneurs are ready, willing or able to pay.

So when I start working with a client, my first meeting with them is about understanding what truly makes sense, and figuring out a plan forward.  I start with a few basic questions when it comes to developing a plan.

What are your products or services?
Not all businesses need great SEO to get the effect that they need.  In fact, some will be better off putting those resources in other places entirely, because their customers are just not internet-centric.  Another thing to consider is that, the only way people can find you is if your product or service is something that your customers can describe/articulate themselves and would think to look online for a solution.

For some businesses that is obvious, but for innovative products or services, sometimes keyword-based solutions are the wrong way to go because your customers may not have any idea that you’ve even got a solution or what you’ve named it.

Do you have an automated sales process or a hands-on one?
If you have a product that people can find, signup and use without ever having to interact with a live person (such as WorkingPoint), then SEO has great value.  If you are someone who provides a customized service (such as a consultant), where you have to scope the job, do some research, have some meetings and evaluate your potential contribution before setting a price, then there are other areas where your efforts are going to garner better return — starting with some targeted social media.

Your prospective customers need to be able to research you online by name, but that’s probably not the way they are going to find you in the first place.  So, again, heavy investments in getting top tier SEO results are probably better allocated elsewhere.

Who are your customers and where do they spend their time?
This is the final lynchpin in developing a strategy, because you have to be where your customers are.  If your customers are corporate clients who have an internal purchasing department, then you need to spend time using their channels to get on their approved buyer list — their process usually preclude online research until it’s a last resort.

Not all customers are available via the same channels.  You need to know who your customers are to figure out how to find them.  And then figure out what internet marketing channels make the most sense.

What’s the state of your content?
As a content strategist, this is actually my last step once all of the above have been examined.  What kind of content you need on your site will depend on your product/service, your sales process and your customer base.  You can have the greatest product in the world, but if you can’t articulate it in a compelling way on your site, you will never see any conversion.

Conversely, you could have tons of great content, but if it is not organized in an intuitive and meaningful way for your customers, and if it’s not focused enough to have findable keyword value, then you could be wasting your time and effort generating content that is not serving your goal.

I start off most of my content workshops by telling attendees, “Don’t drink the SEO Kool-Aid!”  Too many people think it’s a silver bullet that is going to make or break their business.  And sure, it can be a big help, and when someone comes looking for you, you absolutely need to be findable.  Twenty years ago businesses did that buy being in the phone book.  Today we do it by being online.

But how much time and effort you should really be sinking into your SEO is a different question, and it does not have a straight forward answer.  So beyond Mark’s original warning against those who offer you guarentees, I’ll toss out a second warning: not everyone needs to be #1 on the search engines.  And the truth is, not everyone can be.  Developing an appropriate web presence is unique to every business.  Don’t let anyone sell you on the one-size-fits all fantasy.

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

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.

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.

Implications of Being “Even”
The first definition for “balance” on Dictionary.com defines the word as:

a state of equilibrium or equipoise; equal distribution of weight, amount, etc.

While I recognize that the phrase is not literally intended to mean that there should be a minute-by-minute division of one’s day, the fact is that “work-life balance” implies that one’s work and personal lives are supposed to be (at least reasonably) evenly balanced. That is a flawed assumption.

For starters, as a rather classic ENTJ, I would argue that assuming I could possibly be happy with that much of my time focused on non-professional activities is presumptuous and inaccurate. For me only working 60 hours per week is ‘taking it easy,’ and there is no way that anyone else’s expectation of how much time I “should” be spending outside of work changes the fact that is simply not who I am or who I want to be. Period.

On the flip side, the best example I know of is my younger sister. She easily has 30 IQ points on me, and yet she does not have a career-oriented, ambitious bone in her body. She has spent her entire career careening from one dead-end, mindless job to the next. She has been happiest when she was not working at all, but was a stay-at-home wife experimenting with organic and/or vegan recipes, doting over her cats and playing computer games all day. For her the only reason to have a job is to have a paycheck, and even then, only if there are not other arrangements that can be made so she can simply avoid the entire unpleasant mess.

If the universe were to decide to amuse itself and play a Freaky Friday on the two of us, we’d both be miserable. By lunchtime I’d be breaking into the liquor cabinet; and she’d probably call in sick and not bother going to work at all. By the time we switched back, I’d return to my life to discover that she’d thrown away all non-organic food products in my house and updated the OS/service packs on my computer; and she’d return to her life to discover that she had half a dozen job interviews lined up and her three rooms worth of pack-ratted storage had all been hauled to the dump. Neither of us would be happy, because both of us are most happy when our lives are completely ‘out of balance.’

Dividing the Red Sea
The other objection I have to the idea of “work-life balance” is the idea that there is a hard-and-fast separation between work and the rest of your life. I suppose for some people, this is probably the case. I have known a few people in my career who do not make a habit of socializing with co-workers and who, once out of the office for the evening, are disengaged and ‘out of pocket’ until they return the next morning. However, coming from a technology and start-up background, those people are in the extreme minority of my experience. Most people that I know flunk on the ‘work-life balance’ if for no other reason than because there is not that clear of a distinction between their work life ends and their personal life begins.

Since the time I started working full-time in my early 20′s (even before I was done with college) my closest friendships have always been with people I met at/through work. Always. And while we certainly do and talk about other things when we are together outside of the office, we also talk about work and our careers. There is no clear line where one stops and the other starts.

On top of which, there is a universal truth about the tech sector: tech geeks are tech geeks at home as well as at work. How many server engineers have you met who rebuild machines at home all the time just for fun? How many of them have servers in their garage (or pantry) that run their home network? And how many of them come into work eager to try a new trick that they spent the weekend experimenting with and want to apply it to the work environment? Ditto with developers and all other types of tech geeks. And, in a 24/7 web-run world, you never launch, upgrade or convert anything during the day. That always happens late at night. And people rarely come into the office for that. Instead, we all get online, jump on a bridge call, and work from home in our pajamas all night. Further blurring the line between work and life.

Another issue I have with this concept is that I find it to be semi-disingenuous political correctness in good times, and then completely absent in bad times. I’ve never been at a company that touted the importance of work-life balance in good times that didn’t stop as soon as economic conditions turned south.

We’ve past the point where the phrase “work-life balance” either suits us or serves a genuine purpose. The real notion is “work-life integration” or “work-life compatibility” (for the late adopters and/or non-info workers out there). Most people only work because they need a paycheck (or benefits, etc.), which means that often the life side of the equation is what matters most. Those of us who work even when we don’t get a paycheck need far more time spent on work on any given day. It’s only the small minority who fall somewhere in between really stand a chance of finding that mythical “balance.” For the rest of us, finding an integrated solution is what we need so that we can keep our focus where it needs to be — wherever we are, or whatever we are doing.

But before I get started on the specific men and the specific lessons they taught me (and yes, my list is entirely male), I figured I’d take a moment and try to define what I think makes a good boss.

Political Savvy
The best bosses are always the ones with, as I like to call it, ‘great sea legs.’ They are the people you can bring into a new environment, and they are socially and politically savvy enough that it takes them almost no time to find their balance and then successfully navigate the sometimes treacherous waters of office politics.

These are the bosses who not only roll with the punches as business conditions change, but they are also the ones who show you how to adapt and change what you are doing to be most successful because of it.

One of the greatest examples was monthly executive status reporting I was doing at one company. Our team had spent several months fleshing out the set of reports we were presenting every month to the executive to whom our department reported. The reports were geared to focus on the things that this particular executive cared about due to the nature of his role. As soon as we were moved to another spot on the org change, my boss and I worked together to re-define what those monthly reports needed to reflect, now that our executive leader was someone else, whose interest was in completely different areas.

A politically savvy leader knows when to push and when to back off; what battles to fight and which ones to let go. Without having a fundamental understanding of these things, long-term success is nearly impossible. Another common buzzphrase for this kind of self-aware, political astuteness and contextual sensitivity is emotional intelligence.

Inquisitive
A great boss asks questions — the most important two being, “Do you need anything?” and “What is it that you really want to be doing?” — and they internalize the answers.

A good boss should understand what you love about your job, and what parts of it you’d love to avoid if you could. He knows where your biggest areas of growth are, and where your biggest strengths are. He knows what you want out of your career, and where you’d like to see yourself down the road. But he knows those things because he’s asked.

(And, in all fairness, if you either do not answer or do not try to find the answers, then you aren’t doing your part to meet your boss half-way so that he can actually be a truly good boss. A good boss/employee relationship is a two-way street, and neither side can do it well if the other side is disengaged.)

“A Teachable Point of View”
To swipe the phrase from Noel Tichy, “great leaders are great
teachers.” Their underlying philosophy, the foundation for their decision-making paradigm, needs to be established and it needs to be teachable to those around them. A boss whose management style and leadership philosophy changes weekly based on the most recent book he’s read, or a leader whose solid philosophies about managing are closely guarded secrets will never be great bosses. Ever.

In order to be a great boss, you have to have both the content and desire to teach. And you need to make it a priority.

Without a doubt, every boss I’ve ever seen who demonstrates these qualities not only fosters high performance teams, but also breeds a deep respect and fierce loyalty among his staff. Among the bosses I’ve had who have demonstrated these qualities, some have been introverts, some have been extroverts; some have been C-level executives, while others have been managers; some have come from large, mature organizations, others have come from entrepreneurial startup environments. They have all had very different temperaments, personalities, senses of humor and habits (both good and bad).

But they have had two vital things in common: the above listed qualities and the fact that, whether they knew it at the time or not, they each made a huge impact on my life. So this is my Christmas card to three men from whom I learned more than I ever expected, and whose lessons impact business decisions I make daily.

• John, who taught me the value of being invested in your people.
• Robert, who taught me about the importance of owning your priorities.
• Dave, who taught me how essential it is to keep things transactional and not get emotional.

Merry Christmas, gentlemen.

So for me, the idea that a business gets large enough that you end up having specialists who are so focused on their individual discipline that they lose sight of the broader business is something that I need to be reminded of fairly frequently. Every re-org I’ve lived through since I started working in large companies has been done with the express reason that, we need to “align” IT with the business more effectively.

What struck me as more interesting — if not outright amusing — though, was the fact that I never thought about that being an issue for other departments, too. At the Conference Board‘s Change Management Conference in Chicago this week, in listening to the different speakers, it suddenly dawned on me how much of an issue this really is for ALL “back office” disciplines in large companies. IT, Finance, HR, etc. all experience the same sense of “disconnection” from the day-to-day operations of the business.

After my epiphany, I started paying more attention, and sure enough, the issues experienced by career professionals in other disciplines all look and sound remarkably similar:

• Feeling like the “bastard step-child” in the organization
• Feeling like the business units “don’t understand” what we do
• Being self-conscious about being “overhead” (especially in a struggling environment)
• Feeling scorned by the business units as “not understanding the business”
• Cultivating an ‘us vs. them’ sentiment, replete with a lot of contempt

It almost struck me as funny, because I’ve spent the past two years in an environment where one of the most high maintenance business units is actually HR. And I don’t think any of us have ever stopped to think that we are actually all in a virtually identical situation. Nor have any of us stopped to consider how a solution for one of our groups, might potentially offer solutions for all of the others, too.