So you want to be a consultant?
twintechs.com
twintechs.com
First of all, what do I mean by "difference between consultant and contractor"? Well, if you go off as a freelance / solo developer, your business card may say "consultant" but you'll still be "just another developer" in the eyes of most clients, and in that role you're really just a contractor. That is to say, you're contract labor... just a cog in the machine, another brick in the wall if you will.
If you're on a 6+ month engagement where you show up every day from 8-5 and write code in a cubicle all day, you're probably more contractor than consultant.
OTOH, a "consultant" is seen as having valuable and highly prized insights and knowledge, and is paid to help solve a problem, or work through a situation... which may or may not involve writing code.. if it does, it would probably be highly specialized code that only a small number of people could write. But ideally, if your "consulting" you would be doing just that - working with a high level executive (CTO, CIO, VP) or at least a mid-level manager, and providing them knowledge and insights to deal with a situation.
If your work product for an engagement is a report or presentation of some sort, and one or more recommendations about what the firm should do, or what choice they should make between a set of competing alternatives, then you're in more of a "consulting" role.
Anyway, that's my take. Like I said, some people won't care about any of this. But it matters in that a "consultant" (per the above definition) is seen as more of a colleague / peer to management, isn't necessarily sitting in a cube from 8-5, and generally isn't seen as "hired labor". If that kind of thing is important to you, I suggest specializing in something where you can be paid to sharing your insights, not just for writing code.
I get that the difference between the level of services you're describing for a "consultant" vs. a "contractor," but I think that has more to do with the capacity of the individual contractor/consultant than the label itself.
And again, a lot of people may not care about the distinction. For someone who is used to sitting in a cube 8-6 as a W2 employee at Initech, they won't be any worse off if they're sitting in a cube from 8-6 as a C2C freelancer. But for people who think that going freelance is the route to more respect, more freedom, and less of that "cog in the machine" feeling, then I advocate spending some time thinking about how to make that leap to "consultant who gets paid for sharing insights" as opposed to being just another (apparently fungible) nameless, faceless coder.
Both are more about "management consulting" (aka, McKinsey, Deloitte, etc.) than what most of us probably have in mind, but they are both entertaining reads in their own respective right.
House of Lies is a sort of retrospective "tell all" from a former management consultant, and inspired a TV program of the same name. At times it's hard to tell how serious he is, and the TV show is clearly not meant to be a completely accurate documentary (although it may be more truthful than you'd think) but it's a fun read.
The Firm is basically the history of McKinsey, and while that might sound pretty dry and boring, it turns out to be fairly fascinating. Lots of interesting characters involved, and some fun drama and what-not. And it's interesting to see how McKinsey grew from basically nothing, to being the behemoth it is today.
[1]: http://www.amazon.com/House-Lies-Management-Consultants-Stea...
[2]: http://www.amazon.com/Firm-McKinsey-Influence-American-Busin...
How feasible is it to have remote employees when most of your work is on embedded systems?
I recently started a software consulting group with a couple of partners, and we are starting to hire. I'd like to offer remote positions, but since most of our work is on embedded systems (e.g. medical devices), I don't think this is really feasible. For any given system, there's so much pain in wiring, setting up and debugging a test and development environment, etc. that it doesn't seem worth it. However, maybe I'm overestimating the difficulty and underestimating the benefit. Anyone else have success with remote work that is not primarily on web systems?
I have worked on an embedded systems team where some of the employees were remote. The biggest challenges were with sharing details for reproducing specific issues, but emailing videos and lots of conference calls made it a functional environment.
You say the environment was "functional". For you, did the advantages of having the larger applicant market outweigh the disadvantages?
So, if you're based somewhere crawling with tech talent and the nature of your product already attracts it, then it very well might be a net-negative to operate your team remotely.
Otherwise, I think you'll find it's worth navigating some of these setup issues to be able to hire the best from wherever you're based.
It requires a lot more up front planning. It doesn't work as well for an "agile" environment. Although from what I have seen it is difficult to make "agile" work in a specialized hardware environment anyway.
The machines we build are big. As in $100,000 build cost and almost half a ton of aluminum and plastic big. Obviously not something each employee can take home to work with remotely.
Since our control system hardware is pretty high level (Pentium-processor SBC scale), we have a lot of leeway in terms of footprint. So we simulate as much of the I/O as we can. This lets us do a lot of development without each developer needing the actual hardware for most testing. By abstracting the hardware away in this manner, the development becomes similar to server-type software dev that can be done on a desktop.
It doesn't solve all the problems, but we can do probably 80% of our development work on our laptops and only need to do some critical testing on the actual machine itself.
Where the need to be in the office really hits is the interactions with electrical and mechanical engineers. While they have drawing and specs in electronic format, the discussions usually rely on everyone being colocated. I've found it is very difficult to explain designs even over good video conference systems.
I have all the usual stuff you'd need to develop / debug hardware and would be open to fly on-site every now and then too.
- Work as a fulltime employee doing the same type of work you want to be paid to do as a consultant. It's a legitimate way to get the kind of experience you want to sell.
- Be your own first client. Build something that interests you, and sell that experience.
And if you're technically good and put in the hours, and your senior manager/partner has pull among his/her peers, then you will be taken care of in raises/promotions/etc. As soon as you notice the senior management can't go to bat for you for the things you want, then IMHO you should look to make a move. Ideally you can make a move internally, but you dont want to be stuck.
Do remember, many of the employees you deal with will think you are a member of the true oldest profession (Genesis 3:1).
1) I can't comment on the viability of getting great clients by going big consulting firms, but it feels quite indirect. And probably can't expand developing experience as noted.
2) Seems very ideal and in fact something I'm trying to pursue right now, but I suffer from the classic chicken-egg problem where I can't get clients without having prior clients.
3) Seems more like a natural extension once you grow your network enough
4) Sweet spot. I'd love to find a small consultancy, you'd get the best of both worlds, steady flow of clients, but nearly the same flexibility as being an independent consultant. Are there resources to finding those unicorn consultancies? I'm doing mostly Rails/full-stack work, but most consultancies seem to be either local or not that flexible with part-time/remote
Great question. AFAIK, there are not.
I have tended to only find out about them by word of mouth after spending some time in a particular area of specialization. Back when I was doing Flex, Universal Mind and Digital Primates were well-known in that arena. You tended to see them in conferences, and some of their employees were the ones who authored the best known technical books on Flex. So there is one idea: find out where some of the renowned bloggers, authors, and developers in your field of interest do their consulting.