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

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.

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.

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.

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.

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)

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.

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.

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.

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.

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.

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:

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

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.

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.

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

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.

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.

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.

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.

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.

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.