The Converging Network

A Day In The Studio For The Kingdom Project

Friday was one of those truly fabulous days. I was able to spend all day Friday in the recording studio. We were laying down the rhythm tracks for some Christian music written by fellow guitar player, songwriter, and good friend, Ike Elliott. Ike has a post up about Friday on his blog too. The music is part of a non-profit company I'm involved in called The Kingdom Project. I'll tell you more about that in a bit.

Ike's been writing some songs over the past year or so, all of which I like very much. He has a real gift, writing in a style somewhere between The Beatles and Newsboys. After soliciting various opinions, the songs were whittled down to seven which we recorded the basic tracks for on Friday.

Recording music is a fascinating process. I've recorded in my home studio and professional studios. But the process is pretty much the same. The songwriter has a message and a vision woven into their songs. If you are recording your own songs, you get to decide the next steps. But here comes the courageous part. To really do a song justice you have to free it into the hands of other musicians who are part of the recording and creative process. That can be scary or it can be a very liberating experience. It's all comes down to communicating the vision of the music, and the kind of connection you have with your fellow musicians.

The process in the studio can become very technical at times, becoming all about dialing in the instruments, keeping in time with the pulse, playing the right chords and notes, keeping it in the pocket, etc. Recording is like looking into the mirror - it doesn't lie. What's recorded is what you played. If you were ahead of the pulse, even just a little bit, it all shows up. If the musicians aren't connecting, you can hear it. And when the are connecting, the music just flows. The best part is seeing what other musicians do with the song and the ideas from the producer and songwriter.

Each person brings their own talents, ideas, roots in music, etc. Most importantly is a desire to try and achieve what the producer and songwriter are looking for. They may give you freedom to do whatever you feel would work, or they may say "give me a tasty David Gilmour kind of lick right there." At one point during our recording, the producer, Jeremiah Horner, asked me to give him "the biggest pick slide you've ever done." I set my Strat so it would get the kind of sound I thought he wanted, and let'er rip as he punched it into the recording. We all had a huge laugh at just how over the top the pick slide was, but you know, it worked in the song and it's what Jeremiah had in mind. And we all liked it. It was a fun moment that everyone got a lot of enjoyment from.

We spent from 9am to 8pm in the studio and the time just flew by. I only checked the clock twice; once at 12:45pm when my stomach started growling, and then again at 6pm. Each time it only seemed like an hour or so had gone by. Time in the studio goes fast because you're so focused on what you're doing, and because you're having so much fun.

We're planning to go back in the studio in June to do some doubling, overdubs, vocals and solos. That's yet another kind of creative process that I'm looking forward to. In the mean time, I'll be practicing using the rough mixes Jeremiah gave us on Sunday.

A little bit more about the project... This recording is part of a non-profit company called The Kingdom Project. KP is all about helping emerging Christian artists get their music produced, recorded and promoted. We're developing a web site with all kinds of resources to help new songwriters get a leg up on the ins and outs of copyrighting their music, and getting a demo or a CD made, and connecting with others who can help them. We also connect folks interested in sponsoring new artists or projects with songwriters, producers and musicians. Ike's recording is the first project we've initiated. We'll plan to begin our second project sometime later this year.

So if you are interested in learning more or getting involved, please feel free to contact me. We're looking for songwriters, sponsors, and help with the web site and content.

Sun Engineers - I Know Where The Rock Star Jobs In SaaS Are!

With the eminent round of additional layoffs coming at Sun, there have to be some real rock stars out their looking for their next move. So... if you are a rock star pre-sales engineer who knows how to sell solutions and would like to get into the exploding SaaS market... or you are a top QA engineer who loves testing, automation, and digging out the toughest to find bugs... you owe it to yourself to check out these open positions at my new company, Absolute Performance.

Send your information to jobs@absolute-performance.com. Tell 'em you read about it on The Converging Network blog.

Rock On!

Get Ready For XaaS Everywhere

With the soaring interest in Software-as-a-Service (SaaS), we are already seeing the same metaphor used for other service offerings. Platform-as-a-Service, or PaaS, is becoming a common place term. Now I've also seen IaaS, or Infrastructure-as-a-Service. As I like to say, no good idea goes un-copied. What that means is we should all expect to be overrun by the use of XaaS terms, where X equals whatever word or phrase any vendor, analyst or marketer chooses to promote their product or service. If Sausage-as-a-Service will help sell more processed meats, you can bet someone will jump on the bandwagon and leverage XaaS to their benefit.

If imitation (being copied) is the most sincere form of flattery, then I'd say SaaS is gaining enough traction that others are coping the XaaS term for their use. But we shouldn't forget, what this all really means to us is that software, infrastructure, data, etc., etc,. are all moving into the cloud, being offered as a service.

So if anyone needs any Blogging-as-a-Service, you know where to contact me. :)

Unbelievably Bad Web Password Security

I was shocked today because I had two very strange but similar experiences with passwords. Both involved accounts with online web sites/services, and both involved some pretty fundamentally bad password limitations. I'm half tempted to name the sites here but elected to contact them privately about the issues. What were the issues?

Absurd limitations in user account passwords. The first site would not allow a user password longer than 10 characters. Ah... last I heard, longer passwords (to some extent) are generally better, as long as other policies like requiring caps and numbers mixed in. All of these, including password length, help against brute force attacks. The second site did not allow special characters in the password. Adding a special character here or there is another common method of making passwords more difficult to crack. I just found it strange to run into two sites with such odd password limitations.

Wikipedia has some good information on basic password security. I hope it can be of help to the sites I visited today.

Measuring Leadership - What Happens When You're Not There

