Lex Parsimonae

It's been a while since I've been a new employee, and I think it's good for me to get another turn on this side of the hiring process. I always made a big point with all my new employees to tell them, "you're only new here once, so tell us where we're screwing up." So, here I am, experiencing some screw-ups. As always, I think this can be a learning opportunity, so I'm going to share some notes with you -- are you doing any of these things?
Starting a new employee is a critical time. Not only are you forming vital first impressions, you're probably more at-risk with your new employees than at amost any other time in their career with your company. Think about it -- if they're just coming off of a job search, they've probably got a whole database of contacts spun up, and their cell phones are still on speed-dial with a bunch of recruiters. If they're not happy in the first couple weeks of their employment with you, there's every reason to believe you'll lose them.

Here are some things I've seen in my first weeks of employment that could really stand to be improved. For the record, I intend to approach these as areas where I can help raise the bar here rather than reasons to get disgruntled. I guess I'm just a "glass half full" kind of guy. 😉

• Ok, I lied. I'm going to start with something that went exceptionally well. The HR portion of orientation was well-run, professional, and friendly. This is the mark of an organization that sees "service" as an important part of their business, and it's a clue to you as a manager -- there are organizations that are optimized to create things (including processes) and organizations that are optimized to work processes. Knowing which one is which: priceless.
• First day: new machine. There's something to be said for having a machine ready for you on your first day, especially for a developer-type who molds his PC to fit him like a race car driver tailors his seat. I started and was given a temporary laptop(for the first half-day or so), then a temporary desktop, and finally my laptop a week or so after I started. In the mean time, I avoided setting anything up the way I really wanted it, because I knew I'd be giving up the PC soon. Obviously, I was less productive and less comfortable in my new home as a result.
• Where are the docs? Every company and department has a collection of docs, as well as a collective archive of "tribal knowledge". In my experience, organizations that know that they're lacking in documentation are a little better at sucking up the hit to assign someone to sit and explain why things are the way they are. In this case, there's a SharePoint site and a SourceSafe archive, so the natural tendancy is to just assume that everything's in there and easy to find. Only one problem: both are incomplete and not updated nearly often enough. There's just enough available in both places to convince me that nothing here could possibly be made to work.
• Who's in charge of what? It's natural for a new employee to have questions about what's going on, why things are the way they are, and who can help explain things. It's really frustrating to get the runaround when you ask questions about this stuff. I've been asked to put together some best practices for builds on Visual Studio Team System (VSTS). Cool. I can do that. Three days later, I'm still trying to get set up, because I keep getting bounced around trying to find out who can get me access to the stuff I need to do my job. Sigh. Same thing goes for project work - "can you help with XYZ?" "Sure," I say. "Who do I see with questions?" "...uhh..."
• Everyone's busy. This is a killer, because you obviously wouldn't hire someone if you weren't busy. Despite that, you've got to make sure it's someone's job to maintain some continuiity with the new guy, cause it bites to be hanging out in the breeze while everyone else is running around frantically doing what they need to do. The tough truth is that you need to expect to invest some time from your busiest team members in order to ramp up a new employee. That's the price of admission. If you don't put in that up-front effort, you're not going to gain the additional productivity you're looking for in the new guy.

The next time you start a new employee, take the chance to really look at your organization with those fresh eyes. In most cases, shortcomings that are readilly apparent to the new guy are places where you're really vulnerable organizationally, but you've been getting away with it because you've got good people covering the holes in your process. Take advantage of these clues to shore up the problem areas, and you'll have a more efficient, more reliable organization, and happier new employees, too.

Yesterday, I had a conversation with an IT Manager who was trying to figure out how to set up, allocate, and administer a new VM Server. He's drinking the VM Koolaid, so he went out and bought a nice, big server with lots of storage and RAM and room for expansion. When it came to setting it up and getting VM's running on it, though, he was thinking way too hard.
The VM server in this case is Microsoft's Virtual Server 2005, but the problem and the solution are identical for VMWare. I needed to speak with this IT Manager because I needed access to one of the machines we're supposed to be setting up. As we talked about setup of these machines, however, it became clear that he was trying to factor the VM and the host into every setup and administration decision, and it was making all of these decisions very complicated.

