Comparing Consulting, Contracting, and being an Employee

I've worked in IT as a programmer for a while now and have spent quite a bit of time working as an employee, consultant, and contractor. I thought it would be fun to talk about the differences between them in case anyone out there is considering a change from one to the next.

A couple things to note before I get started:

• I've been working primarily as a computer programmer for about eight years now, but for about six of those years I've been trying to be about more than just writing code. I really think of myself as a problem solver who happens to write code, but I live in a world where businesses expect their programmers to have the attitude of "tell me what to build and I'll build it". As a result, until recently I never really felt like I fit into most of my positions, which may have altered my perceptions a bit.
• With a few notable exceptions, most of my employers and clients were small companies. The smallest was a music store that had 5 full-time employees after a couple of rounds of layoffs and people quitting, and the largest was (and is) a software company around 130. While I did have one contract and a couple of clients at large multi-national firms, my focus in this post is on my experiences with small companies.
• All of my contracts were as a W2 employee and I worked through a placement firm - none as a 1099. I had set up a business so I could have done a 1099, but due to circumstances I don't need to get into here I ended up either working as a W2 employee or going on full-time at all of the companies I wanted to contract with. That also means that I didn't have to worry about doing the self-employment paperwork that 1099 contractors have to do.

Life as a contractor

How do I define "contractor"? In my case, I was paid by the hour by a placement firm that took care of employment paperwork for me, but I essentially worked for a company. I had a typical interview process, I was onsite at the company all the time, and I had little-to-no interaction with any other contractors with the placement firm. All of my contracts had a fixed length, but all of my contracts could have continued longer if I wished. As I mentioned above, since I worked as a short-term employee through the placement firm rather than being self-employed, I didn't have to pay self-employment taxes or file tax paperwork.

My day-to-day life as a contractor was fairly easy - people generally expected me to do what I could while I was there and no more. Some of the contracting companies allowed me to work overtime when I wanted, but none of them forced me to since they all had salaried full-time employees they could lean on for that. (Sad, but true....) When I did work overtime, I didn't mind nearly as much as I did working as a consultant or employee, since I got paid extra for the extra work. (It's only fair, right?) I also found that as a contractor, I didn't get as stressed about my environment as I might have as a full-time employee, since I knew that my contract would end at some point and I could choose not to renew if necessary. Finally, working at jobs on a short-term basis really allowed me to see a wide variety of companies and approaches and to meet a lot of people, and these have helped shape my opinions about what works and what doesn't. And as a short-term contractor, more employees opened up to me in ways that they might not have if I were going to be there long-term, giving me even more insight into how the company was and wasn't working well.

On the other hand, as a contractor, since I typically wasn't invited to company meetings, I often found myself out of the loop when it came to process or personnel changes, even when they affected me. I often had to ask the full-timers to fill me in on what happened when I started noticing changes in my surroundings. Since I was clearly a temporary employee, I often got put on the more difficult and/or unpleasant assignments, and rarely was given the responsibility to complete them on my own. Career development was also completely on my own; I had to spend my own time learning new technologies and tools, and I had to create my own leadership opportunities. Perhaps the most frustrating part for me was that I hate looking for jobs, but being a contractor meant that I basically always had to have an eye on the job market.

Overall, I'd say that the contracting life is great if you're not sure where you want to go and just want to try out a few different experiences. It's also pretty good if you want to have a lot of control over which types of opportunities that you work on. It's a lot of work, though, even if you go the W2 route and skip the self-employment paperwork.

Life as a consultant

When I say "consultant", I mean that I worked for a single company, but that company would assign me to various projects for third parties. As a consultant, I didn't have to go through an interview process for a new project, but I also had less control about which projects I could take. While some consulting firms encouraged their employees to work on the client sites, I typically spent most of my time at my employer and called my clients (sometimes daily) when I had questions.

My day-to-day life as a consultant varied greatly depending on the project I was on. One month I'd be on a project where the clients were fairly tech-savvy and all I would do was implement their designs, the next I'd be on a project for a non-tech-savvy client and I would be leading a lot of meetings, and the next I'd be teaching a client about a technology with which they weren't familiar. Sometimes I'd be put on a project where everything was set up well and basically I wouldn't have to screw up, others I had to put in super-human effort and the project still failed because of decisions made long before I got involved. Either way, most of the time I knew I'd only be on a project for a short period of time.