Last week a close friend lost her spouse very unexpectedly. All of us who participate under her leadership in our music program (band) at church were shocked and grieved for such a devastating loss for a close friend. It was truly heartbreaking. The experience is one I would of course not want to have go through if given the choice, but it did reawakened for me something I've believed about leadership for some time. So I share these thoughts about leadership, keeping in mind they pale in comparison to the gravity of last week's events.

There are many ways to assess, evaluate and measure leadership. Bottom line results, leadership style, strengths surveys, 360 degree performance reviews, action under fire... I could go on and on. But one measurement that is often overlooked is, what happens when the leader's not there?

I enjoy, respect and thrive under many leadership styles, but value much less charismatic and personality driven teams. They rarely hold up in the long term, and usually hit some ceiling frequently not surpassable without a significant change of leadership. Those approaches are usually too dependent upon the capabilities and characteristics of one person. Leadership solely vested in that one person also means you live with their limitations too. At least that's been my view.

I believe leadership is about enabling the team and organization to achieve its best results, growing and thriving in the process. Flourishing is a great way to describe a high performance team. It's about enabling people to succeed. It's also about creating a shared vision, with clarity of purpose, goals and a high degree of mutual accountability within and outside the team. I also subscribe to the view that if you believe in people, truly believe in their power to succeed, they'll do just that, and more.

Want to see how effective leadership is? Remove the leader and see what happens. You'll quickly spot where there's deficiencies in communications, continuity, goals, empowerment, decision making and many other areas. You'll see bottlenecks or pent up issues pretty quickly. If the team can't continue to excel, at least for a reasonably short time, you don't have a team, you have a group of followers. Now, see what happens when a curve ball shows up. That also gives great insight into how effective the team's leadership is.

So, bringing this all back home to last week's experiences. Sunday's services went off without a hitch, even without the week's normal 2 1/2 hour rehearsal. Some band members had never even heard the music prior to Sunday's early rehearsal. Everyone involved (probably 25-30 people) all to a person stepped up and volunteered to help out in whatever way was needed. Team members changed previous commitments to be available. And we'll continue this and more until our leader returns, whether that's one week or six weeks from now. We have a shared vision and purpose for our music, we know how to execute and fill in when someone suddenly needs to step out, we know how to adjust (flexibility is one of our key attributes), and there are many capable leaders within the team who can step up and fill the gap until she returns. 

Most importantly, none of us wants to let down the leaders in our organization. Our mission is to continue delivering on our goals without a drop in the quality or capabilities of our music. Matter of fact, our goal still continues to be raising the bar of our music program. We value our leaders too much to do anything less.

Back From Hiatus, Saved by Web 2.0 Technology

Well, I'm fresh back from my unannounced trip to Hiatus. It's a long, sorted and torrid story. To make a long story short, I was held captive in a primitive cave in the mountains of Afghanistan. But thanks to my recent training at RSA, I was able to communicate an SOS via a crudely crafted, low-fi Web 2.0 web service. Fortunately, some Yahoo! stockholders happened across my plea, and aided in my rescue in the hopes that after returning to civilization I might be able to use my Network World blog to sway Microsoft and Yahoo back into active merger talks. Alas, despite my best efforts, Yahoo continues to stumble along on its own, suffering a 14% devaluation in the markets today. None the less, it's great to be back!