For example, the first problem he brought up was access to the individual machines. He had a mental picture of a user connecting and logging onto the host server, and then gaining access to the consoles of VMs by using Remote Desktop via the host. He correctly anticipated a bottleneck here, as this would get pretty crowded in a hurry.

I pointed out to him that the VMs were going to operate as "real" machines for all intents and purposes, and that if console access to any of these machines was really needed, it could be had by connecting Remote Desktop directly to the VM -- not by going through the host. Of course, I also pointed out that in many cases, these VMs were going to play a role where desktop access wouldn't really be necessary or appropriate. If you wouldn't expect someone to march into your server room and pound on the keyboard in front of a physical machine, there's probably no need to support desktop access to a VM, either.

The same priniple applies to other aspects of management, too. The IT Manager pondered creation of one or more sub-domains to help administer the machines. I pointed out tha the decision about what tools and techniques to use for these machines should be made without regard for whether the machines are physical or virtual. In other words, if a sub-domain is the right way to administer physical servers, then it probably makes sense for VMs, too.

That's the beauty of VMs these days, really -- you can treat these machines just like real hardware (think of them as a rack full of servers or blades), but they are a piece of cake to create, move, and destroy, and you can share some big-time horsepower much more efficiently than you ever could have before. So relax and soak up the benefits, and stop trying to treat them differently. You'll make better, easier decisions and end up with a better overall environment.

I'll assume that everyone reading this blog has some experience in software development. You understand the principles of good software development, and you use these techniques to build software that's modular, reusable, and easy to maintain. Yet, I'll bet that you come across some MS Word documents on a pretty regular basis that are in need of some help in these same areas. If you're not part of the solution, you're part of the problem, so pitch in and start cleaning up those docs!Most MS Word docs just aren't built according to good software development practices.

What in the world am I talking about?

Simple. I'm talking about templates and styles. Based on the docs I've seen people crank out over the years, very few people know how to use them correctly, and the result is a slow parade of documents that look almost, but not quite completely dissimilar to one another, despite the fact that they have supposedly come from the same company or even the same author.

Who cares? It depends on context and degree, really. In some cases, it's really important to get formatting just right. These cases usually aren't a problem, however, because companies employ armies of technical writers and editors to make sure that these important documents come out all right. When document authors are left to their own devices, however, things start to slide. Formats vary from author to author, and in many cases, within individual documents.

Bottom line: this looks sloppy. It's a bad reflection on the author and the company, and worst of all, it often jumps out at a reader as a first impression, and this colors the reader's view of the content. Nobody really follows the advice about not judging a book by its cover, you know.

When this problem is really obvious, it's easy for everyone to see and correct. More often, however, the problem is subtle. A font substitution here, a fuzzy logo there, some headings that aren't done quite like the others. You've probably experienced what real crispness in communication looks like -- a relentless pursuit of uniformity and professionalism no matter where or from whom a document comes. It's typically the hallmark of large, marketing-savvy companies, and it's the only thing that really casts "almost right" into perspective. In other words, "almost right" usually looks ok until it's next to "right" -- and then, it just looks sloppy.

People usually assume that "right" is only achievable through the application of ten-story über-marketing and PR divisions. Not so. The most important prerequisite is desire. If you want to look like you're all on the same team, it's not too hard to do. You know software development techniques, and you can help with this problem.

Yes, you.

Let's think about this problem like we would a software problem. There's certainly a matter of standards and documentation. In other words, would you know "right" if it ran up to you and bit you on the ankle? In the case of finding a standard, you may not be able to arbiter what's desired, but you can help document it once it's found.

Next, how do you apply this format to all of your documents? Again, you should think of this like you would a coding standard. There are manual approaches, automatic approaches, and ways to check for use of the standards.

The manual approach idea is simple: just tell everyone to use the correct formatting.

Hahahaha, haaa...hahahaaaa....., chortle, giggle, giggle.

Ok, maybe I'm the only one who found that funny. You'll probably have better luck if you make it easier for authors to do the right thing. Just as with consistency in web pages, the key here is the proper use of styles. If you know anything about Cascading Style Sheets (CSS) in html, you'll be able to grasp the intent and operation of styles in Word. They operate on selections, just like a DIV tag. They can be cumulative. They are stored either with the document you're editing, or in a global document template (normal.dot).

One of the most common ways to use styles is to edit them in a master document, and then copy the master document. This can be effective, but it's not very elegant. You could also copy your styles to the global template, but that's not recommended because it's not easy to propagate those changes to the rest of your organization.

