Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
08/06/10 17:34
Read: times


 
#177803 - So subjective so impossible to give good answers/views
Responding to: ???'s previous message
I think a company should select an employee before hiring a consultant if the task is anywhere near the core business.

When you hire a consultant, you not only pay for the actual work, but you also pay for his education. There will be invoices for his time learning your routines and your tools. If the tools are good, he will then say thank you (maybe) and add these skills to his resume when visiting your competitor and offering similar services.

A product-owning company should strive for maintaining a stable work force with the knowledge in-house. This helps when maintaining the products. And it means the first-line-support will have access to great help if they get stuck. It also makes sure that if someone do a bad job, they will get the not so funny task of keeping their mess together. So people tend to learn to think about the quality. Of course, a stupid manager can quickly destroy this concept by moving older products to junior developers and then fire them as incompetent if they have a hard time supporting the mess.

A product owner should consider consultants when needing help in areas where they either have the knowledge but quickly needs more capacity to overcome a temporary work overload, or where they want to solve - or make an inbreak into - a problem where the company don't have much experience. In that case, the company gets a reversal of knowledge. Besides getting a new feature, it also allows the own employees to pick up knowledges and alternative work methods from the consultant. This of course requires that the company did pick competent consultants.

It is a lot harder to have a view in the other direction. To be an employee or be your own. Personal contacts matters a lot. It can be very hard to sell in yourself. Having a couple of good references helps. Especially since people moves around, so 5 or 10 years later, you will have people who know you in companies you haven't worked with before.

But if you work as a consultant, it's normally not enough that you know how to follow instructions. You must most often be able to show that you can help all the way. Bringing know-how into the requirements specification and bringing know-how into the testing/production phase.

Because of this, few people manages well as consultants without having done a number of years as employees. Unless they work for a consultancy firm where they are just labour for hire with a profile as "worker", "team manager" or similar. The best - and almost only - way to be able to almost directly start as consultant is if doing some school project for a smaller company and proving to be valuable enough that they want to use you even if you don't select to be employed.

When doing just software development, the investments needed is almost zero, which means that it is possible to live a very lean life in case of periods without a project. It's possible to just have a desk at home and the only "extra" cost being the PC, some often cheap software, and a special insurance (in case someone sues you). So you may be able to live acceptable even if only being 50% allocated.

If working with the hw side, life tends to be more complicated. Some useful equipment can be quite expensive. And you quickly fill up a lot of workspace which means that you may need a house if you want to work at home. It's easy to get in a situation where you need to take loans to buy the equipment, which means you need a more regular income to cover the larger regular expenses.

There is also a difference in risks in relation to invoicing. If you do a goof with a PCB spin, you may introduce a couple of weeks of delay in the project. This delays when you may send your invoice, besides the probability that the customer will draw a number of percent every week for the delays. If you do a goof with the source code, you can often spend a couple of hours extra one or two nights to get the software on track.

Another thing. A hobbyist can design quite nice hardware, but the cost of having equipment or hiring for temperature cycling the device, or feeding it 300V instead of 230V or testing all inputs with an ESD gun or doing pre-compliance tests in a shielded room etc can be quite high. And if one of the used hw modules isn't up to spec, the customer will come for you and not for the module vendor.

The above is probably reasons why a lot of people may start doing software projects quite early while most one-man hw designers are 30 or 40 or older. You really want to collect a lot of experience before starting consulting with hardware designs.

There is of course a huge difference between consulting, and being your own product owner. As product owner, you may adjust your time schedules if you don't feel comfortable with something. You decide on the risk - loss of income from delayed release date contra losses from releasing a bad product.

Another thing is that a customer expects a lot more from you when you work for them as consultant than if you work for them as an employee. If you are an employee, they are not really sure where in their chain they have failed - if it was requirements, implementation, testing, marketing, ... If a consultant has been involved in the project, then everyone in the company will "know" where to put the blame. So a consultant just have to catch all goofs in the requirements from the beginning to make sure that there are clear acceptance rules for the project.

List of 10 messages in thread
TopicAuthorDate
The Great Debate: Employee Vs. Consultant            01/01/70 00:00      
   consultants are the firstl aid off            01/01/70 00:00      
      There are positives to being a consultant            01/01/70 00:00      
         beware of ad-hoc meetings!            01/01/70 00:00      
      So subjective so impossible to give good answers/views            01/01/70 00:00      
   In times like these ...            01/01/70 00:00      
   Balance in a free market            01/01/70 00:00      
      "Permanent" (sic) staff            01/01/70 00:00      
         Salaried?            01/01/70 00:00      
   Local differences            01/01/70 00:00      

Back to Subject List