Okay, seriously... I wasn't in Hiatus, but just on hiatus from blogging here for a bit. ("Back from Hiatus" is an old joke from one of Alan and my podcasts a while back.) I've just been overwhelmed recently with all kinds of work and personal activities, that includes attending four different conferences in the last 2 months, practicing for an upcoming CD recording project (we're in the studio this Friday), launching a new product release for Absolute Performance, setting up several new partnerships, rebuilding a corporate web site, digging deep into Microsoft's Live Mesh strategy, and building up my blog readership on my Network World blog. No excuses, but that's some of the things which have been occupying my time.

So... back to more blogging on The Converging Network. I'm really energized about what I've learned from the SaaS marketplace, and activities by the likes of Microsoft, Google, Salesforce and Yahoo. Some of it also comes from reading Nicholas Carr's book, The Big Switch. And of course, I have a lot to say about security, networking, virtualization and creating products.

It's good to be back.

It Takes a Village.. ah, actually, being there first and tons of hard work

I'm proud to say my old company pulled a two out of three and won the SC Magazine best endpoint solution of 2008 award again at RSA. They were also finalists in three other product categories, products all of which I can beamingly say I had a hand in creating. What's different about the SC Mag awards from many others is these awards are voted on by the readers, both users and followers of what's happening in the market. While others have suffered the percentages of the startup business, others march on to live another day.

The NAC market has been a tough slog, one of those markets that's experienced a great deal of attention and hype. None the less, products have to prove themselves, no matter how shiny and exciting they seem to be or how big the analysts say the market will be in five years. NAC's not an easy problem to solve and I'm proud the StillSecure has stuck with it to continue leading the market against heavyweights like Cisco. Frankly, this market could be all sown up if Cisco had purchased the right product several years back. (And guess which product that would be, I say tongue in check. :) )

I always enjoyed the claims other startup vendors would make about "being there first" and owning "xx" double percentages of the market, when in fact I was part of creating one of the first purpose-built NAC products from the ground up before NAC was even a term. The idea came from customer experience interviews I was doing for a completely different product idea, and up popped the customer problem that later became a NAC product. I still remember the excitement of sharing the idea with the team. Serendipity I say.

Net-Net, congratz to my old team on the awards and the continued market successes. The award is just one of the ways to visibly see all that hard work pay off.

Security Industry Missing Ride On The Cloud

One of the things I was interested to investigate at this week's RSA conference was whether SaaS and cloud services (compute, storage, etc.) had entered into the horizon of the security market. The answer is easy. NO. Not even close. Security doesn't get where the software market is headed and we need to get after it now.

There's two perspectives to assess this from; What are security vendors doing to build products for the On Demand, SaaS and cloud computing world we are rapidly moving into? And, are security vendors moving into offerings based in the cloud themselves? Again, with a very few exceptions this isn't something that even appears on the radar screen of RSA exhibitors.

Regarding the first question, the themes of RSA is still very much in the world of data protection, data lose prevention, network access control, USB storage containment, and infatuation with the latest 10 gigabit doodad appliance box.  Maybe its too early for security in the cloud to be the issue of the day - security in the virtualized world isn't even a topic for conversation. At least a few smart people like The Hoff are playing virtualization MythBuster, keeping us honest about what challenges and interesting problems need to be solved as virtualization continues its march into data centers, storage and applications.

How about those offering their security wares via the cloud? Clearly Qualys suffered the arrows of being an early SaaS security vendor but crazy frenchman Philippe Courtot is still riding high knowing the SaaS market is doing well within other segments of IT and security will eventually get there. But they are still pretty much a lone SaaS delivered security player. Another company doing SaaS delivered security products is Alertlogic, providing log management, analysis, and compliance software On Demand. I spent some time with Alertlogic CTO Misha Govshteyn, someone who has been through the transition to SaaS and learned the lessons needed to scale a multi-tenant product. (Misha's a smart guy, btw. You sooooo need to start blogging dude!)

I think Misha's approach also shows some insight into where we'll see SaaS enter into security - in the mid-enterprise and SME markets. Those are buyers who don't necessarily have access to full time security, storage or other specialized resources. They also are more accepting and can get over the perceived privacy concerns that surface when considering an On Demand service, especially private companies who don't fall under SOX compliance. I still recall selling against Qualys and pushing the issue of your vulnerability data being stored in the cloud - many saw the advantages and convenience from an On Demand offering, and for yet many others it was a no-op. But mid-enterprise and SME's adoption of On Demand software solutions could show us this is where security will make it's first SaaS market beachhead.

As security professionals, we can't wait for the market and vendors to catch up. We need to be creating the security dialog and debates about virtualization, on demand and cloud based services. While Microsoft may be trumpeting the call of End-To-End Trust, trying to get the other elephants to tap dance with them, we've got to working ahead of the curve on the tough problems, vocalizing the security needs while services are being created and moving into the cloud, not after. I'm glad that Hoff, Misha and others are thinking ahead of the curve.

Product Bistro: Love Developers, and Trust QA

I was talking with a friend and fellow musician Jason Mendelson last week and the topic of software delivery came up during our conversation. Jason knows that I have a lot of experience leading product teams to bring software products to market. I've learned a ton about shipping products and if there's a mistake you could make, well, I've probably made it at one time or another, and sometimes more than once.

When it comes to shipping software, delivering software releases on time is one of those seemingly elusive concepts that most everyone desires but frequently don't achieve. (I actually believe delivering on time is a learned behavior, but that's for another blog post.) Quality can also be an elusive goal, especially for startups who may not have a lot of experience working together as a team, or are under huge pressures to deliver releases. Dialing in on the winning customer experience and product feature mix is another passion of mine that's vital to creating great products. I could blab on about all these subjects but a philosophy of mine about creating software caught Jason's ear; "Love developers, and trust QA".

These days I'm frequently a coach or mentor to someone who is leading a product development effort, sometimes for the very first time. Frequently they've come up through the developer ranks with a lot great experience that sets them up for new opportunities leading product development efforts. I always try to help them understand a key lesson I've learned; while I love software developers and the innovative work they do, I trust most what QA software testers tell me about the quality and completeness of a software release. I've advised more than one development manager that even though you may not always like what QA has to say (you may even dread hearing it), you need to hear it straight -- they're looking out for your best interest.

Software developers, engineers, artists, or whatever job title you chose to call them, are a loveable, creative, quirky, smart bunch of people who have to try and envision how best to build software that embodies the vision and needs of the business. They are a great group of people and I love hanging around them and being part of the team. Sometimes product developers get great direction and it seems more often than not a lot is left up to their interpretation when creating a new product. Hopefully someone is giving them great input about the target user personas, product requirements, user interface design and help with key decisions about the product architecture and which options help the business most achieve its goals.

But inevitably, releasing software products can become a grind. What's after this release? Another release. And after that, another release, etc., etc. It's hard work and developers are frequently in a situation where they have to be as productive as possible, inevitably making decisions that could make or break the product's quality, feature set and success in the market. Developers have a lot of competing needs to balance and are often asked to make decisions without the time or input that might help make that decision the best one. That's where the development leader, manager and/or product manager comes in, btw, making sure the development team grasps the impact of various options and decisions, and also that business leaders understand consequences of certain demands which could impact the product or the business. But that's why I love developers -- with all these things to consider, the best plow through and get the right things done to create great products.

It's also why asking a developer questions like; Is it done? Is it tested? Does it work? Is the quality better? Did we find all the problems? Is this going to satisfy what our customers asked from us? Is it ready to ship to a customer? I could think of a million questions that while I've asked developers, I know I may not have gotten a completely accurate picture based on their answer. In many ways developers are too close to the problem, head deep into creating the solution we need. One developer is likely only working on one portion of the software release, and more work is required to integrate and get all the elements of the full release working together. That's why everyone knows that to get quality software you shouldn't rely just on developers themselves testing their own code. That's also why I trust developers, but I trust QA engineers more when it comes to understanding the true state of a software release.

QA guys (guys and gals) tend to think very differently. Their job isn't to create stuff, it's to break it -- anyway they can. Because if they don't find a problem, that means a customer will. And some people just have a real knack for it. The best are also very detail oriented, don't assume anything and watch to make sure nothing gets by them. The best QA engineers are also very good about tracking results, creating thorough test plans which get a lot of scrutiny by everyone including the developers, automate testing, and understand the value of metrics and how this can raise the learning and skill of the entire team at releasing quality software on time.

QA engineers are also the first point in the process where someone is actually trying to use the software. Functional testing doesn't always drive this out, but scenario or use case based testing can make a really big difference. Using your own products in your lab or by your IT staff can also be a great way to get real usage feedback, in addition to customer experience testing of course. Testers also have great suggestions about the product. They catch nonsensical error messages, product inconsistencies, or encounter areas of the product that are hard to use. Most importantly, QA engineers know they are the last in line to judge the release, and take their responsibility very seriously when it comes time to say whether they think the release is ready or not. QA engineers aren't just critiques, they want to ship the product too. They just don't want to be embarrassed, taking it personally when bugs or quality issues escape the testing process and are found by customers.

I also believe the effectiveness of any QA team or department is a direct reflection on their leadership, including the visibility, importance and voice given them in the product development process. One of the things I've learned to do as a development manager, VP engineering or CTO is to hold my own weekly meetings with the QA team. Development managers are welcome if they like too. This is our time to talk about release testing, QA processes, metrics, test plans, lab needs, improvements, suggestions, issues escalated from support, and -- most importantly -- give QA a voice directly to the top of the organization to say whatever needs to be said, good news or bad.

I hope this explains some of my learnings around the philosophy, love developers, and trust QA. The fact of the matter is that I love them both for what they bring to product development, and I trust them both too. But I rely on their skills, experiences and judgment differently, and at different times, bringing the best strengths of both to release great software products.

We're Hiring - Sales, SE, QA and Exec Assistant

We have a number of job openings at my SaaS application performance management software company, Absolute Performance Inc.

The following positions are open:

• Regional Account Manager - West Coast
• Sales Director - Boulder, CO
• Sales Engineer - Boulder, CO
• Software Quality Assurance Engineer - Boulder, CO
• Executive Assistant - Boulder, CO

Send your information and inquiries to jobs@absolute-performance.com. (And let them know you read about it on my blog.)

Breathing Your Own Exhaust

One thing that happens to everyone at one time or another is when you become so engrossed in your own world view, you start to believe everyone else thinks the way you do, or if they don't, your spin will fool them. Doesn't matter whether you're big like Cisco and Microsoft, or the latest startup on the block with a new mouse trap. You hear phrases like "he believes too much of his own press" (I'm sure that's been said about me more than once, lol) or "they've been breathing their own exhaust too long."  I blogged about what could be one such case of this, Microsoft's self makeover to be perceived as "open source friendly". Another example is Microsoft claiming it supports Linux in Hyper-V, but only if it's Novell's SUSE Linux.

I'm a big believer in ideas like enrollment, passion and engagement, and to achieve these you have to believe in what you, your product and your company are doing. Doesn't matter if you are the press spokesperson or the person answering the customer service phone -- everyone else can pretty easily tell if you are enrolled in what you are doing, or it's more a matter of your going through the motions.

But that same passion and engagement can also create a blindness, especially in entrepreneurial environment where passion, ideas and commitment runs high. It's easy to build a wall around yourself or your company, focusing just on what's happening inside your product, the product development efforts, or even the geographical market area where you are physically located. My very good friend Alan Shimel used to frequently tell me "you need to get out of Boulder more often", not because Boulder isn't a good town (check out Brad Feld's blog post about Twenty-Five Square Miles Surround By Reality), but to really understand the industry, competition, customers and the market.