Instead, the best approach is to save your styles in a document template (.DOT). Not only does this let you wrap the styles up in a portable fashion, it also lets you present a little example of usage when somebody creates a document from that template. When preparing a template with styles, try to keep the contents of the template as relevant, complete, and accurate as possible. Try not to leave styles in the template that you don't want to be used, and make the ones that you do want to use as obvious as possible by giving them meaningful names. Consider the user, and keep things as simple as you can.

Finally, there are a couple things you can do to check for correct use of styles. The simplest is to turn on an option that flags formatting that Word recognizes as just a little bit different than the surrounding formatting. This will also check for "direct" formatting, where fonts, paragraph settings, and other formatting is applied directly instead of through styles. To turn this option on, go to Tools...Options, and click the Edit tab. Look for "Mark formatting inconsistencies", and check it. You'll see blue squiggly lines where Word sees problems. As a last resort, you can also examine formatting and styles using macros. This is a pretty intense and difficult option, but it's there if you really feel the urge to dive in.

I'll leave you with a few links for further reading. If you have any tips you'd like to share, feel free to comment here.

Styles and Reusing Formatting
Tips for Understanding Styles in Word 2002
Microsoft Word: Living with the Beast
Understanding Styles in Microsoft Word

I'm generally a big Microsoft fan, but they do some things from time to time that really bug me. I'd like to think that the reasons are linked to a grand plan somewhere, but I just can't tell sometimes. I've written a few words on this subject before with respect to the .Net framework, and I've got a couple more to gripe about today.I'll start with InfoPath. I recently started to slog through an RFQ for an application that needed to do a fair bit of forms processing (they're replacing paper forms, in fact). I'm writing the technical architecture for the proposal, and these guys are a Microsoft shop, so I pull out the old MS bag of tricks and go to town.

I start with .Net and SQL Server, of course, and since this RFQ called for a disconnected client for quite a few of the users, I spec-ed a smart client. Good stuff - this was starting to look like a fun project. Next, I needed e-forms, digital signatures, validation and workflow. I started considering the options, and as I'm researching specific features of some packages, I see a lot of references to InfoPath.

It turns out that InfoPath would be a great option for this project. It's obviously a great tool for e-forms. The thing that really gets my attention, though, is that I very quickly stumble upon all sorts of articles and examples for how to use digital signatures in InfoPath and how to integrate InfoPath into BizTalk to handle workflow and integration. Great - it looks like I can knock out all sorts of requirements in a flash.

Wait a minute.

There's a small problem with this plan. Remember the disconnected clients? They don't belong to the same organization that's issuing the RFQ. In fact, they belong to a whole bunch of third-party companies. If I spec InfoPath for this project, I add around $200 to every single install for that smart client. In a flurry of keystrokes, I add hundreds of thousands of $$$ to the cost of the project. That's not gonna fly.

I pause for a moment and let the steam waft away in a little cloud of despair. I'm back to doing the forms by hand.

Now, in the big picture, this isn't the end of the world for me, but as an architect, I'm always a fan of using functionality off the shelf. InfoPath was perfect for this project, but I couldn't use it because of the way it was licensed. Now, I understand that MS needs to pay the bills, and the Office suite is a big chunk of their revenue. Still, I needed a way to license this particular Office component as an embedded component -- not a stand-alone Office executable. In this application, InfoPath was going to end up so deeply rooted in the application that it would likely not be recognizable as a separate product. It was going to be a control, like a calendar or an RTF editor. There are some great examples on MSDN about how to create an application with an embedded InfoPath component, but the articles make it clear that you've to have InfoPath installed where this software will run.

Request to Microsoft: Give architects a way to spec InfoPath without incurring this kind of cost. Maybe an application license that lets us use the functionality for a specific application (bake a key into an assembly or something). Whatever. Just let us use it in a smaller increment.

The next gripe is pretty similar. As work continued on this proposal, I needed to start working with a Project Manager to get a WBS ironed out. Tool of choice, of course: MS Project. Here's another one I'm sure you've run into. You put a project plan together, but it's held hostage on your PC. Oh, sure, you can save the plan as HTML, but if you've ever seen the output from that, you know how uninspriring that is.

Have you ever noticed that there are free viewers for every other Office application (Word, Excel, etc.), but not Project? There are a handful of vendors out there selling viewers for $30-40, and ILog's got a free viewer that works as long as you save your project as XML, so again, this isn't the end of the world, but it's another one of those real head-scratchers.

Come on, Microsoft. Give us a little help here, ok?

If you work in a VC-backed company and you don't read Guy Kawasaki's blog, you should start. If you work in a startup that might be VC-backed someday, you should absolutely start reading Guy's blog -- for you, it might come in time to save your neck.

Guy's latest entry is called After the Honeymoon, and it deals with problems that come up after you've got financing in place and you're trying to make it to that great liquidity event in the sky. There's only one problem: if you wait until you're in trouble to read his article, you're already dead.
When I read through his problems, it sounded like an eerie echo of the last four years at my last place of employment. We didn't have all of these problems, but we had most of them. The funny thing is, though, I don't think that merely having the answers to the problems would have been enough to fix them -- at least not in our case.

When I look back at the events that unfolded over the course of the last few years, so many of the really fatal problems were put in place very early on -- the rest were just harmonics of the fundamental injuries. We set in motion a game plan that directly caused some of the problems that killed us. Of course, we didn't know it at the time -- at least not in those black-and-white terms.

So what if someone had objected to the plan? What if they saw problems well in advance of the hurt and tried to route the company around them? In an environment where everyone looks bad if there are any problems, it's dangerous to be the messenger. That's what got our founder / CEO in trouble. So there's problem #1 from Guy's list. Not quite the same circumstances, but whatever, right?

Next up is problem #2. Let's say just for grins that when you close your VC round, the round is supposed to fund sales and marketing ramp-up. Then, also hypothetically, of course, let's say that the investors want to see you broaden your market. You're gonna need product changes. You're also going to need lots of Professional Services resources, because the new direction implies big sales, big implementations, and big support. There's no funding for development, though, so make hay with what you've got. Or less, since you're now training the new Sales & Marketing people, and your headcount is being funneled into PS. Oops ... late product. That's number 2.

Sales is problem #3, and it makes a certain amount of sense that it's hard to ramp up sales in a market other than the one where the company and the product grew up. Nevertheless, you bring in all the best Rolodexes and light up the phones with news of the Great Elephant Hunt. If nothing else, it makes good Boardroom material for a couple of quarters. Later on, it starts turning into an uncomfortable conversation about, "just how long is our sales cycle, anyway??" Like Guy points out, chasing those big accouts is a rush when it's hot, but the cricket noises in between deals gets old after a while.

Problems 6 and 7 are logical extentions of your other problems at this point, and problem 9 is inevitable when things are going this well.

So at what point do you bring this bad news to the Board, and who's gonna bell that cat, anyway? Our founder would have given them the straight poop -- in fact, she did, and got sacked. That's a lesson that wasn't lost on everyone else. That kind of environment breeds yes-men. Hard-working yes-men can right the ship if the list isn't too bad, but if nobody can tell Captain Smith to slow down, well, you know what happened.

So read Guy's list again. Print it out and tape it where you can see it from time to time. If you're not in too deep already, heed his advice. If you are in too deep, I've got some great advice about using SugarCRM to help your job search. 😉

Epilogue

Although this post reads like an indictment of our VC’s, it’s not. They were remarkably tolerant and stood by us for a long time (maybe someday I’ll write about what sort of reward we got for sticking around to the end, but not today).

In fact, this is an indictment of the system. We were a couple of checks and balances short of a solid foundation. Until I lived through a VC-backed startup scenario, I never really understood the importance of independent directors on a Board. I do now. Maybe this is the state of the art for VC-backed companies (hence, “Venture”?). After all, how are you going to get a high-quality independent Board member to help a fledgling startup? Well, here’s an idea: it’s routine for VC’s to partner with other VC’s to do a deal. Broaden the partnership to include a VC that doesn’t have a stake in the deal. Structure it so it’s a swap – you watch over this deal for me, and I’ll watch over this deal for you.

I’d love to hear your thoughts and feedback – let me know what you think.

In part one of this article, I introduced you to SugarCRM and got you up and running. Now, we're going to ramp up your productivity with usage tips and an introduction to customization.

Usage Best Practices

Now that you've got SugarCRM set up, how do you get the most out of it? I'll share some tips I've found, but you should expect to make changes where they make sense for you. First, the basics. The "big three" of CRM are Accounts, Contacts, and Opportunities. If you understand them, you can't go too far wrong. Accounts are companies - any companies or organizations. Contacts are people. They often belong to accounts, but not always. Opportunities are chances to sell something -- in this case, you're selling you! Opportunities will always belong to an account, and should have a contact, too. Most CRM systems (incuding SugarCRM) have another entity called a Lead - we'll use this when we're tracking something that isn't ready to be an Account / Contact / Opportunity yet.


That covers the basics - here are some tips to help things go smoothly for you:

• Use leads for "new" items - they're fast to set up, you can attach notes to them, and you can convert them into an Account and Contact.
• Convert leads early. I started using leads until I was ready to turn them into opportunities, and it was a lot of work. I ended up creating Accounts and Contacts by hand because I thought "converting" would always create an opportunity and delete my lead. Well, it turns out neither were right. Convert a lead as soon as you have a lot of activity or multiple contacts. You don't have to create an account if you don't want to - you'll still be able to access your old lead, and you can change it from "converted" to "In Process" to make it show up on your Home page again.
• Create limited opportunities. I'm sticking to making an opportunity only after I've got a real interview -- not just a screen or HR conversation. This isn't mandatory, but I feel that before you reach this stage, you really don't have anything you could reasonably predict.
• Track everything. When you make a phone call or send an email, take a few seconds to make a note under the "History" section for the contact or account. It can really help when you start getting a bunch of balls up in the air.
• Make sure to use "archive email" instead of "create note" to record emails. It's got more room and can handle html content pasted from Outlook.
• Use activities to manage to-do's. They show up conveniently on the Home page, and provide history of things you've done for / with contacts.
• Google toolbar will highlight addresses and link to a map.
• Keep an eye on the "Last Viewed" bar on the top of the screen. It'll usually save you a couple of clicks.

That's about it for tips - be sure to share any you come up with!

Customization

You'll find SugarCRM to be pretty usable just the way it is, but there are a few things you'll probably want to adjust. Let's start with dropdowns. All of the dropdown lists you see in the system are configurable. From the "admin" menu, find the "Studio" section, and the "Dropdown Editor" link. Open that up, and let's find a list to edit. You should see "account_type_dom" as the current selection, and that'll do just fine. This is the account type, and if you're using SugarCRM to track a job search, you'll want to make sure you've got values like "Recruiter" and "Job Prospect". Note the arrows on the right of the edit screen, where you can reorder the list. Take care when setting keys and order. The key is used to sort, so if you look at a dropdown like task order, the standard keys of "High", "Medium" and "Low" will cause your list to sort as "High", "Low", "Medium". I also found that integer values don't work right - they get mangled as you move things up and down the list. Instead, use keys like "1High", "2Medium", and "3Low" for proper sorting, and then order the list so that the value you want to use as a default value is at the top.


Next, let's look at adding a custom field. From the admin screen, find the "Edit Custom Fields" link, and click it. Choose the "Accounts" module, and click "Select". On the left of your screen, you should see a panel that lets you type in a field name, label, data type, and so on. Set the values you want, and hit "Save". Now, you've got a field, but you won't see it on any screens, so we've
got another setting to change.


Find the "Field Layout" link on the admin screen, and click it. You'll need to find the screen you want to modify - if you just added a custom field to Accounts, you'll want to edit the modules/Accounts/DetailView.html file - click "
Select" to start editing. This screen is tricky until you get the hang of it,
but easy enough once you've done it once or twice.


First, decide whether you're going to add a new spot on the screen or whether you're going to replace an existing field. If you want to add a new spot on the screen, use the "Edit Rows" link on the left, and click a "+" to open up a new row. Now, let's move your custom field onto the screen. On the left-hand panel, expand the "Sugar Fields" section, and find the field and label for the custom field you just added. Click on them and add to the staging area above by clicking the box in the staging area. Now, click the field from the staging area over to the screen, dropping it by clicking on a square where you want to put your field. Do this for field and label.


The last thing to note when adding custom fields is that you're usually going to have to edit more than one screen. For most screens, you should see a DetailView (read-only) and an EditView (for adding or changing). Be sure to change both, or you won't be able to use your new field.


All this sounds like a lot of work, but it's not too bad -- it took about a quarter of the time to make the changes above than it's taken to write this article, so give it a shot!

Related links

SugarCRM home page
SugarForge - home of open source development for SugarCRM
SugarCRM VMWare appliance

Developer documentation for SugarCRM
Siebel CRM
SalesLogix CRM
VMWare
VMWare Player
VMWare community appliances

As I indicated in an earlier article, I've found myself suddenly and somewhat unexpectedly in the job market. Not being one to take such things lying down, I began to make a lot of phone calls and send out a lot of emails. Initially, I used Outlook to track this activity, but it very quickly reached a point where it just couldn't do the trick. In short, I needed CRM, and I needed it fast. I'd recently seen that there was a VMWare appliance available for SugarCRM, so I decided to give it a shot.

Setup

SugarCRM is a mixed-source CRM platform. The basic open-source SugarCRM product is free and available for download, while more advanced Professional and Enterprise editions of the software are available for purchase. There are also hosted and hardware-appliance versions of SugarCRM available. SugarCRM is a fully-functional CRM system, competitive with commercial products like SalesLogix and Salesforce.com. It features the standard Account-Contact-Opportunity relationships made popular by Siebel, and used in nearly all CRM systems now.

In order to use SugarCRM, you have a number of options, including buying a hosted solution. In my case, I was job hunting, so free was good. That meant downloading and installing SugarCRM on my system, or getting the VMWare appliance. A VMWare appliance is a preconfigured OS image, ready to run in VMWare's free VMWare Player. For me, this option offered the fastest setup and great flexibility.

Downloads:
VMWare Player
SugarCRM VMWare appliance

Download and set up VMWare Player, and unzip the SugarCRM appliance. Open the appliance with VMWare Player and start it up. It'll boot into rPath Linux (a stripped-down distribution used to keep the size of the VMWare appliance as small as possible). Log in as "root" with no password. This is clue #1 that this isn't an enterprise-worthy install (nor is it meant to be), so use it only within your firewall. After you log in, type ifconfig and hit enter. Look for a line that says "inet addr" - this is the IP address the machine acquired during boot-up. Make a note of this, we'll need it for the next step.

Now, launch a browser and use the address you just wrote down to navigate to the SugarCRM login screen. Ex: http://192.168.0.5/sugarcrm Note: you can edit your HOSTS file in windows/system32/drivers/etc to add a textual name, like "sugarcrm" for this IP address. Log into SugarCRM as "admin" / "changeme" and take a look around.

Administration

One of the obvious benefits of using the VMWare appliance is that there isn't much administration. The most important thing to do is to make sure you've got good backups. Since this is a VM, this is pretty easy. First, we need to shut down the machine so no files are in use. Log into the console as root, and enter this command: "shutdown -h now". This will shut down the Linux machine, and you can then back up all the files - probably by burning a CD. After you've copied or burned the files, you can start the VM again. If you happen to be using VMWare Workstation instead of the free VMWare Player, you can use the "snapshot" feature to back up the machine.

There are a couple other options for backing up data, but they're not as convenient. First, you can back up all the application files (htm, php, images,
etc) by using the SugarCRM "backups" command from the "admin" menu (upper right on your browser screen). Choose an existing directory, or make a new one (mkdir) under the /usr/share/sugarcrm directory and set permissions (chmod 777) so that the web process can write to that directory. Once the backup completes, you can download the files by typing the appropriate address into your browser. If any of this sounds challenging, just stick to backing up the whole VM to CD.