Most of the time, though, as a consultant you are surrounded by people who really know what they are doing. They eat and breathe technology, so I rarely ran into a problem where one of my peers didn't have an answer. (Unless it was a problem for which I was the resident expert, in which case I was out of luck.) In such an environment, nearly everyone had energy to tackle new problems, and it was very hard for your skills to atrophy.

The hardest part for me being a consultant is that I had an incredibly hard time moving beyond pure code-writing, MBA or no MBA. As anyone who reads my blog knows, I think that chasing technology is a losing proposition (both from an individual standpoint and the standpoint of the business that cares about profitability) and we as technologists need to become experts in business areas as much as technology stacks. In other words, I didn't really have an opportunity to learn the skills and gain the experience necessary to become a leader of providing true value to clients until I left consulting to get experience as an employee. The other difficult thing is that you're forced to be on the cutting-edge of technologies, and for the most part you have to spend your free time to do it.

If you're straight out of school, consulting is a great experience because you're surrounded by knowledgeable people, and you can get a wide variety of experiences in a relatively short amount of time. Or if you were a stereotypical "tell me what to build and I'll build it" developer and you really loved working with the latest and greatest, consulting would be a little slice of heaven for you. Don't expect to get a lot of quality leadership and management experience, though, and when you do you'll need to learn mostly by trial and error. If you do like working with end users and problem solving, you may need to get some experience elsewhere and go into consulting as a pre-sales engineer or target a firm that really focuses on problem solving, not technology implementation. (If you find such a company, please let me know.)

Life as an employee

When I talk about being an employee, I'm referring to experiences where I was essentially a staff member hired to support internal personnel. I am currently working for a company that employs programmers to work on a software product, but my job is to support the internal software needed so that they (and others) can do their job. As an employee, the company that sees the most benefit from my effort is also the one that signs my paychecks, which is not the case as a contractor or consultant.

More than either contracting or consulting, the quality of life as an employee varies greatly with the environment you are in. Contractors can take solace in a bad job by saying it's only temporary. Consultants can bury themselves in a project, or patiently wait for the next project. For better or worse, employees are stuck in their current situations for the foreseeable future. (Remember, I've worked primarily for small companies. I would guess that large multi-nationals would have more opportunities to move around within the company.) That means that it's incredibly important to ensure that you get into the right position in the first place. What makes it tough to decide whether a position is right for someone is that we all have different needs and wants. To say that "I liked this place because it was a good place to work" is pretty useless. To prove this point, recently I changed contracting jobs and found someone moving from my new firm to my old one. We each were much happier, and our personalities much better suited, to our new jobs.

The thing that I like most about being an employee is that I have an opportunity to really dig down into the cause of an issue and am able to be an active part of creating a long-term solution. I really get to use my leadership skills to do more than merely shape the technological underpinnings for a piece of software. As a result, I get to work together with a wide variety of people to solve a wide variety of problems, but since they're all for one company, I get to see how all of the problems are interconnected. As a bonus, my employers past and present were willing to help develop skills, both related to technology and not.

Perhaps the hardest part about being an employee is that people don't respect my time as much. When I was a contractor or consultant, people knew I was being paid by the hour, so they looked to minimize the amount of time I spent in meetings or performing activities they could do, like configuring software. As an employee, I get dragged into a lot of meetings and projects that aren't necessarily the best use of my time.

So which situation is best?

If you're just starting out in IT, I'd recommend going into consulting for a few years. You get to see a wide range of projects, work with a number of different technologies, for a variety of company types. This experience allows you to hone in on what works for you.

If you're experienced, your mileage will vary depending on your goals. If all you want to do is play with cool technologies, it's tough to beat the environment that a good consulting firm is able to provide. If you're looking for a lot of flexibility and aren't looking for career growth, contracting may be the way to go. If you're looking for stability, or if you're looking to develop your leadership skills, looking for full-time employment is probably your best option. As for me, I'm happy in my current situation as an employee, because the particular role fits me. If I do start looking again, I'll probably look for all three types of roles and focus on finding the best situation for my unique focus within IT.