I recently blogged about (tangentially as it relates to partnering) the bubble effect that can happen in a startup company. It is very easy to become so engrossed in what you are doing, crafting your marketing messages, building the product, training the sales force in the ways you want them to sell, that you forget there are other people out there. Companies may claim to already do what you do, cover the same supposed differentiators, or have already beat you to the punch but you just don't know it yet. I call this inward looking focus, "staring at your own bellybuttons."

There are many things I've found helpful to me to try and avoid this. In a leadership role you probably have more opportunity to take advantage of these but I believe in any of our roles you can find a way, or even ask to participate in these kinds of activities. Here are a few ideas.

1. Never turn down an opportunity to talk to a customer. Doesn't matter if they are a sales prospect, an unhappy customer who wants to scream at you, or one that's nicely tucked in and happy. If you have a chance to talk with or meet with a customer, always, always do it.

2. Support your company's trade shows and marketing events. I learn more about the industry at many of the trade shows I attend than I probably do by reading about companies and the industry online. Even if you aren't one of the marketing dudes or dudets who normally cover these events, ask to go and help out. Stop by everyone's booth, introduce yourself, listen to their pitch, ask questions and learn. It's so invaluable.

3. Be well read. Read everything you can get your hands on. I get between 30 and 60 Google alerts each day. That's in addition to all the email and blog reading I do. I don't read them all, just the ones that really catch my interest, are newsworthy, are something new, or are on a topic I follow. Read blogs, news sites and portals.

4. Inject what you've learned.  Share it in meetings, on calls, in product discussions, in planning discussions, with customers, etc. Bring that information to everyone. Forward relevant info (but don't spam) to others in your company. Add your comments/insights up front so they know whether the article is worth the read or the value is in your insights.

5. Talk to every company, not just the ones you like. Go talk to your competitors. You might find out they could actually be your partner. Or, they may still be your competitor. But go meet them. As Alan also told me many times, "stay close to your friends, and even closer to your enemies."

