If you missed the webinar on Monday, you can listen to it here: http://bit.ly/c7FlM8
A special thanks to Matthew of EditMe for having me on to talk about starting a business.
Cheers!
If you missed the webinar on Monday, you can listen to it here: http://bit.ly/c7FlM8
A special thanks to Matthew of EditMe for having me on to talk about starting a business.
Cheers!
If you’re not familiar with the term “Micropreneur”, you’ll likely hear a bit more about it in the coming months. To give you a really short description, a Micropreneur is basically the owner/founder of a Micro-ISV. Ah yes, another acronym to explain. A Micro-ISV is a small, independent software vendor. That’s basically a term that Microsoft came up with for any software company that isn’t Microsoft.
Next Monday at noon ET, I’m giving a free webinar with Matthew Mamet of EditMe on how to make the leap to being a Micropreneur. Here is the registration link itself, and here’s a link to the description of the webinar. Initially, the webinar will be a simple Q&A with Matt, but after we cover the following topics, we’ll open up the floor to questions.
Hope to see you there.
It’s a few hours late, but here’s my final notice on this blog for a new episode of the “Startups for the Rest of Us” podcast.
Episode 3: The Biggest Roadblocks to Your Success
Unless we do something really cool there, you’re not going to hear about it again. As a side note, I fully intend to keep blogging, so stay tuned. I have articles coming out of my ears right now and it’s not a pretty sight.
A colleague referred to me as Mariano Rivera this week. If you’re not a baseball buff, Mariano Rivera is the closer for the New York Yankees. Like most closers in baseball, Rivera usually comes into the game when it’s almost over and the Yankees are winning by only a couple of runs. It’s his job to make sure the other team doesn’t score so the team holds on and wins the game. If he does it, he gets a “Save” in his statistics. If he doesn’t, he usually ends up with a loss. He’s widely regarded as one of the best closers in baseball.
As I thought about this comparison, I realized that while flattering, it wasn’t remotely true. The people I work with don’t send me in to close a deal. I’m not there to “seal the deal” because I’m not that kind of person.
I’m the guy they call when all hell has broken loose. I’m the guy they call when someone screwed up, someone else got pissed, and tens of thousands of dollars of products, services, and future productivity are on the line. I’m the firefighter.
This week, I felt the urge to change my business card to Winston Wolfe or at least put a quote from him on there. If you remember the movie Pulp Fiction, he’s the guy who shows up to clean up the body after John Travolta’s character accidentally shoots “Marvin” in the face. When he arrives he says:
“I’m Winston Wolfe. I solve problems.”
In a nutshell, that’s generally what I do. I solve problems. And when I’m sent in to rescue a dying project, I look like an All-Star for a couple of reasons.
1) I know how to manage a project and set expectations
2) I have a deep and diverse set of skills
3) The customer expectations are based on the guy who went in before me.
How many of these projects fail?
A study by Gartner suggested that as many as 75% of IT projects fail and an informal poll by CNet in 2008 suggested that 62% of IT projects fail. Neither specifically calls out consulting projects, but personal experience from cleaning up some of these messes seems to indicate that it’s at least 20%. In the past 30 days, I’ve saved two different projects from completely falling apart after the customer lost confidence in both the consultant and in the vendor.
There are varying degrees of failure, but when the customer asks for a consultant to be replaced before the project is over, that’s a pretty good sign that they failed. I came in after one consultant who claimed to know how to use a software package that he had merely installed and used once or twice. When he started working on the project, the customer asked a bunch of questions he didn’t know the answers to, so the consultant went to the product documentation. After four days of reading the documentation, he’d found the answers. But by that time, the customer lost all faith in his ability to deliver and threw the company out. I delivered on the next several weeks of services and heard the story mid-way through the project. I’d be pretty irritated too if I paid $12,000 for a consultant to read documentation for a week. I knew what the customer was thinking and he didn’t hesitate to offer it up. “Hell, I could have read the documentation myself.”
Yes, you read that right. The customer paid $12,000 for a week of consulting services. Some consulting companies charge exorbitant rates is because they guarantee their work. If a project fails, they’ll throw another consultant on it for no charge. Usually they come out a little ahead or a lot ahead.
The problem for the customer is that they waste valuable employee time with the consultant doing things that end up being thrown out anyway. Failed projects cost them even more money. So how do you go about making sure that a project succeeds?
The obvious answer is to use great consultants in the first place. But finding a great consultant is a lot like hiring great employees. The difference is that you have less data and interaction with the consultant to make a decision. More interaction isn’t necessarily going to help because a consultant is generally taken at his word that he knows what he’s doing. It’s simply not cost effective to give a battery of proficiency tests to a consultant who is only going to be there to do a short term project.
When you hire a consulting company to come in and do work for you, you’re relying on the professional services manager to provide you with someone who knows what he is doing. You can stress how important that is, but at the end of the day, the company you hire is going to give you whomever happens to be free at the time unless there’s a very specific skill set needed for the job that nobody else has.
Basically that means it’s a total crap shoot. You can easily get stuck with a consultant who just doesn’t know what he’s doing. Guess what though?
It’s almost never his fault!
I generally feel bad for these guys, because if you hire a company to come in and deliver consulting services and end up with a consultant who really shouldn’t be there, it’s not his fault. It’s his boss’ fault for putting him there. Consultants don’t get to choose what projects they work on. They go where they’re told. And if that means they are put on a project they have no business working on, then so be it. But he didn’t choose to be there. Someone else did. His choice was “Give it a try, or find a new job.” If it works out, then great. He’s got some new skills they can peddle to the next customer. If not, there’s usually enough profit margin built in for the vendor to replace him with someone else who is more qualified and still at least break even. In either case, it reflects poorly on the consultant, even though it’s not his fault.
What’s the formula for being a great consultant?
If you think that a great consultant is someone who knows their products cold, then you’d be wrong. A great consultant is many things, but mostly is someone who is a good teacher. Customers don’t want to have to hire you every time they need something. They want you to come in and teach them to be self sufficient. If you can’t do that, then you’ve failed to do your job. I worked with a guy about 10 years ago who was a brilliant programmer. He could write C code in his sleep and was very good at it. But his abilities, much like the dark side of the Force, made him arrogant. As if he could do no wrong. His code was poorly documented and difficult to read. The few bugs that were in his code were notoriously difficult to find because of his programming style. Eventually, management fired him because he wasn’t willing to be a team player.
A great consultant has to straddle the line between being that kind of Lone Wolf who can accomplish a set of tasks without any supervision, but at the same time, fit well into a team. As a consultant you’re working with the customers employees and need to teach them the things they need to know to be successful. At the same time, you have to be something of a good project manager. If you’ve only got a week to finish a project, then wasting 3 days chasing down a “nice to have” isn’t going to help you finish the project on time, let alone give you time to do any sort of knowledge transfer with the customer employees.
Finally, dial up your Humility Meter a bit. So you’re a consultant. You’ve worked on multi-million dollar software deals. You’ve installed software on tens of thousands of computers in a globally distributed environment. Your customers are all over the Fortune 100 list. Big fat hairy deal.
Customers might be a little impressed by that, but at the end of the day they just don’t care. They want to know that you’re going to do the job in a professional and competent manner. If you do a competent job, they’ll want your company to come back. If you do an outstanding job, they’ll want you back and won’t take anyone else. Which is great for you as a consultant, but bad for the consulting company you work for. This puts their consultant in high demand, rather than the company’s services. Don’t get me wrong, it’s great for repeat business, but if a consultant is good at what he does, most of his customers don’t want to take a chance on another consultant who might have a different style or a lower level set of skills.
How do I become a great consultant?
Like being successful, there’s no one secret to success. A great consultant is a combination of a lot of different things. Usually, you have to branch out a bit to be more successful. I’ve seen both ends of the spectrum and there’s a world of difference between a great consultant and a mediocre one, let alone a bad one. If you want to go from mediocre to great, here’s what you need to do.
1) Learn to be a great presenter
This isn’t just about public speaking, although that’s definitely a big part of it. I’ll give a follow-up blog post in the next couple of weeks to address this specifically because it’s a pretty big topic. Suffice to say that building a good presentation is key, as is being a good public speaker. If you have an opportunity to take a course on how to be an effective instructor, then do it. It will help you. Courses that teach how to be an effective instructor are generally technology or product agnostic. They teach you how to hone your delivery.
2) Become well versed in a lot of different technologies
It’s fine to be a Windows or Unix guru. It’s great if you can build PL/SQL queries in your sleep. But if you can’t relate your skills to problems across multiple technologies and business processes, this is going to hold you back. The ability to at least be aware of the pros and cons of various technologies allows you to relate those technologies to one another to solve larger business problems. It also gives you an effective position from which to offer suggestions on how to approach problems differently. It also helps to provide insight into how things work (or how they should work) when you run into technical difficulties. I’ve been able to pinpoint bugs in a product by knowing how the technology itself is supposed to work, without ever having looked at the code.
This is why developers who turn into IT consultants are so good. They tend to have an innate sense of how things would have been put together that they can troubleshoot things that they think are wrong. It’s like a sixth… or even a seventh sense. A good consultant doesn’t always know why he does the things he does.
3) Be professional
This sounds easier than it is and there are more things that you shouldn’t do than anything else. Don’t badmouth your product, your competitor, your competitors’ product, your boss, your ex-girlfriend, your employer, your ex-employer, the guy who was there before, etc. Airing your personal dirty laundry is simply not appropriate when you’re at a customer. It’s ok to tell stories of when someone did X, which was really stupid. But make sure that you do two things. First, don’t say names. The customer doesn’t need to know who the idiot was. Second, make sure the story serves a purpose.
For example, one of the best practices that I tell people when using a specific product is to always drag the computer onto the job, rather than the job onto the computer. It technically works both ways, but in the list of computers is a node called “All Computers”. If the mouse skips, or there’s a UI glitch in a remote desktop session, it would be very easy to accidentally install a new OS on every computer in the company. The story I tell is of someone who actually did that. It illustrates a point which is the potential consequences of doing it against best practices even though it works. And it illustrates that point without being demeaning.
Don’t brag either. Nobody likes the guy who brags about all of his past successes or the massively complex things he’s done in the past. On the other hand, you have to bring up some things you’ve done in the past to help make the customer comfortable that you’ve done this before. Using past experiences is a great example and an effective way to do this. You get to stroke your own ego a bit by telling a short story of a successful project you’ve done in the past, and at the same time answer their question.
“Mike, how do other companies do this.” “Well, there was another health care company I worked with that had a similar problem. Here’s what we did and it took us this long to do it. I know you’re a much smaller company than them, but it still takes about that much time to get it done. The issue isn’t the number of machines. It’s the setup time for all of the potential configurations. And the thing to keep in mind is that you’re using this technology instead of that one. So it’s a bit different, but the basic process is still the same. Here’s what I think you should do…” As you can see, part of this goes back to #2.
Finally, don’t look like a scumbag. Iron your shirt and pants. If your pants are worn out and threads are coming loose, throw them away and buy new ones. Customers are paying for a professional. The least you could do is look the part. Coming into work wearing jeans and sneakers isn’t going to endear you to the customer, although you can get away with it if there are extenuating circumstances.
I had a customer in Indianapolis who wanted me to deliver training to a class of 12 people for 3 days. I flew out on Sunday night, arriving there shortly before midnight. Unfortunately, the airline lost my luggage with all of my dress clothes. All I had to wear to the training facility the next day was the jeans and t-shirt I’d worn the previous day. The class started at 8:30am and since most stores weren’t open until 9am, it wasn’t as if I could go buy new ones. So I showed up in jeans and a blue t-shirt. I’d spent some time thinking about how to explain it, as I’d never met some of these people before.
I got a lot of funny looks as they walked in the door, but I started the class promptly at 8:30am with no nonsense. I told them that I was wearing blue because I was still upset that my Patriots had lost to the Indianapolis Colts several weeks before and that the reason I was wearing jeans and a t-shirt had absolutely nothing to do with the airline losing my luggage. They laughed at the terrible joke because all of them could relate to the situation. My professional, instructor-like demeanor carried me through noon when I was able to get back to the hotel where my luggage had thankfully arrived. Feedback at the end of the sessions included comments about how some of them were initially skeptical based on how I was dressed, but that I had handled the situation very professionally and they were very pleased with the course.
The way you look and present yourself in business as a first impression is very important and it can go a long way. But if you act like a douche-bag or don’t know what you’re talking about, your value as a qualified professional decreases dramatically and in very short order.
4) Shut up and listen
Customers and people in general like to talk. They want to tell you what’s going on and if you let them, they’re not going to be shy about telling you more than they probably should. You need to let them talk. I’ve been told of goings on which are considered illegal by simply keeping quiet. If you have ideas of how to solve their problems, ask if they’ve considered them. Don’t tell them what they should do before you find out if it’s something they considered. Otherwise, they will tell you why they already tried or considered that option and knew that wouldn’t work in their environment. Eventually they stop listening because you haven’t actually contributed anything.
The point of the first day at any customer is not to solve their problem. It’s to get the lay of the land and figure out what needs to be done. If the first thing you do is jump right into the middle of things without taking the time to find out the background story and what’s really important to the customer, you’re simply setting yourself up for failure.
Listen first. Ask questions. And don’t offer suggestions unless directly asked what to do. Even if that happens, talk about a few different options and then ask more questions. Trust me, you’ll seem smarter and sounds like you know exactly what you’re doing, even if you don’t. Making decisions without all of the information simply leads to poor decisions. Let the customer tell you everything. In fact, ask them to. Then filter out what isn’t important. Don’t let the customer tell you what’s important and what isn’t. You need to make that decision. By all means they should decide what is important to them in terms of goals and accomplishments because that will help guide how your solution is implemented. But you need to decide what information is relevant to the success of the project. That’s part of why you’re there.
5) Manage the project and your time well
Arrive on time, especially the first day. Most customers tend to be a bit lax about the exact hours when they’re paying for X weeks of assistance. So long as you get the job done, they don’t care about the hours you spend unless they are far lower than the amount they paid for. Unless you make some major mistakes, there should not be an expectation placed on you to work late unless that was a commitment made as part of the project. I’ve had customers start at 7am every day. Others have said that 10am is fine. The customer generally dictates the hours. It’s up to you to make sure that the project gets done during that time frame.
As the project progresses, your role should change from that of an information gatherer to that of a project lead. You need to drive the engagement, as opposed to letting the customer tell you what should be done. The presumption is that you’ve been a consultant for a while and have done a job like this before. You know the process and what should be done next. The customer doesn’t. Show them why they hired you. Unless you’re truly at a standstill and there’s nothing else you could be doing, then you should be working and moving towards your goal.
I’m not a consultant. Why should I care about how to be a great consultant?
The skills that make a great consultant translate very well into being a great employee. These skills translate into being a solid and well rounded business owner. If that’s not something you’re interested in, then there’s somewhere else they come in handy. These are the same skills you need to be a great manager and I’m sure we can all agree that the world needs better managers.
These skills really aren’t for making a great consultant. They will help turn you into a trained and polished professional. Being a polished technical professional will translate very well into any career path you choose. I’ve never heard of anyone who was called “too professional” for a job in the technology industry.
The second episode of our free podcast named “Startups for the Rest of Us” that Rob Walling and I created is live at our podcast website. This episode is titled “Stupid Reasons to Start a Software Company”. You can either listen to it in your browser or download the MP3 and a full written transcript of the episode has been made available. In an attempt to keep the noise on this blog to a minimum, I will only be announcing one more episode here. After that, it will be up to you to keep track of the new episodes, which will come out every Tuesday for the foreseeable future. So tune in and subscribe using any of the links below.
Subscribe Now:
In other news, look for another blog post later this week. Enjoy!
In 2006, I had been self-employed for less than a year. I knew a decent amount about business and a whole lot about technology, but wasn’t quite sure what I wanted to do. I had been involved in a startup called “Pedestal Software” for the previous few years and it was sold to Altiris to the tune of $75 million in March of 2005. I thought it was something that I wanted to be part of again, but having spoken with other founders who’d received angel and venture capital investment, the politics of it all made me queasy. I wanted to build software. Not cater to people who’d never actually done it before.
Then along came game Paul Graham, a former software founder who was offering people a chance at building their own startup via Y Combinator. Initially, it seemed like a great deal for an entrepreneurial founder but as I read the fine print, I realized that Y Combinator was not designed for someone like me in mind. It spawned a blog post called “Startups for the Rest of Us” that has since gone viral twice.
My biggest problem with Y Combinator wasn’t so much that you had to move, give up part of your company, or that you had to be selected. It was the fact that they were offering a paltry $2,000/month for three months to build a product and for that “privilege”, they would charge you 6% of your company.
Seriously?
Umm… This is Massachusetts. My mortgage alone is more than that. And their expectation would be that I would move to Cambridge, rent a house, and build something reasonably good in 3 months that people would be willing to pay for. In addition to paying my mortgage of course. Again, I don’t have a problem with the timetable, but the money is a deal breaker. For someone like me who is married with kids, a mortgage and the sole breadwinner for the family couldn’t possibly make ends meet for three months to do that. My only hope would be to use personal savings to help bridge the gap and if I’m taking that kind of risk, why should I bother giving up part of my company to do it? Feel free to read what I wrote back then, as I’m not going to rehash it here.
A tiny bit more background…
About 9 months ago, I reconnected with Rob Walling, who runs a blog called Software by Rob. Together, the two of us have been building a community of developers as part of the Micropreneur Academy to help people who want to be self employed but don’t know where to start. We came to the realization that we wanted to take things a step further. We wanted to provide even more information to developers who were interested in building and launching their own products. Not everyone who comes to our site is going to join the community, but that’s no reason to deny them valuable information to help them on their way.
The Actual Announcement
So today, it is with great fanfare and gusto that Rob and I are launching our new podcast, named “Startups for the Rest of Us“. If you’re looking for practical advice from experienced entrepreneurs who have been in your shoes, then our podcast is the place to get it.
The Details
We will release a new episode every Tuesday. The first episode is live at the podcast website and you can listen to it in your browser or download the MP3. We’re also providing full written transcripts of each episode in the show notes.
Episodes will be concise and run 20-30 minutes so you can listen to them during a jog, a short commute or part of a lunch hour.
We think that this is something you’ll want to check out. We’ve never done a podcast before and the first couple of episodes are a little bit rough, but we get better at it pretty quickly. Tune in and subscribe using any of the links below. Enjoy!
Subscribe Now:
About 6 weeks ago, I had dinner at a pizza place near Boston with some fellow developers. We were generally discussing various aspects of business, things to do, things not to do, etc. One of the guys asked me a question that I feel like I get quite frequently:
“What’s the most important thing you need to do to be successful as a single founder?”
I immediately came up with three different things, but settled on explaining the importance of setting goals and having a plan for meeting those goals. We talked about how to go about setting goals for a few minutes and then went on to discuss other things.
This isn’t a new question to me, but I was uncomfortable with the answer. I seem to answer it differently every time I’m asked and not usually the same way twice. This past Friday, as I sat white-knuckled in a small turbo-prop plane that was being buffeted violently by winds over the mountains of West Virginia, it dawned on me why I had been uncomfortable with my answer.
I was wrong.
I published a popular article named “The Single Founder Myth” a few years back. In this article, I contended that contrary to popular opinion, it was not impossible to go it alone with a software startup and be successful. To clarify up front, what I mean by “going it alone” is that you build up the company without handing over equity to someone else, be it either investors or other co-founders.
In this article, I gave several reasons why companies have multiple founders and countered the necessity of each for a single founder company. I came to a sudden realization the other day why most technology companies have two founders.
It’s because one of them is a builder, and the other is a salesman.
Fellow blogger Rob Walling and I were featured on the .NET Rocks podcast yesterday. You can check out the interview here. We’ve been featured on a few other podcasts for the Micropreneur Academy that we put together last year. When I get a chance, I’ll post the links to those podcast interviews.
Several weeks ago, someone pointed me to an article on a blog I’d never read before. It was very profound it its simplicity. It was called Smart People should do Stupid Stuff. The basic concept of this blog post was that there are millions of dollars to be made doing things on the internet that anyone is capable of doing. I mean quite literally, anyone can do these things, regardless of how smart or how dumb you are. Here’s a very short excerpt, because I know you’re not going to go actually read the entire article.