Ask HN: Moving from a product org to a consulting org: What should I know?

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.

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.

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.

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