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

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.

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.

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)

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.