Yammer, what is it good for? Absolutely nothing! (Or maybe....)

A few weeks ago, I wrote about how Microsoft has its work cut out for it in selling Yammer. I've attended several conferences about Yammer, and in each one several people ask what good Yammer can do for a business. In each presentation, the presenter gave some examples that highlight some marginal uses for the technology. The naysayers, then smelling blood, repeat even more forcefully that they simply don't see an ROI for the technology. In one presentation, I had the Edwin Starr song "War" running through my head, with slightly different lyrics:

Yammer! Hooh!
What is it good for?
Absolutely NOTHING!

I do see value in Yammer, but as I wrote last month, its value lies in areas that aren't at the top of most managers' priority lists. Where I see Yammer's real value as a tool increase group communication on a small scale. Or to use buzzwords, to increase collaboration among self-organizing groups. To clarify, here are some use-cases:

• A project lead wants to share information about the status of a project. Every week he or she sends a status email, but frequently someone asks to receive or not to receive these messages. Yammer would allow the project lead to create a group for the announcements, post the updates to the group, and let everyone join or leave the group as they wish.
• An employee has a question about how to handle a particular issue, but his or her boss isn't quite sure how to handle the issue either. Instead of calling a meeting to discuss it, the employee can post a question to the department group and let everyone post their opinions and come to a consensus.
• A new employee has a question about the location of one particular bit of documentation. Instead of bothering the person next to him or her every time a question arises, the employee can post a question to the topic-specific group and let whoever has time address the question.
• An executive wants to share information about news in the industry, but doesn't want to send mass emails several times a week. That executive could create an "Industry News" group and let whoever is interested in the topic join the group to see the news.

In all of these cases, you can accomplish the same goal with creating email groups or organizing documents. In fact, I'd argue that most business leaders who are trying to solve the problems above aren't thinking about social media as a solution - they're either thinking about more mundane solutions (such as organizing emails) or focused on more pressing problems. But Yammer is a more natural solution to these types of issues. And unless your company is made up of 2-3 people or is made exclusively of superior communicators, it probably is worth implementing for your organization.

Levels of function (and dysfunction) IT can have with business: Part 1 of 8

A lot of articles are written about how IT and the rest of the business have difficulties working together well. Clearly there are differences between companies that merely have challenges with communication between IT and companies that have such horrible communication that business creates "shadow IT" departments. What should be just as obvious is that solving problems within each type of group should take a drastically different approach. There are no frameworks that I'm aware of that help companies gauge their problem, though. Luckily for us, Steven Wheelright and Robert Hayes from the Harvard Business School came up with a useful framework (payment needed for the full PDF), to describe how manufacturing is treated in the rest of the business. This post is my attempt to adapt their terminology to IT.