Ditto for the next backup, which is the database backup. For this, you'll need to open the console, log on as root, change your directory to the backup location you used before, and use mysqldump to write the contents of your MySQL database to a text file (ex: mysqldump sugarcrm > backup_file.sql), and then download the database backup like you did for the application files. This
information may be helpful if you decide to install SugarCRM on a "permanent"
machine. For me, you can't beat the convenience of just burning the whole VM
to a CD.

That's it for part one. In part two, I'll cover usage best practices and
customization.

If you're a job seeker and you work with multiple recruiters or staffing / consulting companies, you have to be very aware of who is showing your resume to which contacts. If your resume shows up twice at the same company via two different channels, feathers are going to get ruffled -- this is known as double posting or double submission, and it'll cause recruiters and employers to drop you in a heartbeat.
My first experience with a double submission was close to ten years ago, when I received the same resume twice as a hiring manager. Not realizing the goo I was walking into, I interviewed the candidate, keeping the first recruiter abreast of my progress (we ended up passing on they guy). Shortly thereafter, I got a call from a very angry recruiter #2, demanding to know what the hell was going on. Boy, was I blind-sided.

More recently, I saw this happen again, and this time I was better prepared. I saw the problem before we called the candidate in for an interview (not always easy to do if the recruiter / staffing company mangles the resumes before submitting), and got both sources on the phone. I let them know what was going on, whose submission had arrived on my desk first, and asked them to sort out among themselves who was going to go forward. Many employers would not have been that cooperative.