These ideas are pretty basic and simple, and while they might not shake up the world, they could redefine how you view your own business.

Zero Day Threat & My First Book Jacket Quote

I'm a big believer in serendipity, karma and helping people whenever I can. A lot of people have been very gracious to me throughout my career, and I'm always looking for ways to pay it forward. That's one of the reasons I coach entrepreneurs and enjoy starting new companies so much.

Back in 2001-2003 I started getting much more involved in the external aspects of the CTO role, working with press and analysts, writing byline articles, speaking, etc. Though I had been in a few press interviews (my first quote was in the London Financial Times in 1986 while helping with some story background), I was a huge neophyte when it came to doing media work. I received some extremely valuable coaching from Sonya Caprio at StillSecure along the way and now am pretty comfortable doing just about any media, writing and speaking work.

Early during that learning process, USAToday reporter Byron Acohido got a hold of me while researching stories about various computer security threats posed to the average computer user. This was back in the Code Red and Melissa virus days. While I'm no security researcher guru by any stretch, I've been working and creating security and networking products since the early '90s, so I was able to help Byron on background, tutoring him on the various kinds of threats, how they worked and what the current and emerging threats were around the corner. Though I didn't expect any quotes from those conversations, Byron was kind enough to quote me in 4 or 5 USAToday stories.

When I talk to press I always offer to help on background, specifically noting I have no expectations for quotes. Part of my job of course is pitching media about my companies and products when that's the topic, but I also believe in helping people outside of my own agenda. I do this with no expectations of any payback or reciprocal quid pro quo to me. If you help people, even if they don't return the favor directly, someone else down the line might return the favor to you. And even if the favor is never returned, that's okay.

Helping people with the expectation of something in return isn't helping, it's trading. You don't help people with a payment expected in return. You do it because it's something you want to do. Good karma, serendipity, etc. will take care of everything else. Trading has an expectation of something in return, helping doesn't. I'm not naive enough to believe that everyone has this philosophy -- many don't. Even with some, everything has strings attached, but that's not me. As long as people don't take advantage of that goodwill I'm happy to help, and if they do, it says a lot more about them and than me. I just have my own philosophy about helping others.

After my media work became more focused on the business market and Byron expanded his sources to researchers much more talented than me, we talked less frequently but still kept in touch via emails. Bryon is good about emailing his network whenever he writes a new piece, is looking for feedback or is seeking out knowledge in new areas..

