Introduction

I want to start by clarifying that everything in this article is based on my personal experience working for about three years at a consulting company. I didn’t do any research, or reach out to other colleagues working with other companies, so some of the points may reflect my specific situation. That said, I believe many of the observations are broadly applicable and would likely hold true across different consulting environments. Also, I want to focus only on the IT & technology domain, as this is my work domain.

What is a consulting company?

A consulting company is a professional service firm that provides expert advice and specialized solutions to other businesses. For example, if your company is having some legal issues, then you would hire a legal firm to provide guidance. If you want to file your taxes, an accounting firm would be hired to do the job. In software development, this could happen for multiple reasons:

  • Legacy System Migrations: You have an old legacy system that is becoming impossible to maintain, so you hire a consulting company to migrate to a new codebase.
  • Cloud Architecture: You have an on-premises system that you want to migrate to the cloud.
  • Staff Augmentation: You need to deliver some features fast, and your IT department can’t handle everything, therefore you hire externals to do that for you.
  • Core Business Focus: You want to focus more on the marketing and business growth of your application, and you don’t want to hire and manage an engineering department.
  • …

Pros of working as a software engineer with a consulting company

  • Network

For me that’s the most important benefit. When working in consulting you get to work with different clients and meet a lot of different people from your domain. This network can help you later when you decide to find a new job. In fact, I’ve seen situations where, once a project was handed over, the client reached out and hired the consulting team to work with them internally. You also get to know how massive companies work internally. I had a colleague who was working with one major client, Afterwards he said “It was a dream for me to work with this company, but now that I see how they work internally, I would never consider working with them.”

  • Lower Requirements

Usually, consulting software companies don’t have very high entry requirements. You can get hired straight from college as a junior developer, and many people who decide to change careers from fields like physics or mathematics find opportunities here. It is also great for students who are finished with academia and want to start working immediately. Within my three years at my current company, the vast majority of our hires fell into one of these categories. In fact, I don’t remember having a single senior engineer join the company.

  • Breadth over specialization

Consulting companies work with many different clients, and most of the time, the project lifecycle is short. Because of this, you would constantly move between different projects, each using a different tech stack. Today you might be working as a backend engineer using Go, then you move to another project that uses Kotlin and Spring Boot. Sometime later, you might work as a frontend developer using Flutter or React. The benefit here is that you have the opportunity to work in various domains using different technologies.

I see a lot of fresh graduates asking me, “What should I focus on? Web development? If yes, then should I focus on backend or frontend? Maybe UI/UX design, SRE, or AI?” My answer is always “I don’t know what you like yet.” Personally, I can’t imagine myself working on SRE or infrastructure topics. However, when you are exposed to different options to try in a production environment, then, as a fresh graduate you can figure out what you want to specialize in later.

That said, this breadth isn’t ideal for the long term. This flexibility comes with several downsides, which I will cover in the “Cons” section below.

Cons of working as a software engineer with a consulting company

  • Breadth over specialization

Yes, again. As an entry-level job, this is helpful for a short time, but eventually, it starts to hurt you more than you think. During my three years in consulting, I worked with Kotlin and Spring Boot, Python and LangChain, Java and Spring Boot, and Go on the backend. For the frontend, I worked with Vue.js, React and Flutter. I also worked with both GCP and AWS. I know all of these technologies and I can work with them, but I still don’t feel confident enough to say I am a senior in any stack. You need to know when to start caring more about depth instead of breadth.

  • Conflicting work styles

Think about this as two corporations working together, but they both have different ways of managing their work. One works with an iterative approach, while the other uses Agile. One wants to use story points for planning, while the other uses time capacity. Sometimes these two corporations can be stubborn enough not to compromise; other times, they would agree on a “middle ground” solution that is even worse. I have seen this in action; teams being handed over and projects ended just because no one wanted to sit down, talk, and listen. This also affects your relationship with the people you’re working with. You have to follow your company’s guidelines, and they also have to follow their own guidelines. These guidelines are often defined by managers who never talk to or see each other, while you are the one talking to your colleagues daily.

  • Lack of Ownership

You don’t own the product that you are building. Yes, you are the one working on it and creating it, but in the end, the client owns it. This means you often have to follow decisions you don’t agree with, whether it’s the stack you use, the architecture design, or the choice to use Postgres versus MongoDB as a database. You can suggest what to use and you can discuss it, but in the end, it is entirely up to the owner to choose.

  • Frequent changes

Expect that at any time, your manager could reach out and tell you that the end of next week or month will be your last day with the team. The reasons vary wildly: the end of a contract, a client running out of budget for the project, a sudden change of scope, or a relationship with the client that went sour. Of course, this sudden shift is always followed by a new tech stack, new colleagues, a new work style, and very little time to adapt to everything. Most importantly, it comes with a real emotional burden.

  • Emotional burden

I experienced this when we handed over a project I felt most attached to. I joined at an early stage and watched it grow, contributing to every single part of the codebase. I even had a couple of ideas to improve it further. The worst part was that the handover came right after a feature I had worked hard on for more than three months finally went live. It felt as though I had never worked on it at all, because I never got to see it in action. To be honest, I think that was the main reason I decided to look for a new job away from the consulting world.

Conclusion

I want to conclude by saying that consulting companies are here for a reason, and they are going to stay for a long time. Especially right now, with many businesses building products using only AI agents, I expect that in the next two to three years we will see consulting companies step in just to fix all the crap that AI is producing.

If you are a fresh graduate or someone looking to break into software development, you can benefit from working at a consulting company. Just keep in mind not to stay too long in this field.

I hope you liked this article as much as I enjoyed writing it! It has been a long time since I wrote something here. I have a couple of new ideas to write about and am super excited about them, so I will try my best to publish more frequently. Stay tuned for more! 😃