Luckily, the two recruiters knew each other and reached a peaceful arrangement. If there had been even the slightest remaining conflict, I wouldn't have moved forward with this candidate at all.

Now, I find myself on the other side of the table. I'm working with recruiters, and they're trying to get me in to see some clients. I've tried to keep up with who's showing my resume to whom, and I ended up catching one today. A recruiter started telling me about a "Planning Architect" position, and it sounded familiar. A quick spin through SugarCRM while I'm on the phone, and I find where I've already learned about this position.

The letter of the law in these cases turns on who actually puts a resume in front of a client first, and though the first recruiter in this case hadn't actually sent my resume in yet, I was scheduled to meet them to discuss the position, and I felt compelled to wave off the second recruiter.

Close call.

Hopefully, this isn't a problem that you run into too often, but you do need to be aware and diligent to make sure you're not creating or walking into one of these situations.

When a company goes through the kind of turmoil I've seen recently, there are frequently opportunities to pick up some consulting hours to help with the transition. I got a shot over the bow last week: "Hypothetically, what would your rate be to do 'XYZ'?" I hadn't given it an awful lot of thought, but suddenly found it was time to do some "back of the envelope" calculations. I found a link that was helpful for me, and I dropped some of my calculations into an Excel spreadsheet that's available for you to download.
First, it may be helpful to consider whether you have any preconceived ideas about what you think your rate might be. They might turn out to be way off, but it'll be useful later to see whether the rate you compute is anywhere near the rate you thought you'd end up with.