Stage One: Internally Neutral (Minimize Manufacturing's Negative Potential)

The "Minimize Manufacturing's Negative Potential" subtitle describes quite accurately the level of interaction between manufacturing and the rest of the business at this level. Rather than look upon ways of manufacturing products as a source of strength, companies at this level merely see manufacturing as a necessary function whose importance and effect on the rest of the business should be minimized. Here are some characteristics of this stage as given by Wheelright and Hayes:

• Managers attach little to no strategic importance to infrastructure issues [such] as workforce policies, planning and measurement systems, and incremental process improvements.
• …production managers run into top-level insistence to remain flexible and reactive so as not to get locked into the wrong decisions.
• …Stage 1 organizations think of production as a low-tech operation that can be staffed with low-skilled workers and managers.
• Eager to keep the manufacturing function as simple as possible, they feel justified in thinking that "anybody ought to be able to manage manufacturing"
• With a self-limiting view of what manufacturing can do, managers find it difficult to upgrade their labor-intensive, low-technology processes when [new] products … appear

Based on my interpretation of the article, here are some signs that your IT department is in Stage 1:

• Your software developers don’t interact with end users or your customers, they simply take orders from management, business analysts, and/or project managers.
• Neither your business analysts nor your project managers know much about software development or how it fits into the business as a whole. The business analysts merely document requests and the project managers merely report on which tasks have been completed.
• Your programmers must have their requirements spoon-fed to them, since they are incapable of interpreting the intent of a request.
• You have nobody with a technical background in executive levels of management.
• Your employees with a technical background are managed by whomever in the company is willing to do so, and rarely by someone with technical experience.
• You have no problems asking your developers to work 60-100 hours a week on a regular basis.
• You don’t give your developers any time to learn new products or technologies and don’t allow them to try out new technologies on new products.
• You have never heard of user experience designers or information architects.
• When problems arise, upper management gets involved to fix the problem, despite the fact that they know little about its causes.

Stage Two: Externally Neutral (Parity with Competitors)

The goals of a company whose interactions with their manufacturing department could be described as being in Stage 2 would be to keep up with their competitors manufacturing-wise, but primarily look for opportunities for creating a competitive advantage elsewhere. Here are some characteristics of this stage, as defined by Wheelright and Hayes:

• Following Industry practice in matters regarding the work force, … equipment purchases, and the timing and scale of capacity additions.
• Avoiding, where possible, the introduction of major, discontinuous changes in product or process.
• Treating capital investments in new equipment and facilities as the most effective means for gaining a temporary competitive advantage.
• Top managers of Stage 2 companies regard resource allocation decisions as the most effective means of addressing major strategic issues in manufacturing.
• Offensive investments to gain competitive advantage are usually linked to new products; manufacturing investments … are primarily defensive and cost-cutting in nature.

Based on my interpretation, here are some signs that your IT department is in Stage 2:

• Your software developers do not interact with end users much and still rely largely on project managers and business analysts to give them direction.
• Your software developers do not want to interpret the needs of end users, instead they prefer to have their requirements spoon-fed to them so they don't have to think.
• Whenever you upgrade your technology, it is because you can or because your competitors are, not because you have a specific need you're trying to solve.
• You primarily hire people that will fit within your existing process rather than those that will improve it.
• Your entire software development team is ignorant of any new product opportunities in the pipeline and are on a "need-to-know" basis regarding new business strategies.
• Software development managers can come from a technical background or not, but either way are expected to enforce the status quo rather than improve the current situation.

Stage Three: Internally Supportive (Provides Credible Support to the Business Strategy)

A company could be characterized as Stage 3 when manufacturing is expected to actively support, but not shape, the strategy of the business as a whole. Here are some characteristics, again as defined by Wheelright and Hayes:

• Screening decisions to be sure that they are consistent with the organization's competitive strategy.
• Translating that strategy into terms meaningful to the manufacturing personnel.
• Seeking consistency within manufacturing through a carefully thoughtout [sic] sequence of investments and changes over time.
• Being on the lookout for longer term developments and trends that may have a significant effect on manufacturing's ability to respond to the needs of other parts of the organization.
• Stage 3 companies … view technological progress as a natural response to changes in business strategy and competitive position.
• Another characteristic of Stage 3 organizations is that their manufacturing managers take a broad view of their role by seeking to understand their company's business strategy and the kind of competitive advantage it is pursuing.

Here are some signs that your IT department is in Stage 3:

• You have executive-level leadership with technical knowledge in your organization, but they report to the CFO, CMO, or COO, not the President or CEO.
• Your software developers have access to end users during the development and testing phases, but the software strategy and software design phases are still driven by non-technical personnel.
• Your management team goes to your technology team relatively often with ideas, looking for feedback about how to make them a reality.
• Most of your technology managers have at least some knowledge of both the company's overall strategy and the nuts and bolts of the technology that their staff is using.
• Your project managers and business analysts are very technical and may have once been programmers themselves.

Stage Four: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

What distinguishes this stage from the other three is that this is the only stage where manufacturing is expected to make an equal (or greater) contribution to the overall success of an organization as its fellow departments. It is important to note here that there are two distinct types of Stage 4 companies:

1. Companies whose business strategies place primary emphasis on manufacturing-based competitive advantage to the detriment of other functions, which are relegated to a Stage 1 or 2 role.
2. Companies who strive to provide equal weight to all departments to achieve balance within the organization.

For purposes of this blog, I am going to ignore the first type of Stage 4 company. Companies that are dysfunctional because they emphasize manufacturing or technology too much are as dysfunctional as those who emphasize manufacturing or technology too little.

Here are some of Wheelright and Hayes' key characteristics of Stage 4 companies:

• [Manufacturing] anticipate[s] the potential of new manufacturing practices and technologies and seek to acquire expertise in them long before implications are fully apparent.
• They give sufficient credibility and influence to manufacturing for it to extract the full potential from production-based opportunities.
• They place equal emphasis on structural (building and equipment) and infrastructural (management policies) activities as potential sources of continual improvement and competitive advantage.
• By treating the manufacturing function as a strategic resource … they encourage the interactive development of business, manufacturing, and other functional strategies.
• There is an expectation in Stage 4 that all levels of management will possess a high degree of technical competence and will be aware of how their actions may affect manufacturing activities. Further, they are expected to have a general understanding of the way products, markets, and processes interact and to manage actively these interactions across functions.

Here are some signs that your IT department is in Stage 4:

• You expect your software developers to be actively involved in all stages of the software development lifecycle, including strategy and design.
• Your software developers are trained in areas other than pure software development, such as business areas and leadership.
• You do not have dedicated project managers or business analysts; instead your software development team manages themselves and gathers their own requirements.
• Your software development team has a pretty solid knowledge of most new software development techniques, regardless of whether they’re using them at the moment.
• You have someone whose job is primarily to manage the technical side of the company at the highest levels of management.
• Your technology people understand how the technology enables the business strategy and the rest of the business understands the potential and limitations of technology and how that affects the business.

Why this matters

Putting terminology around these levels is fine for an academic discussion, but this isn't an academic blog. Where I see the value in this structure is in recognizing that it takes different solutions and approaches to solve issues in a Stage 2 organization than in Stage 4. But since this topic is too huge for a single blog post (indeed, Wheelright and Hayes wrote an entire book about manufacturing), I will be rolling out a series of posts for the rest of the year to apply these concepts to the real world.

Here is the current schedule:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: What a Stage 2 organization might look like

August: What a Stage 4 organization might look like

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

When avoiding the Sunk Cost Fallacy can be a mistake

One of the concepts that I learned about when getting my MBA was the Sunk Cost Fallacy. For those of you who may be unfamiliar with the term, here is a definition from Wikipedia:

In economics and business decision-making, a sunk cost is a retrospective (past) cost that has already been incurred and cannot be recovered

In other words, when you are determining whether to continue with a project, you should not consider the costs incurred to date. For example, let's say that you need a new CRM system for your company. You've evaluated the existing systems and decided that none of the existing systems meet your needs and that you need to need to build your own. $30,000 into the project, and an estimated $30,000 to go, you decide that a $20,000 system would be adequate. The normal human reaction would be to say that "we've already put so much effort into the project, we can't stop now". The fallacy here is that the original $30,000 is lost. There are no circumstances in which you can get that back. If you are to avoid the Sunk Cost Fallacy, you should decide if you want to spend $30,000 to finish the custom system or $20,000 to purchase the new one. Period.

The problem with that statement is that people's feelings do matter. When you're purchasing or building new software, people track the costs for gathering requirements, making customizations, training, etc. But people almost always forget that the hardest parts for delivering software can be around usage:

• How do I make sure that people use the system?
• How do I make sure that people use the system correctly?

When considering whether to abandon the CRM project, one must also gauge the reaction that the team will have when abandoning the project. Sometimes, stopping the project will bring a sense of relief to the team and the savings by purchasing the system will be even greater than what is obvious at first. Other times, the team will feel betrayed that their project is being abandoned and will subconsciously undermine efforts to implement the new system. (This can be especially true if there were nice-to-have features in the old system that people were excited about that were absent in the new one.) In these cases, continuing with the original plan is actually the correct decision, regardless of the savings on paper.

To be clear, I'm not arguing that the Sunk Cost Fallacy is an idea that should be ignored. Clearly that is not the case. We need to be careful about making business decisions based on our personal investment into a project. But we must also remember that excitement and buy-in are important too, and if you kill these by trying to save costs you will never realize the intended savings.