Ask HN: Moving from a product org to a consulting org: What should I know?
73 comments
I’ve been on all sides of this and bounced back and forth between consulting and product a few times in my career.
First: I think it’s a great idea. Consulting, especially in an agency environment w/ many clients is high energy. Depending on the size of the team you can still wear many hats and touch a lot of different projects. It ends up adding a lot of color to your day to day life.
As far as the monotony of boilerplate: that can be seen as a drag or as an opportunity to develop in house best practices, protocols and tooling to eliminate the drag of all that as well as the room for error/inconsistency.
It’s a lot of fun! I encourage you to jump in feet first. Don’t worry too much about your future career prospects - continue to grow and learn and i’d wager this will make you a better candidate in the future.
My network grew larger than it ever did in agency environments. I built the entire Four Loko website at one point. I have work still running on Farmers.com. I got to provision the first Linux instances inside of a big spooky hedge fund in Century City. It was a great time in my life.
First: I think it’s a great idea. Consulting, especially in an agency environment w/ many clients is high energy. Depending on the size of the team you can still wear many hats and touch a lot of different projects. It ends up adding a lot of color to your day to day life.
As far as the monotony of boilerplate: that can be seen as a drag or as an opportunity to develop in house best practices, protocols and tooling to eliminate the drag of all that as well as the room for error/inconsistency.
It’s a lot of fun! I encourage you to jump in feet first. Don’t worry too much about your future career prospects - continue to grow and learn and i’d wager this will make you a better candidate in the future.
My network grew larger than it ever did in agency environments. I built the entire Four Loko website at one point. I have work still running on Farmers.com. I got to provision the first Linux instances inside of a big spooky hedge fund in Century City. It was a great time in my life.
I appreciate this perspective, thanks!
If you are using the same skills over and over again in different consulting environments, you probably will be gaining deeper expertise with them, especially as you traverse different business domains that will exercise and flex the "boilerplate" in different ways depending on the business and project requirements. There, one sentence.
I started as a consultant and moved the other way, here are some key differences I see:
- "long-term" architecture of projects is non-existent on short contracts (anything less than ~2 years)
- The ownership feeling is very different if you're working directly with a client, or if you work with your own team
- Even if the project sucks, it's nice to know that you won't be on it forever
- Networking as a consultant is great
- Your manager is always planning for the next project, any "down-time" is lost revenu, so expect to spend less than a week when switching between 2 projects
- I found salary negotiations simpler as a consultant, basically I knew what my manager was charging for my day. Remove some % that they're willing to live with. Then, you can do some easy math. This was within a small shop, so I wouldn't know if that would scale to big groups.
- "long-term" architecture of projects is non-existent on short contracts (anything less than ~2 years)
- The ownership feeling is very different if you're working directly with a client, or if you work with your own team
- Even if the project sucks, it's nice to know that you won't be on it forever
- Networking as a consultant is great
- Your manager is always planning for the next project, any "down-time" is lost revenu, so expect to spend less than a week when switching between 2 projects
- I found salary negotiations simpler as a consultant, basically I knew what my manager was charging for my day. Remove some % that they're willing to live with. Then, you can do some easy math. This was within a small shop, so I wouldn't know if that would scale to big groups.
I also started consulting and moved to product and I agree with what you say, but one difference is that in product you can usually negotiate a higher salary (although you'll feel more uncertain about it) since you're not capped by any consulting rate.
Essentially your salary is investment for the company, not cost.
Essentially your salary is investment for the company, not cost.
I was a consultant in security for 15+ years and switched to 'industry' as an engineer/team lead in a large org. I agree with every point you've made, particularly re: networking and ownership, in fact I am still struggling a bit with old habits. I don't know if pwnasaurus can reverse engineer any tips out of them but here are a few:
One challenge in particular is that I have next to zero inertia in my thinking...I will stay with an idea exactly as long as I think it's the best compromise of factors, but if I find a better idea I pivot like a light cycle in Tron. In the consulting world I always have to explain my thinking anyway so this was generally fine. In the product world I'm finding that people in my sphere build mental models of my thinking (or expect me to toe the line) and get surprised in not-great ways when that's not the case. For OP the advice might be that most people won't (likely) have a clue who you are or how you think, and the assumptions and patterns you've developed in a product org might be wildly different than the status quo from place to place. I would say overcommunicate and apply 'when in Rome, do as the Romans do' unless you see a compelling and explainable reason not to.
A related issue is that I will tend to argue multiple positions simultaneously. This might be specifically from the infosec part but I see everything as a tradeoff and unless I 'try on' a position I can't really fully appreciate the nuance. In consulting this worked because it let me test counterarguments and try to land on a well-considered place. In the product role this just tends to confuse people I think, especially if the arguments go against the party line. I don't know if there's anything valuable to extract here for OP.
I also struggle a bit with low 'ownership stamina'. Keep in mind that my average engagement length as a consultant was 2-3 weeks, but I'm great for MVPs and that's about the extent of it. For OP this really depends on your role...if you're staff aug on year contracts there's probably nothing for you to learn from this. If you're short term I think the lesson is that any tech debt or 'I can deal with that later' burden that you are assuming from a decision isn't actually going to be yours to bear. For OP, if applicable, I think the lesson here is to realize that all burdens are going to your customer so prioritize documentation, minimizing loose ends and lowering tech debt/operational costs.
Good luck! It's probably going to be stressful at first but you're going to meet a lot of cool people and neat problems along the way. If you used LinkedIn, get ready to blow that puppy up!
One challenge in particular is that I have next to zero inertia in my thinking...I will stay with an idea exactly as long as I think it's the best compromise of factors, but if I find a better idea I pivot like a light cycle in Tron. In the consulting world I always have to explain my thinking anyway so this was generally fine. In the product world I'm finding that people in my sphere build mental models of my thinking (or expect me to toe the line) and get surprised in not-great ways when that's not the case. For OP the advice might be that most people won't (likely) have a clue who you are or how you think, and the assumptions and patterns you've developed in a product org might be wildly different than the status quo from place to place. I would say overcommunicate and apply 'when in Rome, do as the Romans do' unless you see a compelling and explainable reason not to.
A related issue is that I will tend to argue multiple positions simultaneously. This might be specifically from the infosec part but I see everything as a tradeoff and unless I 'try on' a position I can't really fully appreciate the nuance. In consulting this worked because it let me test counterarguments and try to land on a well-considered place. In the product role this just tends to confuse people I think, especially if the arguments go against the party line. I don't know if there's anything valuable to extract here for OP.
I also struggle a bit with low 'ownership stamina'. Keep in mind that my average engagement length as a consultant was 2-3 weeks, but I'm great for MVPs and that's about the extent of it. For OP this really depends on your role...if you're staff aug on year contracts there's probably nothing for you to learn from this. If you're short term I think the lesson is that any tech debt or 'I can deal with that later' burden that you are assuming from a decision isn't actually going to be yours to bear. For OP, if applicable, I think the lesson here is to realize that all burdens are going to your customer so prioritize documentation, minimizing loose ends and lowering tech debt/operational costs.
Good luck! It's probably going to be stressful at first but you're going to meet a lot of cool people and neat problems along the way. If you used LinkedIn, get ready to blow that puppy up!
I would work for a product company or get your own consulting clients.
In the agency model, the company's profit margin is everything they don't pass to you. There are too many incentives to overwork and underpay you. The larger the agency, the more this is true (see accenture). But give it a try and if it sucks you can always quit.
I like consulting directly with clients because it does expose you to a lot of different industries and also pays pretty good compared to most startups. Working with other agencies has been a very bad and expensive decision for me in the past.
In the agency model, the company's profit margin is everything they don't pass to you. There are too many incentives to overwork and underpay you. The larger the agency, the more this is true (see accenture). But give it a try and if it sucks you can always quit.
I like consulting directly with clients because it does expose you to a lot of different industries and also pays pretty good compared to most startups. Working with other agencies has been a very bad and expensive decision for me in the past.
This is very true. Good agencies know that they're reputation is more valuable than goosing their margins in the short term but not all agencies are good. I worked in the agency space for a good long time and actually found the most rewarding role was being involved in presales and having input on contract writing so I could help spell out what scope comes at what price. That and wrangling process to make sure the team is laser focussed on delivering to the contract. Two things I never thought I'd enjoy as a young developer.
Always be billing. If you're on the bench for an extended amount of time, start looking for a new job.
I personally think working for a consulting org is very stressful and they tend to keep all the profits at the top. Better to follow the other advice here and start your own--maybe start with a consulting org, negotiate a less restrictive non compete, build your client list, and start your own.
I personally think working for a consulting org is very stressful and they tend to keep all the profits at the top. Better to follow the other advice here and start your own--maybe start with a consulting org, negotiate a less restrictive non compete, build your client list, and start your own.
It definitely can be stressful. I wouldn't go back now, but a young man I thrived on that sense of mission and urgency, and on the chance to prove that I was equal to whatever problem came my way. It can be a lot of fun if you're up for that sort of thing!
Soft skills are much more valued than hard skills. You can be a mediocre developer as long as your code does the job, but you will thrive insofar as (you can make) your clients like you.
There are many ways to bring value other than writing code, mostly trying to fix broken processes at your client's and putting out fires that nobody cares about anymore.
In other words, if you care and value deep expertise then consulting may not be the best place for you. It certainly was not for me.
(sorry for the negative take, it certainly depends on the company's culture and how they are positioning themselves on the market)
There are many ways to bring value other than writing code, mostly trying to fix broken processes at your client's and putting out fires that nobody cares about anymore.
In other words, if you care and value deep expertise then consulting may not be the best place for you. It certainly was not for me.
(sorry for the negative take, it certainly depends on the company's culture and how they are positioning themselves on the market)
That's not always true. Both are valuable. A mediocre developer with good soft skills can make their way to management more quickly. But a good and fast developer will be worth their weight in gold. The best devs I've ever worked with I worked with at agencies.
To counteract the negative take with my own somewhat, I have found that people are quite happy to have deep and broad consultants. What you say is on point, just for me the customer fires can get quite technical and span many technologies
I definitely want to hear both the positive and the negative, so thank you!
I logged in just to say that this is a great question. This is one of those things where long-form HN threads come in really handy.
> I’m worried that being involved with shorter term projects means I won’t get the chance to gain _deep_ expertise in any one thing, which might hurt my future job prospects
This is a reasonable thing to worry about, but don't overlook the opportunity to gain broad experience across the entire product lifecycle - not just with multiple technologies, but also working with customers, developing requirements and designing products to meet them, ops and maintenance, tier 2/escalation support, and all manner of other aspects of working with software that a lot of engineers in my experience tend to overlook.
You won't come out of it with exhaustive knowledge in one specific stack, sure. But you very well can come out of it a much more well-rounded engineer, and that can easily do more for your ability to contribute - and thus your prospects - than any single deep, narrow specialization ever will.
I started my career in the kind of role you're considering now, only in those days the tech was all Perl 5 and PHP 5. I was good at them then, but have barely so much as touched either language in about a decade at this point. No tech stack is forever; what's been of enduring value has almost entirely been the kind of broad experience I describe. Not all that many engineers in my experience can and will also sit down with clients to help figure out what they actually need, and then prioritize, plan, schedule, and lead the work to build it. Not all that many engineers can and will volunteer to handle customer support escalations, and be able to do so effectively, in order to get insight into where the pain points are and how to solve them. A job like the one you're considering is a great opportunity to learn those things by doing them; I don't know of any better.
Sure, if you ultimately want to take tickets and work tickets somewhere in the bowels of a FAANG, stuff like that probably won't be all that useful. If you want to start your own company, I think a job like this will be of immense value to you. Ultimately, of course it's up to you and what you want to get out of your next role - I hope I've been able to provide a decent sense of what this kind of role can give you.
This is a reasonable thing to worry about, but don't overlook the opportunity to gain broad experience across the entire product lifecycle - not just with multiple technologies, but also working with customers, developing requirements and designing products to meet them, ops and maintenance, tier 2/escalation support, and all manner of other aspects of working with software that a lot of engineers in my experience tend to overlook.
You won't come out of it with exhaustive knowledge in one specific stack, sure. But you very well can come out of it a much more well-rounded engineer, and that can easily do more for your ability to contribute - and thus your prospects - than any single deep, narrow specialization ever will.
I started my career in the kind of role you're considering now, only in those days the tech was all Perl 5 and PHP 5. I was good at them then, but have barely so much as touched either language in about a decade at this point. No tech stack is forever; what's been of enduring value has almost entirely been the kind of broad experience I describe. Not all that many engineers in my experience can and will also sit down with clients to help figure out what they actually need, and then prioritize, plan, schedule, and lead the work to build it. Not all that many engineers can and will volunteer to handle customer support escalations, and be able to do so effectively, in order to get insight into where the pain points are and how to solve them. A job like the one you're considering is a great opportunity to learn those things by doing them; I don't know of any better.
Sure, if you ultimately want to take tickets and work tickets somewhere in the bowels of a FAANG, stuff like that probably won't be all that useful. If you want to start your own company, I think a job like this will be of immense value to you. Ultimately, of course it's up to you and what you want to get out of your next role - I hope I've been able to provide a decent sense of what this kind of role can give you.
One thing to think about, it terms of deep experience, is that in a product role you'll often only be using part of a stack. If, for instance, you are making a CMS you won't touch the numerical parts of the language. In consulting you may get to choose between using more of what's available in a stack or branching out to other technologies.
The entrepreneur thing is true too, I went from an employee to running my own operation and nothing was really surprising. I'm not sure how many other jobs you can make that transition so easily.
The entrepreneur thing is true too, I went from an employee to running my own operation and nothing was really surprising. I'm not sure how many other jobs you can make that transition so easily.
Even if you just go self-employed as a consultant, it's a great springboard. A few years at a good small firm can give you everything you need except a decent accountant.
I've run both types of orgs. Here's the one thing few ppl on the consulting side get: the primary product of a consulting org is its people. Thus, there (should) be an emphasis on growing the skills of the team, both soft and hard. The software product is secondary (unless it's sold together with the consulting hours). That means people skills and giving these people, more skills is priority #1. That can be lots of fun for some people, less so for others.
I have done both and I currently work in a consulting company like the one you describe, but in product as opposed to engineering. Like all jobs it has pros and cons. The big advantages to consulting are the opportunities to work on a lot of different projects and in different fields. You'll get much more exposure than working for a product company where you'll have a singular focus for years. I've been in consulting for two and a half years and have worked with insurance, automotive, grocery, and retail marketplace companies doing web, mobile, b2b and b2c products. That's a lot of variety for that time period. And as others have mentioned your network grows much faster as every new project means a whole new set of people to meet. Consulting can be a great way to 'trial' certain sectors without taking a dedicated job there. I now know much more about where I don't want to work in the future as much as I do because of that experience.
As for disadvantages there are several. Your main concern is the first one and it is real. You can only spend so much time on a project, and that means you may never get to take it to the depth and maturity that you want. In most cases you're there to start something or fix something. Once it is started the client will take over, and if it is fixed, it's fixed. So if you want to go deep into a subject, I would pick a different path. It can be a bit sad to put your heart into something for a year and then not be able to see it all the way through. The other disadvantage is around the politics of the kind of work. This is a three party system - there are your goals, the goals of your company and it's consulting business, and the goals of the client. Those don't always align and it can be complicated to navigate. You can also find yourself in situations that are uncomfortable - like dropped into a project timeline that you weren't part of estimating. It can be a bit sink or swim in my experience. The most important factor in being successful is communication / stakeholder management and making sure expectations are clear to everyone.
It's given me a lot of experience quickly, but it's a real challenge. It is fast-paced and intense and thus it is not for everyone - but if you're thinking about it it is probably worth doing for a few years to get the experience and see how you like it.
As for disadvantages there are several. Your main concern is the first one and it is real. You can only spend so much time on a project, and that means you may never get to take it to the depth and maturity that you want. In most cases you're there to start something or fix something. Once it is started the client will take over, and if it is fixed, it's fixed. So if you want to go deep into a subject, I would pick a different path. It can be a bit sad to put your heart into something for a year and then not be able to see it all the way through. The other disadvantage is around the politics of the kind of work. This is a three party system - there are your goals, the goals of your company and it's consulting business, and the goals of the client. Those don't always align and it can be complicated to navigate. You can also find yourself in situations that are uncomfortable - like dropped into a project timeline that you weren't part of estimating. It can be a bit sink or swim in my experience. The most important factor in being successful is communication / stakeholder management and making sure expectations are clear to everyone.
It's given me a lot of experience quickly, but it's a real challenge. It is fast-paced and intense and thus it is not for everyone - but if you're thinking about it it is probably worth doing for a few years to get the experience and see how you like it.
Writing lots of boilerplate is an opportunity to build new libraries, frameworks, code generators, and other tooling; use that as something extra you can share with your colleagues and sell to clients, or use it to build an open source portfolio. Some companies might let you do it under your own name, others will want you to use their Github org.
If you find a technology you really like that's popular with clients, it may be that you get to use that with every client and then you can gain deep expertise in that. Don't be too picky here, this is an opportunity to get access to a lot of customers to find out what technology is really in demand. Contract-to-hire is also a valid thing that happens if you find a client with full-time positions open that you really like working for; you may have to negotiate with the consulting org for a finders' fee. Some orgs are not okay with this though, so I would only suggest it if you know it will work, or if you have a backup plan for another job in case it fails.
Extra advice I can give is that the relationships involved when doing consulting is pretty different; in my experience, unless the clients are all big IT firms, you likely won't have strong engineering management guiding any projects, and the client may not even be able to help you out with technical issues at all. It's on your team as technical experts to get in, figure out what is going on, and then get out. There are a number of ways to deal with this but the number one rule is: cover your ass with clients! I've seen lots of projects go south because of bad communication and failure to manage customer expectations.
If you find a technology you really like that's popular with clients, it may be that you get to use that with every client and then you can gain deep expertise in that. Don't be too picky here, this is an opportunity to get access to a lot of customers to find out what technology is really in demand. Contract-to-hire is also a valid thing that happens if you find a client with full-time positions open that you really like working for; you may have to negotiate with the consulting org for a finders' fee. Some orgs are not okay with this though, so I would only suggest it if you know it will work, or if you have a backup plan for another job in case it fails.
Extra advice I can give is that the relationships involved when doing consulting is pretty different; in my experience, unless the clients are all big IT firms, you likely won't have strong engineering management guiding any projects, and the client may not even be able to help you out with technical issues at all. It's on your team as technical experts to get in, figure out what is going on, and then get out. There are a number of ways to deal with this but the number one rule is: cover your ass with clients! I've seen lots of projects go south because of bad communication and failure to manage customer expectations.
I hadn't thought about the opportunity to build libraries, frameworks, etc. Thanks!
Ask about their typical engagement model. Usually it's either Time and Materials or fixed price. Fixed price contracts can sometimes be stressful and encourage hurrying just to meet the requirements, whereas T&M projects can allow you more time to innovate or propose better solutions.
Also find out what people do when they are on the bench (unstaffed). Sometimes you're allowed to work in your own projects on full pay and sometimes there's an internal backlog.
Also find out what people do when they are on the bench (unstaffed). Sometimes you're allowed to work in your own projects on full pay and sometimes there's an internal backlog.
I have done both and can say: IF your product org pays you very well and you like the people you work with stay there. This also assumes you have freedom to do your own R&D projects.
If any of the above is not true go the consulting route with the goal to have your own clients. Its exciting, you pick the people you work with and the work you accept. At the time of this writing there is plenty of software work for consultants who are interested in long term B2B companies. You dont need many. We are a team of 4 and have about 5 large long term client. We are also building a product on the side (and this is the real icing on the cake)
When I made the change I was worried about healthcare. Using the healthcare.gov market place I ended up paying about the same for slightly better (local) insurance.
If any of the above is not true go the consulting route with the goal to have your own clients. Its exciting, you pick the people you work with and the work you accept. At the time of this writing there is plenty of software work for consultants who are interested in long term B2B companies. You dont need many. We are a team of 4 and have about 5 large long term client. We are also building a product on the side (and this is the real icing on the cake)
When I made the change I was worried about healthcare. Using the healthcare.gov market place I ended up paying about the same for slightly better (local) insurance.
People tend to bring in consultants when they are not healthy and well functioning. That can mean you often end up in clients with a lot of dysfunction. That can be frustrating if you can't help them, but extra rewarding when you can.
Having been in a product org, a consulting org and having done consulting alone, I think:
- The type of work you do is largely the same across all orgs - unless you're a specialist in some advanced field nobody else can do or you can convince someone in power that you know how to do the occasional cool project
- Both can have long useless meetings. Product orgs' meetings will be crap about how the company is awesome and will make zillions or crap about process-but-not-process-cause-we're-agile; consulting orgs' meetings will be all about having 5 muted engineers on reddit while the client comes up with 3 new requirements per minute
- Product orgs can get by doing way less work, if people lazying around and doing the bare minimum or nothing at all upset you, avoid product focused orgs
- I think you can divide consulting orgs roughly in two groups:
- The type of work you do is largely the same across all orgs - unless you're a specialist in some advanced field nobody else can do or you can convince someone in power that you know how to do the occasional cool project
- Both can have long useless meetings. Product orgs' meetings will be crap about how the company is awesome and will make zillions or crap about process-but-not-process-cause-we're-agile; consulting orgs' meetings will be all about having 5 muted engineers on reddit while the client comes up with 3 new requirements per minute
- Product orgs can get by doing way less work, if people lazying around and doing the bare minimum or nothing at all upset you, avoid product focused orgs
- I think you can divide consulting orgs roughly in two groups:
- Doing client work with in-house project management: a nightmare of people trying to squeeze more work out of you until you die
- Giving engineers to organisations: largely like working in a product org
- Consulting orgs have the advantage of rotating clients more often, which means you'll have to deal with horrible people for a shorter amount of time (unless the horrible people are inside your consulting org). In product orgs you'll have to deal with them until they leave for somewhere else
- Consulting on your own is definitely more work & more money but, more importantly, reduces the risk of running into horrible peopleI was the CTO of an R&D consulting company in Poland, and parent is mostly spot on. I disagree, however, about the way they describe in-house management vs giving engineers to the customer.
The only thing of real value in a software agency is the team. If your programmers get pissed off and move to another company, you are going to have to spend money to hire and onboard someone, and leave money on the table (you need engineers to fulfill your contracts). So, unless an agency's management totally sucks, they will put a lot of effort to keep their personnel happy. This means, for example, having decent project management (and that's kinda natural, as you tend to do a lot of projects). Second, working the engineers to the bone is very much _not_ in the interest of the agency – if you work super hard and burn out, the customer gets all the upside (project delivered), and the agency gets all the downside. So, a decent agency will be good at pushing back when the client tries to abuse their employees.
This is one of the reasons why we strongly preferred managing the work ourselves, and why we stuck to hourly billing (which is super annoying to most of the time, but it aligns the incentives in that regard slightly better than if you bill by the day).
If the agency is doing staff augmentation, the developers are mostly left to fend for themselves. This is problematic, as it makes the devs to (justly) wonder what is the agency doing to deserve their margins.
(Of course, your mileage may vary. Ours was a small shop with very senior people, and we were doing very interesting projects. Working at a huge Indian outsourcing company is going to be a very different experience.)
The only thing of real value in a software agency is the team. If your programmers get pissed off and move to another company, you are going to have to spend money to hire and onboard someone, and leave money on the table (you need engineers to fulfill your contracts). So, unless an agency's management totally sucks, they will put a lot of effort to keep their personnel happy. This means, for example, having decent project management (and that's kinda natural, as you tend to do a lot of projects). Second, working the engineers to the bone is very much _not_ in the interest of the agency – if you work super hard and burn out, the customer gets all the upside (project delivered), and the agency gets all the downside. So, a decent agency will be good at pushing back when the client tries to abuse their employees.
This is one of the reasons why we strongly preferred managing the work ourselves, and why we stuck to hourly billing (which is super annoying to most of the time, but it aligns the incentives in that regard slightly better than if you bill by the day).
If the agency is doing staff augmentation, the developers are mostly left to fend for themselves. This is problematic, as it makes the devs to (justly) wonder what is the agency doing to deserve their margins.
(Of course, your mileage may vary. Ours was a small shop with very senior people, and we were doing very interesting projects. Working at a huge Indian outsourcing company is going to be a very different experience.)
While this makes sense in theory in my experience these companies end up relying on new grads for a lot of the work until they get wise and leave or burn out. For some reason they treat attrition as a cost of doing business, even though a lot of knowledge leaves when people do.
I have observed that some global consultancies throw lots of low performing grads at projects and bill like crazy. Typically the client pays around 8-12x the employees' rate. I am not exaggerating. I have been involved in the negotiations and bidding process.
Is there some prerequisites to get into consulting alone, e.g. having worked in a consulting org before ? What kind of profile are people expecting ?
I have a pretty good tech generalist engineer profile, and I'm considering doing that while working part time on a personal project.
The biggest requirement of solo consulting is being able to get clients on your own. The quality of your clients will directly result in how successful you are. There are several approaches to gaining new clients, but the best ones come from your professional network and your reputation.
Solo consulting is more work than many other positions you can find. If you want to work part time on a personal project you are better off finding a product org with flexible scheduling then solo consulting.
Solo consulting is more work than many other positions you can find. If you want to work part time on a personal project you are better off finding a product org with flexible scheduling then solo consulting.
A lot of it is recommendations, networking, knowing the right people.
At the beginning I was very active in the startup community and that meant several small contracts with startups / small companies.
With my network growing (and ageing) with me, I started having contacts in bigger companies, which landed some contracts with FTSE 100 companies.
That translates to more experience which helps you land similar roles.
At the beginning I was very active in the startup community and that meant several small contracts with startups / small companies.
With my network growing (and ageing) with me, I started having contacts in bigger companies, which landed some contracts with FTSE 100 companies.
That translates to more experience which helps you land similar roles.
This is all very accurate
I don't mean what I say negatively, but in consulting it's important to remember that contracts are only as good as you can litigate and you can be fired by the client at any time.
By that I mean, you need to bring your A-game every day and essentially always be selling to the client (and always billing). There's no room for you being in a rut or having off days consulting and at a client site. Take your sick days rarely. That's great for some people but doesn't work for everyone.
By that I mean, you need to bring your A-game every day and essentially always be selling to the client (and always billing). There's no room for you being in a rut or having off days consulting and at a client site. Take your sick days rarely. That's great for some people but doesn't work for everyone.
As a software engineering consultant, be prepared for small/quick stints, some of them as short as 2 weeks.
You will not get time to analyse technical details deeply enough before presenting to clients. Focus on code quality is seldom lesser. Be prepared for a lot more talking than a product org. Be prepared for a lot more work and constant pressure of timelines.
You will not get time to analyse technical details deeply enough before presenting to clients. Focus on code quality is seldom lesser. Be prepared for a lot more talking than a product org. Be prepared for a lot more work and constant pressure of timelines.
I've worked as permanent staff for ISV product companies and banks. I've also worked for a consulting firm on banking projects, and as a contractor at banks and ISV product companies. I could say a lot about the differences [1], but I'll confine myself to one point here: the interests of client and consultant are never truly aligned. Why? Because the consultancy wants maximum duration and headcount from any project to maximise billing. The client wants the project done, and the consultants gone. Yes, I'm assuming time and material billing here, not fixed price. That misalignment means that the consulting org can never really be honest with the client about the true state of the project. I've seen this play out at a cost of tens of millions at first hand. And we've all seen it in industry news, often with large govt contracts.
[1] https://etrading.wordpress.com/2006/05/31/permie-vs-consulta...
[1] https://etrading.wordpress.com/2006/05/31/permie-vs-consulta...
I worked in some of the top digital agencies for a long time. It is marked by fast pace and high levels of uncertainty. Depending on the quality of your team this is either an adrenaline rush or a meat grinder. Frequently flip flopping between the two. But you'll never be bored.
The agency landscape is pretty broad. Some shops are very technical, some are design lead. Some can dump an army of bodies on a project and some deploy lean tiger teams. My experience was doing a lot of strategic engagements. I got to do architecture and real planning and quality control. Sometimes it was fire and forget popup projects. Rarely if ever did we own any support role which was pretty great. Got to flip between web, mobile and even experiential work. Very frequently thrown into stuff with no training which is always exciting/terrifying depending on your personality.
The agency landscape is pretty broad. Some shops are very technical, some are design lead. Some can dump an army of bodies on a project and some deploy lean tiger teams. My experience was doing a lot of strategic engagements. I got to do architecture and real planning and quality control. Sometimes it was fire and forget popup projects. Rarely if ever did we own any support role which was pretty great. Got to flip between web, mobile and even experiential work. Very frequently thrown into stuff with no training which is always exciting/terrifying depending on your personality.
Product companies ideally optimise for outcome (growth/delight/adoption metrics).
Consulting companies tend to optimise for output (delivering on time, code quality, reported bug counts, number of stories, sprint velocity etc.)
A full time product engineer has more skin in the game and freedom to work across the stack while consultants might be restricted to non-prod environments and therefore limited access to infra/devops work and prod support/troubleshooting. YMMV.
There is a huge learning in supporting what you build and not getting that experience can be a limitation in consulting.
However consulting offers you the opportunity to work across domains, tech stacks, work with new people, travel etc every 1-2 years whereas in product companies a commitment of 2-3+ years is desirable.
Finally, it boils down to quality of the group of people you are going to work with. A consulting firm with higher density of talent would be more interesting than a mediocre product team.
Consulting companies tend to optimise for output (delivering on time, code quality, reported bug counts, number of stories, sprint velocity etc.)
A full time product engineer has more skin in the game and freedom to work across the stack while consultants might be restricted to non-prod environments and therefore limited access to infra/devops work and prod support/troubleshooting. YMMV.
There is a huge learning in supporting what you build and not getting that experience can be a limitation in consulting.
However consulting offers you the opportunity to work across domains, tech stacks, work with new people, travel etc every 1-2 years whereas in product companies a commitment of 2-3+ years is desirable.
Finally, it boils down to quality of the group of people you are going to work with. A consulting firm with higher density of talent would be more interesting than a mediocre product team.
I've made this transition from product R&D to product design consulting. As far as your concerns about variety, it probably depends on what clients/projects your sales team is bringing in. As far as depth, again, this probably depends on the project - my experience was that I was getting much more depth and breadth, typically working on green development and having to figure out the hard stuff up front (like, can this actually be done?) Typically, I'd work on the first 90%, and the client would do the maintenance/sustaining. On the plus side, if you have a client or project that you dislike, you only have to hang on for the term of the contract - 6 mos / year for light at the end of the tunnel. In terms of concerns about boilerplate, my recommendation would be to turn the boilerplate into a library, and sell your customer licenses - you will be more competitive this way, and your margins will be better - it's a win-win (have had success with this). One thing to remember is that in the product company, everyone is on the same team, and you work together. With a client, each one is different, and the relationship varies, but typically boils down to "I paid you a lot of money, where's my stuff?" Be very careful what you commit to with customers, and that anything you do commit to is spelled out clearly and fully in the contract. That was the first important thing I learned. Good luck.
I do technical consulting for a fairly niche industry. Here is what I’ve found in no particular order:
1) when times get bad you will be “expensive” and among the first to be let go.
2) you have to be expensive enough to afford bench time in between gigs. When the economy is good I plan for 85% utilization. Covid had me at 50%, until very recently.
3) if there are multiple consultants and or consulting firms be prepared for political games where each firm tries to position themselves to take other spots in the organization. It will range from limited access to information to outright bus throwing. The best way to stop this is highly detailed accounting of how you spend your day and what roadblocks you face. Send this to your supervisor daily via email. It’s worth the 30 minutes and has helped me on numerous occasions.
4) on a similar token don’t be afraid to mention your success. It doesn’t have to be a brag but if you build some take the credit before someone else tries to.
1) when times get bad you will be “expensive” and among the first to be let go.
2) you have to be expensive enough to afford bench time in between gigs. When the economy is good I plan for 85% utilization. Covid had me at 50%, until very recently.
3) if there are multiple consultants and or consulting firms be prepared for political games where each firm tries to position themselves to take other spots in the organization. It will range from limited access to information to outright bus throwing. The best way to stop this is highly detailed accounting of how you spend your day and what roadblocks you face. Send this to your supervisor daily via email. It’s worth the 30 minutes and has helped me on numerous occasions.
4) on a similar token don’t be afraid to mention your success. It doesn’t have to be a brag but if you build some take the credit before someone else tries to.
My take from experience and from what I've seen with friends:
- Consulting is great for people with good people skills, but it can turn into hell if you haven't them.
- It's very easy for experienced workers in some shops to take advantage of the "new meat", and basically shove you their work. Be on the look for that situation. If it happens run as fast as you can.
- Find out who are the top performers, get as close as you can. Some of them will just be political hacks, but others are fountains of experience, and learning from them will provide you with invaluable insight into their fields.
- Be ready to ship crappy products. Consultancy is about doing things fast and keeping costs down. Nobody expects perfection, although you'll hear business speak like "excellence" repeated constantly. Your bosses know it, your clients know it. If you are the kind of person that has trouble living with that (i.e. perfectionist), you'll be way happier in product orgs.
- Insist on meeting the client. Engineering consultancy is 20% about making the thing, 80% about understanding the clients needs and managing their expectations. All the big failures I've seen in consulting come from having middleman between the guy building and the guy talking to the client. You don't need to be there all the time, but enough to not be playing telephone with others about what the client wants.
- Consulting is great for people with good people skills, but it can turn into hell if you haven't them.
- It's very easy for experienced workers in some shops to take advantage of the "new meat", and basically shove you their work. Be on the look for that situation. If it happens run as fast as you can.
- Find out who are the top performers, get as close as you can. Some of them will just be political hacks, but others are fountains of experience, and learning from them will provide you with invaluable insight into their fields.
- Be ready to ship crappy products. Consultancy is about doing things fast and keeping costs down. Nobody expects perfection, although you'll hear business speak like "excellence" repeated constantly. Your bosses know it, your clients know it. If you are the kind of person that has trouble living with that (i.e. perfectionist), you'll be way happier in product orgs.
- Insist on meeting the client. Engineering consultancy is 20% about making the thing, 80% about understanding the clients needs and managing their expectations. All the big failures I've seen in consulting come from having middleman between the guy building and the guy talking to the client. You don't need to be there all the time, but enough to not be playing telephone with others about what the client wants.
Totally agree about the perfectionism. I started out in consulting and it was a great way to work across a bunch of industries and technologies and to get exposure to different ways of doing things. The reason I left was I felt like my skills around support, testing, and architecture were atrophying because those just aren’t priorities on short, hourly engagements.
Since starting at a product company I’ve been able to build deep expertise, but I still rely on those consulting skills when talking with product people, QA, or if we need somebody to quickly ramp up on 3rd party libraries or understand something outside the scope of the team.
This all only applies to small, short term engagements though. Multiyear engagements are their own beast and I always stayed far away. Consulting politics is another layer of hell that most people will want to stay away from.
Since starting at a product company I’ve been able to build deep expertise, but I still rely on those consulting skills when talking with product people, QA, or if we need somebody to quickly ramp up on 3rd party libraries or understand something outside the scope of the team.
This all only applies to small, short term engagements though. Multiyear engagements are their own beast and I always stayed far away. Consulting politics is another layer of hell that most people will want to stay away from.
>All the big failures I've seen in consulting come from having middleman between the guy building and the guy talking to the client.
I've worked in different sized consulting organizations. The bigger the consulting project, the more middlemen on both sides. Large consultancies focus on large projects at large customers. Large customers have a bunch of middlemen talking to the middlemen at the consultancy. What is sold, what is required, what is actually done...it's like a big maze...
If all you care about is a paycheck and checking some "delivered" boxes, these large consultancies are fine. If you are the type of person who gets upset because you feel like what you are asked to do can't possibly be right, try to find a smaller consulting org where customer success actually means something.
>If you are the kind of person that has trouble living with that (i.e. perfectionist), you'll be way happier in product orgs.
100% Agree. Note that smaller consulting orgs can be more focused on not delivering crap, but a change in profitability or strategy can change that quickly.
I've worked in different sized consulting organizations. The bigger the consulting project, the more middlemen on both sides. Large consultancies focus on large projects at large customers. Large customers have a bunch of middlemen talking to the middlemen at the consultancy. What is sold, what is required, what is actually done...it's like a big maze...
If all you care about is a paycheck and checking some "delivered" boxes, these large consultancies are fine. If you are the type of person who gets upset because you feel like what you are asked to do can't possibly be right, try to find a smaller consulting org where customer success actually means something.
>If you are the kind of person that has trouble living with that (i.e. perfectionist), you'll be way happier in product orgs.
100% Agree. Note that smaller consulting orgs can be more focused on not delivering crap, but a change in profitability or strategy can change that quickly.
Pretty much my experience as well. I suffered quite a lot from "Be ready to ship crappy products" when the projects were short (it happened quite a lot when I was doing AWS consulting).
I will also add that companies using consultants can be divided in two distinct groups:
1) The companies who know where they are doing and they are using consultants as extra hands/expertise. 2) The companies who expects consultants to (magically) fix their deep problems just because "we pay".
I have worked for both and 1) is definitely more enjoyable (as you can imagne!).
I will also add that companies using consultants can be divided in two distinct groups:
1) The companies who know where they are doing and they are using consultants as extra hands/expertise. 2) The companies who expects consultants to (magically) fix their deep problems just because "we pay".
I have worked for both and 1) is definitely more enjoyable (as you can imagne!).
I think that final point is one of the most important components to being successful in contract based consulting. By the time the contract that we're doing lands on my desk its a game of telephone thats prob been going on for 2 years. Clearly understanding the client needs and priorities is the only path to successfully growing a program I've found.
Brilliant advice, favorited. Thanks for writing that.
These are great things to keep in mind. Thank you.
Truly, an excellent summary.
Like others who have commented, I've spent significant time (>10y) in both sorts of environments, and am currently at a product company. Like you might expect, there are pros and cons to both types of employment.
For consulting, it's key to remember that your experience will be almost completely driven by the specific projects and teams you're on. Two people can go to work for the same consultancy on the same day, wind up on different projects, and have totally different experiences and outcomes. (This is particularly true at larger, more management oriented consultancies that might not be able to put you into technical roles at all. Even though I came in with years of professional engineering experience, I spent my first year at a big five consultancy building UI mocks in Excel, and watching the client's Java team make dubious design choices. After some growing pains, I was able to navigate my way over into a release management role where I was able to have a more positive impact.)
This is also true for one person working over time for the same consultancy. A great experience on a great project can turn into a terrible experience almost literally overnight with the wrong change in staffing. The upside is the opposite - if you can outlast the rough spots, you can usually find a way into a better situation, thanks to the more dynamic staffing model. It's easier to change teams within a consultancy (where it's expected to change) than within a product company (where the company has an incentive to keep you staffed where it knows you perform well and have experience). I have seen people leave product companies because they can't get away from maintaining the thing the built. (Ironically, though, I left my first consultancy job in part because I couldn't get away from a particular project with the political pull of a small black hole.)
For the technical side of the work, it again varies from project to project, but your involvement in a given consultancy project will on average be shorter than your involvement in a given product project. This makes it much harder to implement anything resembling a long term vision - there just isn't enough time. It can also make it hard to understand the full impact of the decisions you were able to make while you were there. If you're staffed for a build out, it's very plausible that you see the system go live, immediately get staffed elsewhere, and wind up with no real direct perspective on how well your design/code operates in production. Conversely, for greenfield build outs, consultants are often very much involved in project startup, so spend a lot of time setting up build/ci/cd processes.
As negative as some of that might sound, I did and continue to highly recommend engineers spend a significant amount of time doing consulting work, even if product work is the long term goal. The biggest positive about consultancy is that it can put you directly in front of customers and directly at the point of trying to solve 'real world' problems with software systems. Learning to develop customer facing skills and understanding what's truly important (and not important) to people in the 'real world' is hugely beneficial. Along those lines, I've been doing product work for the last few years, but there's not a day that goes by where I'm not thinking how I'd react to our product if I was in that other role, as a consultant, trying to use it to solve somebody's business problem on a too-short schedule with a too-small budget.
For consulting, it's key to remember that your experience will be almost completely driven by the specific projects and teams you're on. Two people can go to work for the same consultancy on the same day, wind up on different projects, and have totally different experiences and outcomes. (This is particularly true at larger, more management oriented consultancies that might not be able to put you into technical roles at all. Even though I came in with years of professional engineering experience, I spent my first year at a big five consultancy building UI mocks in Excel, and watching the client's Java team make dubious design choices. After some growing pains, I was able to navigate my way over into a release management role where I was able to have a more positive impact.)
This is also true for one person working over time for the same consultancy. A great experience on a great project can turn into a terrible experience almost literally overnight with the wrong change in staffing. The upside is the opposite - if you can outlast the rough spots, you can usually find a way into a better situation, thanks to the more dynamic staffing model. It's easier to change teams within a consultancy (where it's expected to change) than within a product company (where the company has an incentive to keep you staffed where it knows you perform well and have experience). I have seen people leave product companies because they can't get away from maintaining the thing the built. (Ironically, though, I left my first consultancy job in part because I couldn't get away from a particular project with the political pull of a small black hole.)
For the technical side of the work, it again varies from project to project, but your involvement in a given consultancy project will on average be shorter than your involvement in a given product project. This makes it much harder to implement anything resembling a long term vision - there just isn't enough time. It can also make it hard to understand the full impact of the decisions you were able to make while you were there. If you're staffed for a build out, it's very plausible that you see the system go live, immediately get staffed elsewhere, and wind up with no real direct perspective on how well your design/code operates in production. Conversely, for greenfield build outs, consultants are often very much involved in project startup, so spend a lot of time setting up build/ci/cd processes.
As negative as some of that might sound, I did and continue to highly recommend engineers spend a significant amount of time doing consulting work, even if product work is the long term goal. The biggest positive about consultancy is that it can put you directly in front of customers and directly at the point of trying to solve 'real world' problems with software systems. Learning to develop customer facing skills and understanding what's truly important (and not important) to people in the 'real world' is hugely beneficial. Along those lines, I've been doing product work for the last few years, but there's not a day that goes by where I'm not thinking how I'd react to our product if I was in that other role, as a consultant, trying to use it to solve somebody's business problem on a too-short schedule with a too-small budget.
Second @xondono.
I have made that change recently and it's hard for me to let go the stupidities and the crappy job we're basically forced to do "because best practices, unit tests, (you name it) is not priority".
Money can be better, tho.
I have made that change recently and it's hard for me to let go the stupidities and the crappy job we're basically forced to do "because best practices, unit tests, (you name it) is not priority".
Money can be better, tho.
The Secrets of Consulting[1][2] sounds like a book you might appreciate in your current situation.
[1] https://www.amazon.com/Secrets-Consulting-Giving-Getting-Suc...
[2] https://www.goodreads.com/book/show/566213.The_Secrets_of_Co...
[1] https://www.amazon.com/Secrets-Consulting-Giving-Getting-Suc...
[2] https://www.goodreads.com/book/show/566213.The_Secrets_of_Co...
Also
Managing the Professional Service Firm
By David Maister
Helps understand how consulting type firms as a whole work
> A variety of projects sounds like it could be engaging, but on the other hand, maybe I’ll get bored writing the same boilerplate over and over?
I've worked in a couple machine integrator shops (kind of a mix of product and consultancy, basically building products that the OEM can't build themselves) over the past decade. There have been lots of 200-800 hour projects from lots of customers. My takeaway has been that every project that's valuable enough to contract someone to do has at least one really interesting problem to solve. Every project also has some boilerplate to make it work, I don't think anyone gets out of that. Even tenured research professors have to write grant proposals.
> But I’m worried that being involved with shorter term projects means I won’t get the chance to gain _deep_ expertise in any one thing, which might hurt my future job prospects?
Shorter term projects mean that you're gaining adequate expertise to be productive in dozens of things. If asked "We're using the X stack to build a product that does foo, are you capable of working here and helping us?", and you can say "I've used the X stack to build something that does bar, and I did a project that mostly automated foo using stack Y, I'm confident I could do it with stack X", you're clearly ready to hit the ground running. If you can say that you've never used stack X or done foo, but have learned V, W, Y, and Z, and have not done foo but have been successful with similar projects like bar, baz, and qux, well, HR drones and hiring managers aren't always the brightest bunch but they're often capable of a small leap of faith like that. You're in a much better position than someone who's only ever used stack W to build baz, and doesn't know anything else.
Also, it's really hard to gain deep expertise with one thing if you're only building a small number of products. Early architectural decisions often mean that you're stuck with the first thing that worked, while on a ton of short projects you can figure out what does work and what doesn't. For example, as a controls engineer, I've had the opportunity to try at least a dozen ways of representing a machine operation or actuator. I've built systems that are inadequate and had to be extended with cludgy add-ons, that are too rigid and had to be forked into subtly different varieties, that are too flexible and bulky, and finally settled on a representation that really works well. It's kind of like being given the opportunity to do a complete rewrite of the software, except you're not writing quite the same software each time...highly risky at a product org, but at a consulting org you're basically expected to do that.
I've worked in a couple machine integrator shops (kind of a mix of product and consultancy, basically building products that the OEM can't build themselves) over the past decade. There have been lots of 200-800 hour projects from lots of customers. My takeaway has been that every project that's valuable enough to contract someone to do has at least one really interesting problem to solve. Every project also has some boilerplate to make it work, I don't think anyone gets out of that. Even tenured research professors have to write grant proposals.
> But I’m worried that being involved with shorter term projects means I won’t get the chance to gain _deep_ expertise in any one thing, which might hurt my future job prospects?
Shorter term projects mean that you're gaining adequate expertise to be productive in dozens of things. If asked "We're using the X stack to build a product that does foo, are you capable of working here and helping us?", and you can say "I've used the X stack to build something that does bar, and I did a project that mostly automated foo using stack Y, I'm confident I could do it with stack X", you're clearly ready to hit the ground running. If you can say that you've never used stack X or done foo, but have learned V, W, Y, and Z, and have not done foo but have been successful with similar projects like bar, baz, and qux, well, HR drones and hiring managers aren't always the brightest bunch but they're often capable of a small leap of faith like that. You're in a much better position than someone who's only ever used stack W to build baz, and doesn't know anything else.
Also, it's really hard to gain deep expertise with one thing if you're only building a small number of products. Early architectural decisions often mean that you're stuck with the first thing that worked, while on a ton of short projects you can figure out what does work and what doesn't. For example, as a controls engineer, I've had the opportunity to try at least a dozen ways of representing a machine operation or actuator. I've built systems that are inadequate and had to be extended with cludgy add-ons, that are too rigid and had to be forked into subtly different varieties, that are too flexible and bulky, and finally settled on a representation that really works well. It's kind of like being given the opportunity to do a complete rewrite of the software, except you're not writing quite the same software each time...highly risky at a product org, but at a consulting org you're basically expected to do that.
I started out in consulting and at one point decided that I would no longer accept those sorts of jobs, for primarily one reason: at consulting gigs, I never[1] got to stick around long enough to experience the long-term consequences of my choices.
I started out consulting because I thought it would be a great way to learn a wide variety of things but it turns in order to actually, really, truly learn something, you need to stick around for a long time to see the long-term, second order consequences unfold.
Instead, I've now been in a few smaller product orgs, where I get many of the benefits of consulting (high pace, many hats, good compensation, lots of learning all around, wide array of technologies) except I also get to witness how everything ends up and what the fruits of my labour are.
Something else that I hadn't thought about until now is that in these smaller product orgs I also get the opportunity to build the culture and organisation from scratch – that was rarely something offered to me at the consulting gigs.
[1]: Of course, I shoudn't say never. Maybe once or twice were there opportunities to stick around for a long time, but they were rare in comparison.
I started out consulting because I thought it would be a great way to learn a wide variety of things but it turns in order to actually, really, truly learn something, you need to stick around for a long time to see the long-term, second order consequences unfold.
Instead, I've now been in a few smaller product orgs, where I get many of the benefits of consulting (high pace, many hats, good compensation, lots of learning all around, wide array of technologies) except I also get to witness how everything ends up and what the fruits of my labour are.
Something else that I hadn't thought about until now is that in these smaller product orgs I also get the opportunity to build the culture and organisation from scratch – that was rarely something offered to me at the consulting gigs.
[1]: Of course, I shoudn't say never. Maybe once or twice were there opportunities to stick around for a long time, but they were rare in comparison.
relying on device brand/model detection for design decisions makes no sense to me. Layout should be based on viewport dimensions.
An iPad can easily be larger than a desktop browser window.
As a person who moved from consulting to product and then back to consulting my take is
- product is long term , while consulting can be short or long term. There is no guarantees there.
- Product teams you have the freedom to chose and experiment, but in consulting you dont. Product has more number of innovations while consulting has very less or in my case negligible.
- Consulting pays you more but product gives you experience, knowledge and sometimes depending on the company pays you more.
- In life and career chose long term when possible and short term only when you are bored and need a quick change.
- Consultancy is all about customers and meetings. you need as some mentioned, lots of people skills. You can develop one , but it takes years of experience
- Personally I am moving back to product now from consultancy. You can always move and collect experience and make money. But always think long term and be obsessed about customer.
I may be wrong here but these are my personal opinions. Please take it with grain of salt
- product is long term , while consulting can be short or long term. There is no guarantees there.
- Product teams you have the freedom to chose and experiment, but in consulting you dont. Product has more number of innovations while consulting has very less or in my case negligible.
- Consulting pays you more but product gives you experience, knowledge and sometimes depending on the company pays you more.
- In life and career chose long term when possible and short term only when you are bored and need a quick change.
- Consultancy is all about customers and meetings. you need as some mentioned, lots of people skills. You can develop one , but it takes years of experience
- Personally I am moving back to product now from consultancy. You can always move and collect experience and make money. But always think long term and be obsessed about customer.
I may be wrong here but these are my personal opinions. Please take it with grain of salt
I made this transition recently, and felt compelled to write about it. https://erik.wiffin.com/posts/missing-manual-professionalism...
One of the things I noticed is that all of the "how to be a good developer" books/blogs/etc felt much more targeted at product orgs - there's a real lack of "advice" for people working at agencies. That being said, maybe I just don't know where to look, and someone in this thread will point me in the right direction.
One of the things I noticed is that all of the "how to be a good developer" books/blogs/etc felt much more targeted at product orgs - there's a real lack of "advice" for people working at agencies. That being said, maybe I just don't know where to look, and someone in this thread will point me in the right direction.
There is a great way to say "no": saying "yes, maybe later".
Consultancies/Contractors can be career boosters, because they have a rather high attrition rate, which allows you to grow into more advanced positions faster than in a product shop (e.g. Dev -> tech lead or software architect). You should insist to be hired with that perspective.
Unfortunately, consulting is a low-margin business, so expect to be laid off quickly if projects run dry. Time-Tracking is a huge pita in project organisations too.
I wanted to share a different perspective as a hiring manager that has worked at multiple FAANGs.
As you start looking to get into more mid/senior levels, the consulting work starts to hinder more than help. Typically when we are looking at candidates we want to see long term ownership of a product or project. This can include things like dealing with operational issues, shipping major versions, or leading large architectural changes. Most of these things are quite rare in the consulting case. Typically consultants don't have much ownership over the code or major decisions about the product, and that becomes increasingly limiting for the scope and ambiguity you are able to demonstrate.
This is of course purely anecdotal and not all consulting roles are like this, but it is a trend I have encountered.
I don't know what your long term career goals are or what stage of your career you are in, but in the off chance you may look to return to a product focused org at a higher level you should be aware of the challenges that can come from long stints in consulting.
As you start looking to get into more mid/senior levels, the consulting work starts to hinder more than help. Typically when we are looking at candidates we want to see long term ownership of a product or project. This can include things like dealing with operational issues, shipping major versions, or leading large architectural changes. Most of these things are quite rare in the consulting case. Typically consultants don't have much ownership over the code or major decisions about the product, and that becomes increasingly limiting for the scope and ambiguity you are able to demonstrate.
This is of course purely anecdotal and not all consulting roles are like this, but it is a trend I have encountered.
I don't know what your long term career goals are or what stage of your career you are in, but in the off chance you may look to return to a product focused org at a higher level you should be aware of the challenges that can come from long stints in consulting.
ABB: Always be billing. Consulting is a game of renting people out by the hour. You want to be on customer billable projects. Being on the bench, means you are costing the company money - eventually you will be let go.
Change is Good: It is ok for customers to change their mind. Just make sure it gets documented as a change request and the Lead consultant gets the cost approved.
Never use the word No with a customer: You can propose alternative, argue, cajole, etc. But don't say no. No is a word that can be used by the lead consultant - not by the engineering team
Change is Good: It is ok for customers to change their mind. Just make sure it gets documented as a change request and the Lead consultant gets the cost approved.
Never use the word No with a customer: You can propose alternative, argue, cajole, etc. But don't say no. No is a word that can be used by the lead consultant - not by the engineering team
I get frustrated trying to improve things both big and small. As a small example, our endpoints return a list of JSON objects, as well as the length of that list, as though we're passing C pointers or something. I was under the impression that Javascript could determine the length of a list without help, but apparently that's the way it's done and it's not really worth a confrontation with the client to change such a small thing. Bigger changes are, of course, even more difficult.
Even in the best circumstances there is a slight adversarial relationship with the clients, I think that is the source of a lot of problems.
Even in the best circumstances there is a slight adversarial relationship with the clients, I think that is the source of a lot of problems.
Returning the length can be helpful for partial JSON parsing - determining the response size without parsing the whole thing.
More commonly it's used for pagination, in which case it's a total count.
More commonly it's used for pagination, in which case it's a total count.
My advice: stay away from consulting.
My user name itself is a result of my experience working in one of those body shops. Client doesn't care, my employer doesn't care. I see people here talking about 1-1s and promotions and so on. I never had a single one in 5+ years. Clients treat us as outsiders. I am not sure if they even see us as humans. Just keep on dumping work, and then suddenly you are kicked out one fine day. Makes you wonder why did you spent 10-15 hours a lot of days for free. No team activities, no trainings, nothing.
My employer has absolutely no interest in my well being either. No promotions, no salary increments most years. Only time my 'manager' talks to me is when they want me to relocate to some other state or client. If I say no, they will threaten me - 'I will snip you' is what my manager told me once. Now I categorize these so called 'managers' as 'slave traders, parasites or demons'.
Wider variety of technologies and languages may sound good initially, but at least from my experience, the work you do for these clients are basically things you can learn on your own. So if that's your only goal, I would say do some personal projects instead.
Every single one of my colleagues have jumped ship within 2 years working in our company. Only idiots like me stayed. My itinerary for today is this: work from 6am-4pm. Then log out. Prepare for interviews. Get a work in good product company.
My user name itself is a result of my experience working in one of those body shops. Client doesn't care, my employer doesn't care. I see people here talking about 1-1s and promotions and so on. I never had a single one in 5+ years. Clients treat us as outsiders. I am not sure if they even see us as humans. Just keep on dumping work, and then suddenly you are kicked out one fine day. Makes you wonder why did you spent 10-15 hours a lot of days for free. No team activities, no trainings, nothing.
My employer has absolutely no interest in my well being either. No promotions, no salary increments most years. Only time my 'manager' talks to me is when they want me to relocate to some other state or client. If I say no, they will threaten me - 'I will snip you' is what my manager told me once. Now I categorize these so called 'managers' as 'slave traders, parasites or demons'.
Wider variety of technologies and languages may sound good initially, but at least from my experience, the work you do for these clients are basically things you can learn on your own. So if that's your only goal, I would say do some personal projects instead.
Every single one of my colleagues have jumped ship within 2 years working in our company. Only idiots like me stayed. My itinerary for today is this: work from 6am-4pm. Then log out. Prepare for interviews. Get a work in good product company.
Sorry but your issue is not "consulting" vs "product". You work for a shitty company/team/boss and you need to get out. Don't blame consulting in general.
Man I’m so sorry you’ve had such a bad experience. I don’t think this has to be the case in consulting, a supportive team and a policy to only work with clients that treat you respectfully could go a long way in situations like this.
It's a bad move usually. You're now variable cost, not fixed cost or investment (your hours cannot be capitalized).
So the company is heavily pressured to push your hourly rate down and your billable hours up.
So the company is heavily pressured to push your hourly rate down and your billable hours up.
What Steve Jobs had to say about consulting - https://www.youtube.com/watch?v=-c4CNB80SRc
Depends -- there are so-called "body shops" that only care about billable hours, and these are the worst.
But in general as a consultant your time is the product that the co. is selling. Never forget that.
But in general as a consultant your time is the product that the co. is selling. Never forget that.
My 1 year at a consultancy out of 13 total as a dev gave me the the impression:
1. You get to walk on 10x the eggshells for the same pay
2. Shorter project ownership time horizon might have been fine with me, except this particular group was so intent on presenting the appearance of utmost competence to the clients that they couldn’t do the necessary course corrections that become apparent maybe 1/3 of the way into any project, once you’ve gained the initial bit of experience particular to that project.
The result was a quality of work that I was not willing to be a part of, so I bailed.
1. You get to walk on 10x the eggshells for the same pay
2. Shorter project ownership time horizon might have been fine with me, except this particular group was so intent on presenting the appearance of utmost competence to the clients that they couldn’t do the necessary course corrections that become apparent maybe 1/3 of the way into any project, once you’ve gained the initial bit of experience particular to that project.
The result was a quality of work that I was not willing to be a part of, so I bailed.
I have worked for several consulting firms, ranging from global ones to 10 person ones. In my experience there is a lot of repetition but across a diverse range of industries. So if you are only interested in the technology, then it might get boring. Having said that, I did learn new technologies by being willing to take on jobs involving tech that I was unfamiliar with.
Talking to friends working for other consulting firms, reveals that some firms focus on a narrow niche of technologies and don't touch anything outside of that. Others seem to take on clients only in a limited range of industries.
Your best bet is to research the company and ask questions in the interview. Only then will you be able to ascertain whether it is a good fit for your career expectations.
Talking to friends working for other consulting firms, reveals that some firms focus on a narrow niche of technologies and don't touch anything outside of that. Others seem to take on clients only in a limited range of industries.
Your best bet is to research the company and ask questions in the interview. Only then will you be able to ascertain whether it is a good fit for your career expectations.
Product companies move slowly despite what they believe and all their agile ceremony. Consulting firms move quickly. The reason for the distance is cost center. At a product company a developer is always a fixed expense and never a driver of increasing revenue, such as sales and marketing. In a consulting company a developer is billing a client for their time and that billing determines the financial effectiveness of the developer to the business even though the developer doesn’t determine the relationship or set its terms.
So far in my software engineering career, I’ve worked at a product focused company and at a media company (building internal APIs/tools/etc.). I’m interviewing at a small software company that’s more of a consulting shop / contractor. Teams have several active projects, and it sounds like most contracts last for less than a year, with several multi-year engagements mixed in.
So my question is: What should I be considering before moving into this sort of work? A variety of projects sounds like it could be engaging, but on the other hand, maybe I’ll get bored writing the same boilerplate over and over? It also sounds like consulting has the potential to expose me to a wider variety of technologies and languages, which I see as a plus. But I’m worried that being involved with shorter term projects means I won’t get the chance to gain _deep_ expertise in any one thing, which might hurt my future job prospects?
Any advice would be greatly appreciated.