Next, grab a copy of the spreadsheet and open it. This spreadsheet is based on a thread about the same subject on the Joel on Software site.

There are just a few numbers in here for you to adjust. I'll comment on them briefly here.

• Salary. This is your W2-equivalent salary, or what you'd expect to make if you worked for someone else.
• Hardware-software budget. After all, nobody's going to buy you that new laptop but you.
• Insurance. Health, liability, and other insurance normally provided by your employer
• Billable hours per week. This is the first of three factors designed to account for the fact that as a contractor, not all of your hours will be billable This is an area you'll want to give some careful thought to, as I'll discuss below.
• Working weeks. You want vacation? Sick time? Holidays?
• Utilization rate. Another billable hours factor. See below

The most important part of the spreadsheet to fiddle with will be the factors in the Revenue area. Generally, you're trying to account for risk here. There's nobody paying you if you find yourself without a client, so you need to plan for downtime to line up that next deal, as well as all the incidental time-wasters that come up during the week.

You can play with both the hours / week factor and the utilization rate factor to see what effect they have on your rate, but remember to leave a few hours per week for administrative tasks like accounting and IT support. You may also want to adjust the utilization rate to account for the length of your contract. If you've got a year-long contract, for instance, you can get a whole lot higher utilization than if you have a series of one-week contracts.

Even with a long-term contract, though, don't go to 100% utilization, since there will still be time spent at some point lining up the next gig, not to mention education, training, and decompression time. In general, the more confident you are that you'll always have another gig spun up and ready to go when another one finishes, the closer you can approach 100% utilization, but remember that 80% is considered a very healthy utilization for consultants that have a supporting crew selling deals for them.

There's clearly a lot more sophistication that could be built into this model, but this should serve to help structure your "back of the envelope" scribblings a bit. Good luck!

A couple months ago, CIO had a great article on open source models: Free Code for Sale: The New Business of Open Source. The really nice part about this article is not that the content is especially deep (it isn't), but that it's a great executive summary of what's going on out there. Having the article show up in CIO also lends real legitimacy to the topic of open source. The article does a good job of descriibing the real business models at work here -- this is more than just hobbyists hacking away on code in their spare hours. I've referenced this article a couple of times already to people who understand the software industry in general, and want to learn more about this aspect of the business.