Friday, August 22, 2008

Expertise and Competition

Companies are better served by having a few really good people on a project vs. a large number of ineffective ones. This begs a couple of questions:
  • Do you potential clients believe that it is better to pay for quality than quantity?
  • Who is your competition, and are you better than they are?

The Competition


Let's start with the second question: when you are an independent consultant, who is your competition? As a rule, it is not other independent consultants. According to this bureau of labor statistics report, only about 4% of programmers are self-employed. According to this one, only about 6% of systems analysts are self-employed while, this report indicates that only about 2% of "Computer Software Engineers" are self-employed.

There is a lot of overlap between each of these groups, but the bulk of the "tech lead" work will fall into the systems analyst and software engineer groups. That is what I'm mainly seeking, and I assume that you are as well if you're reading this.

So who is the competition? My own experience tells me that when the time comes to staff a project, 90% of the candidates I have seen fit two or more of the following:
  • Little or no "initiative" - only do work when given very specific tasks.
  • Little or no talent for creating software.
  • Non-native speakers of US English with poor communication skills (mainly from India since that's the bulk of the talent pool right now, but many US-born programmers have this problem even without a language barrier).
  • Limited understanding business in general and the purpose of business software in particular.
  • Very little experience with 'real' programming work (as opposed to school projects).
To sum up: if you communicate well and are motivated, you're head-and-shoulders above your competition. (For more on this topic, here is a blog entry with some pretty good quotes on what it takes to be a "good" programmer.)


Your Potential Customers

This is where the rubber really meets the road. I think that most software developers understand on some level what it means to be good or bad in this space. I think that most business people do not know this, but believe that "programmers" are mainly interchangeable.

This state of affairs is changing slowly, and there are a number of voices out there (like this one) that seem to get it.

To find the work you want to do and make a good living at it, you really need to do two things:
  1. Sell your clients on the idea that they get a lot more benefit from a few good people (like you!) than from a large group of mediocre ones.
  2. Build your expertise to the point where you're obviously one of the best.

Both of these will be the subjects of future posts. I would really like to hear your opinions in the meantime!

Tuesday, August 12, 2008

The Beginning

Detroit. A city filled with good restaurants, violent crime, and felonious politicians. The city I grew up in and that I still live near.

This is not a blog about Detroit.

It's a blog about something far, far more important. Me.

More specifically, it's about my journey from employee to independent. It's about returning to my roots as an ΓΌber-nerd software developer. It's also about Java's place in the world, and the independent consulting market in Detroit and Ann Arbor. I don't think I'll run out of topics any time soon.

I resigned my job as Program Manager in a struggling software company last week. There were a lot of reasons behind that, but the most important one was that I couldn't stand my job.

I didn't hate the people. I didn't hate my boss. I hated the actual work I was doing from day to day.

I'm getting ahead of myself, though. Before I tell you where I'm going to, let me tell you a little bit about where I'm coming from.


The Salad Days
Very early in my career, I worked as a contract software developer. I was directly employed by a couple of different shops until I met a fellow developer at a software company in Ann Arbor who also yearned to go into business for himself. Starting in 1994 we set up shop under the inspired name of "Damon, Przekop & Associates, LLC".

Those were heady days. Anyone with the ability to register a domain name could put up a website and bill themselves as a solution provider. A few really sharp people did so, as did a large number of clueless ones. It was a time when work just fell into our laps, and customers were grateful when we managed to deliver a working system, regardless of the quality.

We took whatever came our way. Need a client-server database app? "Sure, we can do that. Erik knows Visual Basic and Dave can handle the SQL work." Need some realtime work done? 'We know C++, and we can learn realtime in a hurry. " Want to piss away a couple of million on an voice-recognition-based CRM that will never see the light of day? "Java is the platform you want! (I guess we had better learn how to code in it.)"

Companies got wise after the bubble burst in 2001. They wanted their contractors to have some idea about how to ensure software quality. They wanted us to write systems that actually did what they needed. The approach of ignoring the customer's needs in favor of working with the flavor-of-the-month technology was no longer acceptable.

Our skillsets simply weren't up to that challenge. We both had a really good grasp of the basics of writing code, and we could do it in 10 different programming languages. The problem was that neither of us had true expertise on a specific development or delivery platform. We hadn't specialized, and we didn't know jack about QA, requirements or agile development.

A couple of companies came to the rescue. Dave was hired by a software company in Monroe, and I moved to a data company in Southfield. Both of us were tired of the grind and were ecstatic that someone actually recruited us away from what we perceived as a failed way of doing business.

I became an employee again, and learned quite a lot in two years as a technical lead. I specialized in Java development, with a focus on the process of software development. I learned how to get a team to deliver on time, how to gather requirements, and (after having my head handed to me a couple of times) how to see testing as my friend instead of as a pointless waste of time.

Then, something very bad happened.


Drawn to the Dark Side
That's right, I did such a good job as a tech lead/architect that my bosses foolishly thought I would make a great manager. It turned out that they were at least partially right - I did a pretty good job of managing software & support people, and I turned into a process-Nazi in a big hurry, which was just what the organization needed. I was rewarded financially and became the go-to guy for evaluating the capabilities of smaller companies we might want to buy. It was challenging, and usually fun.

Things went downhill after a couple of years though. My success was rewarded by giving me a job doing pure infrastructure management because that's where they needed the most help. For those who do that job well, hats off to you. I was mediocre at it at best, but I stuck it out for most of a year.

When the time came for cutbacks, my name was one of those that came up. I found myself on the street (with a severance package that took some of the sting away), wondering what to do next. On pure inertia, I put my name out there as an "IT Manager", which brings me back to my current job.

Jokes aside, I learned quite a bit as a manager that I wouldn't have otherwise understood. You simply can't get this stuff from books. How seemingly non-technical" people can add a lot more value than some of the rocket scientists. Why it's important to pay attention to office politics if you want to get anything done. How to plan for success, but still guard against failure. How to build and balance a team.

I also learned how much I hated doing it.

I really have nothing against management as a profession. Quite the opposite. I will now appreciate a good manager much more than I did before, and the management skills that I gained should serve me well in a technical job.

I did find that most management jobs (particularly infrastructure) require a very thick skin. Mine may not be quite thick enough, but I think the real problem for me is that it isn't what I "should" be doing. I just don't have any passion for it.


The Lightbulb Goes Off
I've been kicking this idea around for a year. While doing infrastructure work, while hunting for another job, and a lot while handling my latest job, I asked myself, "Why not go back to consulting?"

What held me back was the perception that I had failed at it before. I just didn't have enough customers, or enough expertise... or something. So I took a long look at what I did back in the 90's, and what it would take to make it work now. I came up with some answers.

That brings me back to what this blog is really all about: How to build and sustain a consulting practice based on my own expertise. How to build that expertise, find the right projects and clients, and sustain a small business for the long haul. My initial thoughts on what I did wrong then, and what I will do right going forward, will be the subject of another post.

If anyone who reads this is in the same boat, I would really like to hear your thoughts and opinions. If anyone has built a one-man (or one-woman) business out of writing code and/or architecting software systems, I'd really like to hear your thoughts.

I don't expect much feedback right away (though I'm prepared to be pleasantly surprised - I didn't come across anything else that really focused on this topic). I will add some useful links and observations from my own experience in future posts. I will also post snippets from projects I have worked on over the years, the steps I took to get things on track, and mistakes made that I learned from.

I look forward to hearing from you.