|
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. |