A year or so ago, Byron sent out an email about a new book he and USAToday reporter Jon Swartz (who I've also done interviews with) were working on. Bryon has a background in investigative reporting, having won a Pulitzer Prize for beat reporting about his investigative reporting of Boeing 737 tail rudder problems and related government foul ups. Jon has also been nominated in the same Pulitzer Prize category.

I checked out Byron's and Jon's site they'd set up about the book, Zero Day Threat. Byron sent me an early look at some sections of the book, which I blogged about in a post last year.  Later Alan Shimel and I had Byron on the SSAATY podcast to talk about the book they were writing. Later, Bryon also offered my some sage advice to me about setting up my Converging Network LLC company and doing additional media work after leaving StillSecure.

Zero Day Threat is a fresh, unique look at how actions by financial, credit, technology companies and "the bad guys" not only put everyone at risk for identify theft, but result in a large number of identity theft victims because they fall in the margin of acceptable risk. Companies are playing lose with our identities because it's an acceptable level of risk to them, not us. The book is available in books stores April 1, and has already started shipping through Amazon.

This week I received a copy of Zero Day Threat in the mail from Byron. I'm very to pleased to have my first book jacket quote on Byron's and Jon's book (see below). And I also appear in the acknowledgments, along with a very nice hand written note from Bryon inside the front cover of the book I received. The quote came from something I wote on my blog back when I reviewed some early parts of the book.

I definitely never expected or even thought I'd receiving such acknowledgments, and I'm totally honored and flattered Bryon, Jon and their editors chose to acknowledge my small contributions. I also owe a dept of gratitude to Sonya, who helped me be in a position to contribute to Byron and Jon.

What this experience says to me isn't that "doing something good will get you quoted", but that you don't always know the impact you have when helping someone else. My few conversations with Byron must have been much more valuable to him that I ever realized. The satisfaction I'm feeling is more about playing some small part in helping Byron and Jon be able to write their book. The quote is gravy, and really something I take as a thank you from them both.

You never know the impact you have on people. Sometimes you learn about it later, such as in this case, but most of the time you don't. That tidbit, coaching, idea, compliment, comment in passing or something you didn't even realize, may have had a very significant impact.

Whether my philosophy about helping others has zero, a little or a huge impact on readers, I'll likely never know. Maybe it won't have an impact on anyone. Whatever the result, I hope you received some enjoyment from reading about my experiences with Bryon and Jon.

Here's my quote that appears on the Zero Day Threat book jacket:

"Rushing in to profit from online commerce and banking, financial institutions knowingly put our personal information and identities at risk -- the digital-age equivalent of tobacco companies making sure cigarettes have highly addictive properties." - Mitchell Ashley, security consultant, The Converging Network

Please check out their new book and the blog at their site. I hope they are both wildly successful.

Does Your CEO Have Fun?

I've been fortunate to start or be a part of a number of startup companies which is something I thoroughly love to do. I've always been a "culture person" to varying degrees too, sometimes playing a big role in shaping or changing the culture, and other times just working as part of an existing company culture. By "culture person" I mean I place a lot of importance on the culture of a company and believe it is something that deserves a great deal of purposeful time, attention and personal investment. 

Sometimes you make a very active and concerted effort to build a company culture around a set of principles, like when creating BoldTech Systems, we decided we wanted to create a learning organization along with our other core values. We spent a great deal of time those first three years implementing processes to achieve this goal, like company off sites, learning circles, creative tension, focusing on personal goals and growth in performance reviews, and teaching many ideas from the MIT Learning Lab and Peter Senge's book The Fifth Discipline. As a consulting company, that meant some significant time was spent that wasn't billable, but the results created a great place to work and made attracting great people much easier. I was and still am very proud of the culture we created there.

My experiences are also that if you don't make conscious decisions about your corporate culture, one will form around you anyway, and possibly one you'll later wake up to and find you don't like. And not everyone is "touchy, feelly" and into the culture thing -- it's not everyone's bag, so to speak. But in either case, I've learned that in startups culture is always strongly driven by the top management of the company, and most specifically the head of the company -- the CEO, president, founder, etc.

Companies are strongly influenced by and take on the personality of their leaders. Even members of the executive team take their cues from the top person. My philosophy is that small companies are about personalities, and big companies are about politics. (This is a topic I plan to blog more about sometime.) Employees, execs and management within a startup quickly learn what the head person does and doesn't value, and behaviors shape around those values pretty quickly.

I've come to learn that if I'm going to work at something, I really want to have fun doing it. Fun not just in meeting revenue and business goals (and yes, it's a lot more fun when you achieve those), but fun while doing the hard work is takes for a startup company to win. Having fun is part of the human spirit, something we should NOT hide or suppress (Carol Ross blogged about this recently.) One of the ways I know I'm having fun is when I realize I've had a smile on my face during the day.

Fun is infectious. If leaders in the business are having fun, that's going to spread and have an impact on others. Someone who exemplifies that is the CEO of Absolute Performance, Jerry Champlin, where I'm CTO. Jerry has fun at what he does. He frequently walks around with a smile on his face. When you talk to him, it's not unusual for the conversation to have a light hearted moment or two. And when out with the troops, Jerry doesn't hesitate to let his guard down, be himself, and have a good time with the employees in the company. Its also created some strong, long term working relationships. Don't get me wrong, Jerry's not just some social butterfly, flitting around spreading good cheer. But when the CEO has fun, you can tell it has an impact on other people.

A company's soul is its culture. You can walk into a business and pretty much get a quick feel for the place. Is there excitement in the air? Are people engaged, interacting with each other? Is any one having fun? Or is the place cold, almost having a suppressed or even a dead feeling. I'll bet you can look to the management team and see if what they are creating is a vibrant culture or one that's all business. And I'll bet if people are having fun, there's a much higher degree of engagement, leading to more significant results and personal pride in those results.

So, I just wanted to thank Jerry for setting a good example about having fun and Carol Ross for blogging about not hiding the human spirit. It inspired me to write about some of my own thoughts about culture, having fun and showing others that it's okay to have fun while creating success.

Now... At work today, put a smile on your face, do something that brings fun into your meeting, conversation or personal interactions. And see what impact it has on others around you.

Product Bistro: Demo in 5 Clicks or Less

As a companion to my last post about Mitchells' Rules of Demos, there's another learning I've had about giving product demos. You will give a much better demo if you can demo your product in 5 mouse clicks or less. (Assuming your product has a GUI interface.)

I was once doing some sales training with some very talented and capable sales team members. During the training, one sales person stated that the product had so much in it they were struggling to learn everything the product did. They didn't know which buttons to click on or not when giving a product demo. "Do you begin in the configuration section? Should you jump right in to the [blah] section of the product? What do you like to do, Mitchell?" were the questions.

My response was, "You're probably giving the wrong demo if you are clicking on tons of stuff. You can give a great demo by just clicking on just a very few things." Everyone in the training session looked at me like I had asparagus sticking out of my ears and hollandaise sauce running down my head.

The principle behind my thinking is that clicking on lots of stuff means you are probably getting lost in the product details, likely giving a functional decomposition demo, and not focusing on how the customer's problems can be solved with what you have to offer.

So after some more of the hollandaise sauce dripped off my head (metaphorically speaking), on the fly I responded, "Let me demonstrate. How many clicks will you give me to demo our product?" The questioning sales person said, "Ten."

Since I like a challenge, I said, "Well, I can actually do it in zero clicks, but I'll do it in five." Everyone laughed an uncomfortable laugh, like when a lightweight wrestler says he can pin the heavyweight guy in one round. "How much time do I have?", I asked. "5 minutes", was the comeback.

I gave myself a few seconds to reset where my head was and get into presentation mode. I started out by saying, "Mr. Customer, you told me earlier that the problems you need to solve are [blah] and [blah]. Here are the five things we do that help you solve those problems. First let me set some context about how we approach the problem...". After setting the stage, giving the audience a <-- YOU ARE HERE description of what they were about to see, I used my five clicks to navigate to sections of the product that I wanted to illustrate both what we do and how we solve the two problems as well as mentioning a few other customer problems we've addressed with our product.

After concluding the demo, which took under 5 minutes, and summarizing what we saw during the demo, I asked the sales person, "How'd I do?" The response? "I give, you're right. You don't have to know what every button does, or even most of them. I get what you are saying. You are giving a different kind of demo than I was thinking about."

"Cool", I said. "Do you see how I could have given the demo with zero clicks, by just pointing to the main screen in our product?" A few sorta-believers nodded their heads.

I'm of the belief that a sales person needs to be able to give at least a basic level presentation and demo of their products. But that doesn't take knowledge of what every bell and whistle does in your product.

"Let your sales engineer be the person who knows what every button does. That's their job. They can always jump in and help, or answer those questions." Or if you are going to be taking a deep dive, let the sales engineer drive the demo, but your job is to keep on point, what I described in Mitchell's Rules of Demos.

Now I'm not saying every demo should be done in 5 or less clicks. The idea is that being able to do this helps you not focus on all the bells and whistles, but orient the demo around matching up the customer's needs with your product. And you should be able to give a zero click demo in situations where you are standing in front of your trade show booth, telling an interested party about your product.

So.... If you'd like a challenge, see if you can do it. Can you demo your product in 5 clicks? Or less?

It might take some practice. I believe in you. You can do it.

Product Bistro: Mitchell's Rules of Demos

I've done a ton of software and product demos over the years, starting with the first demo of a graphics program I wrote on an Apple II+ to my fellow classmates in a college programming class.

Ever since, I'm usually the guy to give demos to customers. Sometimes I wonder why I'm the "demo guy" but inside I really know why. Most product demos are very poorly done because they start with the wrong objective in mind.

Most bad demos are what I call "functional decomposition" demos. You know what I'm talking about -- after some perfunctory sales questions, the demo conversation goes something like this...

"This is the blah screen. The blah screen is used to create blah's. You can have an unlimited number of blahs, and can name blahs any way you wish.

Pushing the Create button opens up the window where you enter the name of the blah, and all the attributes of the blah you want to create... the blah type, a description of the blah (it can be as long a description as you wish), etc., etc. I won't go through all the settings on this screen right now, but you get the idea here about how to create blahs.

Next we have the list blah screen where we list all the blahs in the system."

... and so on, and so on. It's a description of the product, a feature walk through, and what everything does. It's like a verbal User Guide told to people who probably never wanted to read the User Guide in the first place. Not interesting, very boring and it doesn't connect with people. 

I can't tell you how many sales people, SEs and technicians I've seen give demos this way. Being on the receiving end of one of these demo is bad enough, but whenever someone in one my companies gives a customer this type of demo, I think I get a little bit of throw up in my mouth. (Sorry to be so graphic.) In my book, you just lost a perfect opportunity with the customer, and you've left them with figuring out why and how they'd use this product to solve their problem.

Mitchell's Rules of Demos

I only have two rules. There's only two because without achieving these, everything else doesn't matter.

1. The Goal

There's only one goal of a product demo, and it's not to show the customer the features of your product. Here's the goal.

You want your audience to envision themselves, or their organization/company, behind the wheel using and benefiting from your product that solves their problem.

Now, study it, practice this, and above all, only consider your demo successful if you get signals from the audience they are now in this place. You'll recognize comments from your audience when you are achieving this goal. Statements like...

"This would let us ..."

"With this product we could..."

"Now if Bob down in Finance had this, it means I could..."

"Could this replace...?"

And if you aren't hearing statements like these, ask your audience; "What parts of what we're talking about today could you see using  for the problem you told me about?"

In the end, the customer has to envision how what you are showing them solves their problem. You are leaving a great deal to chance, e.g. you're not likely to be successful, if you force the customer to make the mental leap from what your product does to their own business problem.

Your job is to be the Sherpa guide, easing the job of making that mental leap, so participants can easily cross the the divide needed to make the connection between their problems and how what you have to offer solves those problems.

How do you do all this?

Here's some suggestions:

• Build your demo discussion around the problems the customer has told you about.
• Talk about how they would use the product, not how the product works.
• Talk about how your customers use the product to address similar problems, and other uses that tie in with this customer.
• Use scenarios and fit the product into the scenario that look like the customer's situation.
• Check in and ask questions to see if this is at all connecting, and if so, what's connecting and why.

The best way to sum it up is that a product demo isn't really a demo, it's about a conversational story. The story you are telling is about how this customer and customers like them use your product to address their need or solve their problem.

2. Set Context

Have you ever gone into a meeting with a vendor, realizing you've pretty much forgotten most of what was said in the last meeting with them? Maybe you even forgot exactly what they do or what their product does. Maybe you are one of the participants who hasn't been in previous meetings and you are new to the discussion.

This happens all the time. Just because you live with the product everyday or have been thinking tons about how to sell to the customer since your last meeting, doesn't mean they have. You always have to set and re-establish context.

Context is that map in the mall shopping center with the arrow that says <-- YOU ARE HERE. Because there has been a gap in time and/or because there may be new participants in the demo meeting, you have to briefly re-establish context. If there are new participants, you'll need to spend a little bit more time up front doing this.

Here's what you need to summarize:

• Who you are. "Hi, we're will ABC. We solve the blah problem for A, B and C type customers like you."
• Confirm you still understand the problem. "Through our discussions, you've helped us understand the problems you are looking to solve are.... Do you feel we have a good understanding of the problems? Has anything changed since our last meeting?"
• Confirm what they came to see. "Our goal today is... Are there any other expectations of today?"
• Tell them what they are going to see. "Today we are going to show you how blah can solve the blah problem."

And then at the end of the meeting, circle back around to determine if you've addressed how you can solve their problem or need. And also re-emphasize all the benefits you've touched on. It's akin to what you learned in speech class in high school and college; Tell them what you're going to tell them, Tell them, and Tell them what you told them.

I also can't emphasize enough revisiting the customer problems you've uncovered during previous discussions. Things may have changed since your last discussion. Maybe their understanding is deeper or different. Maybe their situation has changed and what was a priority has now been replaced by something else. Maybe some other vendor came in and change the game since your last visit, laying some land mines or booby traps for you to stumble into. Lots of things could have happened and you don't want to be operating from the wrong or outdated perspective. Last week's highest priority project could be in the dumper this week. Things change so don't assume they haven't.

Remember, setting context is two way, for both you and the customer, and it's just as important you know the customer's current context.

Wrap Up

I hope you find these two rules as beneficial as I have. They have some far reaching implications to the logistics of product demonstrations, especially the type of demo data needed to give a conversational story demo rather than a feature based demo. If you start with these two rules in mind I think it will drive a number of downstream logistics and help your demos accomplish a great deal more than what might be happening today.

Try it out, and give me your feedback. I'd love to hear if this is helping you and hear about your views and ideas on product demos.

How to make a guitar player love you forever

I received an email today from our praise worship leader with an email request she had received. It read,

So... I just want to know if there's going to be that 70's wacka-wacka guitar sound on Hosanna?  I love it - it cracks me up!

So, if for some strange reason you want to make kudo's with a guitar player, especially an electric guitar player, here are a guitar players three most favorite things to hear...

    “Could you turn up your guitar more?”

    “Play that really cool riff you did on that one song.”

and …

    “Can you make that really cool [fill in the blank] sound you did on that one song?”

More micro-podcasting

I've posted up a 2nd micro-podcast interview with Treb Ryan, CEO of OpSource, on my Network World blog.

Any feedback is appreciated.

Trying out new "micro-podcast" format

I know that not everyone who reads blogs also likes to listen to podcasts, and visa versa. So I decided to try something different and see how readers and listeners like it. I call it a "micro-podcast". (Let me know if you think of a better name.)

Last week while at the SaaS Summit conference in San Francisco, I interviewed Michael van Dijken, head of marketing Microsoft's efforts to support the hosting and SaaS software market segments. I posted the interview with Microsoft's van Dijken up on my Network World Converging On Microsoft blog using this new format. The interview was recorded with my micro-recorder podcast unit.

What I've done is break up the interview recording into snippets, or micro-podcasts, wrapped in blog narrative with my lead in and comments for each portions of the interview. The idea is just to listen to the parts of the recording you want to hear, rather than listen through the entire recording just to get to the topic you're interested in. And, if you wish to hear the full, unedited interview recording, just go to the bottom of the blog post and listen to the full interview instead of the broken up segments.

If you have a moment to check it out, please do so and let me know your feedback about this idea. Do you like it? Is it easier to read and listen to? Does that format work for you? What suggestions do you have for improving it?

Let me know your thoughts. Thanks.

VC panel about funding SaaS companies in today's market

While attending the 2008 SaaS Summit last week, I was fortunate to listen in on a panel discussing venture funding of SaaS companies in today's market. The panel had a mix of early stage, mid and corporate, corporate investors and a view from the public markets perspective.

Panel: Ann Winblad, Partner - Hummer Winblad Venture Partners, Jason Maynard, Research Analyst - Credit Suisse First Boston, Jason Green, General Partner - Emergence Capital Partners, and Jon Krause, Investment Manager, Intel Capital. Moderator: Treb Ryan, CEO, Opsource.

Several things stuck with me from the panel discussion. First is the divergence of business funding models that have been funded in the current and past years. SaaS isn't just about funding investments of $50m, $75m or $100m in capital mega startup or roll up companies. Several companies were mentioned who bootstrapped, acquired a bevy of good customers, and then seek capital to increase growth. These aren't the days of "build it and they will come". SaaS and On Demand software enables companies to get products to market with fewer barriers, benefit from customer and market feedback, to more quickly prove out their business model, or at least spend less money doing so.

Another common theme was the patience that investors must have these days. Few startups are going to go from series A to a buyout or IPO in 3 years or so. Most take much longer for a liquidity event. Venture cycles are running 6.7 for a company IPO, and 5 years for a company is acquired, according to Ann Winbald, of Hummer Winblad. Though the VCs know this, most entrepreneurs are still learning that these timeframes are typical, not the quick pops during the '90s bubble.

A few other themes resonated with me. The importance of partners, and extending your reach through those partners, sales organization, branding and technology. My experience is that product managers, CTOs and product developers often overlook opportunities for rebranding and OEM products early in their development. I know I've been guilty of that lesson myself, and it's something I put a lot more emphasis on in the companies I work with today.

The other was the investment in the front end of the business that is necessary, sales and marketing. Some of the panel members felt it should be a 1:1 ratio, $1 of sales and market for every $1 of the most recent quarter of revenue. That's sounds like the spend of one of those capital intensive mega companies and seems pretty heavy to me, but I do believe you've got invest significant dollars in the front end. Products rarely market or sell themselves, and when they do, no one knew it would happen up front -- I'm saying they are lucking more often than smart. So don't put too much faith in luck and invest in the business.

Is your product aspirin or vitamins (metaphorically)? That's one prescription for telling how important your product or service is to the customer. How sticky is what you provide your customers and could they walk away during a downturn of the economy. That was some other sage advice from Ann, who talked about how they evaluate the customer portfolio of companies they consider for investment.

Note: I'm requesting permission to post the mp3 recording of the panel discussion. Stay tuned.

 

TechStars: 29 Days Left To Apply

I've made it a personal goal to be more involved in the entrepreneurial community instead of my usual "singular focus" when doing start up companies. One of the reasons is to give back and help others as they develop their ideas and businesses. It's a part of my thoughts about flourish and how to help make that happen.

I'm happy to announce that Brad Feld and David Cohen have asked me to be a mentor for the TechStars program. What a great way to get an idea developed and possibly funded. And, it's a great way I can help others in the process.

If you still have a business idea but haven't applied, I would encourage you to do so. There are only 29 days left to submit your application. Maybe submitting your business plan or idea to TechStars is that calling you need to put your idea into action. Plus, you can't get selected if you don't apply, so here's your chance.

I hope you'll consider becoming part of the program. Yours could be the one that gets selected!