Find (or found) a consulting support group

I work on my own most of the time, out of my house. This means that I have regular email and phone contact with other people, typically clients, but only occasional face to face time. This style of work suits me, though I have friends who say it drives them batty. I enjoy the short commute and the freedom to order my day as I see fit (as long as I deliver).

However, sometimes it’s nice to have contact with people who aren’t paying you money. Users groups (such as BJUG) and meetups (such as the New Tech Meetup) can be informative and through provoking, but the presentation focus makes it hard for me to connect with other people. What I’ve found works best is a small regular lunch group with other consultants.

At lunch, you can discuss business problems, sometimes related to people who aren’t paying you money, but should be. You can get referrals for professional services that you may need–accountants, lawyers, etc. The group can be a source of business for you, as well as a place you can find someone to refer clients to for projects beyond your expertise. I always find it interesting to hear what other people are doing: one of my favorite lunchtime activities is the ‘new project go around’, where everyone talks about what new project he or she is working on.

In short, gathering on a regular basis with a set of consultants who you know and trust can be very useful. I have found once a month works just right for me–we always have plenty to talk about. We have also met semi monthly, and that was alright too–a bit harder on the schedule. A group of 4-8 people is about the right size–less and you don’t get as much cross pollination, more and you start to lose track of people. If you can, try to have people from different parts of the technology world in the lunch. The group I belong to has development managers, UI folks, project managers, developers and designers. This means that if I have a problem to discuss, I can get a lot of different viewpoints.

How do you start such a consulting support group? I think the best way to do it is to pick a restaurant and time, and invite 10 colleagues that would find this type of networking both useful and geographically convenient. At the restaurant the first time, see if people are interested. If so, set up an email list, and pick future dates. Don’t try to pick a time to meet that always works for everyone–part of the reason to invite 10 or so people to start the group is so you have enough people for a good conversation when someone inevitably can’t make it.

My group wrote up some bylaws–the most important of which was that no clients would be invited, except with prior notice to the email list. The reason for that was to allow the sometimes frank discussion of issues. Other than that, just set up a recurring event in your calendars and ping the email list when the lunch is near. And let the discussion commence!

Is the tech contractor to salaried employee ratio a sign of the tech business cycle?

Nat Torkington seems to think so: “…when the clever contractors head for salaried positions then bad times are coming.” (The last paragraph is cut off due to an HTML error, but basically asks if a shortage of engineering talent affects this indicator in one way or another.)

It is a complicated problem because there are a lot of other factors influencing whether being a contractor or an employee is a better fit for a person’s situation: need for income stability, contacts in the industry, demand for a given skill set, even preference for new situations. Even so, it’d be interesting to look back and see what the ratio was over the last, say, 20 years.

I took a look at the BLS web site, but couldn’t find any reports delineating contract employees and salaried employees.
Via Infectious Greed.

Technorati Tags: ,

Business Process Crystallization

I’m in the process of helping a small business migrate an application that they use from Paradox back end to a PostgreSQL back end. The front end will remain written in Paradox. (There are a number of reasons for this–they’d like to have a more robust database, capable of handling more users. Also, Paradox is on the way out. A google search doesn’t turn up any pages from in the top 10. Ominous?)

I wrote this application a few years ago. Suffice it to say that I’ve learned a lot since then, and wish I could rectify a few mistakes. But that’s another post. What I’d really like to talk about now is how computer programs crystallize business processes.

Business processes are ‘how things get done.’ For instance, I write software and sell it. If I have a program to write, I specify the requirements, get the client to sign off on them (perhaps with some negotiation), design the program, code the program, test it, deploy it, make changes that the client wants, and maintain it. This is a business process, but it’s pretty fluid. If I need to get additional requirements specification after design, I can do that. Most business processes are fluid, with a few constraints. These constraints can be positive: I need to get client sign off (otherwise I won’t get paid). Or they can be negative: I can’t program .NET because I don’t have Visual Studio.NET, or I can’t program .NET because I don’t want to learn it.

Computerizing tasks can make processes much, much easier. Learning how to mail merge can save time when invoicing, or sending out those ever impressive holiday gift cards. But everything has its cost, and computerizing processes is no different. Processes become harder to change after a program has been written or installed to ‘help’ with them. For small businesses, such process engineering is doubly calcifying, because few folks have time to think about how to make things better (they’re running just as fast as they can to stay in place) and also because computer expertise is at a premium. (Realizing this is a fact and that folks will take a less technically excellent solution if it’s maintainable by normal people is what has helped MicroSoft make so much money. The good is the enemy of the best and if you can have a pretty good solution for one quarter of the price of a perfect solution, most folks will choose the first.)

So, what happens? People, being more flexible than computers, adjust themselves to the process, which, in a matter of months or years, may become obsolete. It may not do what they need it to do, or it may require them to do extra labor. However, because it is a known constraint and it isn’t worth the investment to change, it remains. I’ve seen cruft in computer programs (which one friend of mine once declared was nothing but condensed business knowledge), but I’m also starting to realize that cruft exists in businesses too. Of course, sweeping away business process cruft assumes the same risks as getting rid of code cruft. There are costs to getting rid of the unneeded processes, and the cost of finding the problems, fixing them, documenting them, and training employees on the new ones, may exceed the cost of just putting up with them.

“A computer lets you make more mistakes faster than any invention in human history – with the possible exceptions of handguns and tequila.” -Mitch Ratcliffe, Technology Review, April 1992

A computer, for the virtue of being able to instantaneously recall and process vast amounts of data, also crystallizes business processes, making it harder to change them. In additional to letting you make mistakes quickly, it also forces you to let mistakes stand uncorrected.

© Moore Consulting, 2003-2017 +