5 ms·

Worked for PWC, DT, EMC (pre-Dell) - great pay, insane hours, no work-life balance - it's all work and a bit of sleep. Fast-track to burn-out. What nobody seem

Worked for PWC, DT, EMC (pre-Dell) - great pay, insane hours, no work-life balance - it's all work and a bit of sleep. Fast-track to burn-out. What nobody seems to mention is that the Big 4 consult to enterprises so you have masses of meetings, "methodology" to follow and the general BS that comes with where PHBs rule. If you enjoy all that and politics then go for it. Personally I am far happier working as a one-man show. I only take on projects where I can deliver real results on realistic timelines and budgets.

butteredpopcorn 7y ago
How did you made the switch to working by yourself?
- CyberFonic 7y ago
  It took a series of steps. I was an Oracle/DB2 DBA + ERP specialist when working in the big 4 space. I learned networking whilst still using my DBA skills. Worked for a number of systems integrators from which I picked up some direct consulting work and some sub-contract work. These days I focus on product line software engineering and embedded systems, mostly custom IoT design and deployment. I think that the key to being a successful consultant is to have specialist skills that the larger firms do not have. In my experience, competing with larger firms requires undercutting their rates. Clients who are only interested in paying as little as possible are not my favourites.
  - butteredpopcorn 7y ago
    Thanks! I wonder about finding the balance between skills that are specialized enough to be rare, and but not so rare that people don’t need them that often...
apohn 7y ago
>Personally I am far happier working as a one-man show. I only take on projects where I can deliver real results on realistic timelines and budgets. There is a middle ground between Big 4 and one person consulting. I used to work in the services/consulting org of a decent sized software company that sold data products. We had ~25 consultants in the US and were focused on deployment and light/medium customization. Our selling point was that all consultants were like surgeons and did focused work. We were not a staff augmentation group. Two great things came from this 1). We didn't have enough people to support multi-year enterprise projects and all the BS that comes with that. If a customer had a big project we'd bring in a partner (e.g. Accenture). 2). Individual consultants could push back on unreasonable asks. For example, more than once I got asked to configure something (e.g. databases, firewalls, etc) that the company I worked for did not sell. I could simply say that I could provide info (e.g. schema recommendations, what ports to open), but the customer had to find somebody else to do it. If you work for a big consulting company the services manager will come in, say we can do it, and things just grow more complex from there as more and more people get dragged into things. Or worse, the services manager leans on you to do something totally out of your expertise because they don't care. At least 75% of the projects I worked on were reasonably scoped and budgeted. Of course 3 years after I started somebody somewhere decided the consulting team needed to generate more revenue and take on bigger projects.
- nighthawk648 7y ago
  While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are always going to be interacting systems and having knowledge of other systems only helps your job performance. When scoping for a client, there are many legal concerns at play. The scope, handed from the client, cannot be too specific technically. The concern is, if the systems change(due to firm changes, etc...) or one part of the implemented functionality is turned off (typically a free, or exit fee cost) certain technical verbiage would require contract arbitration and renegotiation. Maintaince fees are different. Most firms are paid significantly for the software produced, if they employees are not paid a proportionate amount, that’s the firms problem not the client. Unreasonable internal scopes are different then client scopes. You just emphasized you worked in a client facing business, I thought it was an interesting topic to discuss.
  - apohn 7y ago
    >While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are a lot of on-premise software vendors who are exactly like this. The consulting group exists to deploy, configure, and customize their software. While the consultants may connect and integrate with other systems, it's just a bad idea to start configuring systems from other vendors. For example, the software we (the company I worked for) sold could pull data from MS SQL. One of our customers had a product from another vendor that stored real-time data in an MS SQL server. Except, it was stored in a funky table structure and the SQL server was installed as part of that product install. It wasn't a standalone SQL server the client installed separately. The customer asked us to pull data in real-time from that server. After about a day of digging, it was clear the other vendor never intended for data to be pulled from this database and I had a ton of concerns about locks and lost data. So I said they needed to talk to the other vendor about this. As soon as I said "data loss" my management agreed with the decision to not mess with that database. I could certainly talk about our system and what we were trying to do with the other vendor, but we wouldn't touch that SQL server unless they said do. Consultants at Mulesoft, Talend, and even Cloudera are going to do the same thing. They may pull data from other databases, but the sensible consultants aren't going to start making big changes to a customer's MS SQL server, even if the consultant is highly experienced with that database.

butteredpopcorn 7y ago

How did you made the switch to working by yourself?

CyberFonic 7y ago
It took a series of steps. I was an Oracle/DB2 DBA + ERP specialist when working in the big 4 space. I learned networking whilst still using my DBA skills. Worked for a number of systems integrators from which I picked up some direct consulting work and some sub-contract work. These days I focus on product line software engineering and embedded systems, mostly custom IoT design and deployment. I think that the key to being a successful consultant is to have specialist skills that the larger firms do not have. In my experience, competing with larger firms requires undercutting their rates. Clients who are only interested in paying as little as possible are not my favourites.
- butteredpopcorn 7y ago
  Thanks! I wonder about finding the balance between skills that are specialized enough to be rare, and but not so rare that people don’t need them that often...

apohn 7y ago

>Personally I am far happier working as a one-man show. I only take on projects where I can deliver real results on realistic timelines and budgets. There is a middle ground between Big 4 and one person consulting. I used to work in the services/consulting org of a decent sized software company that sold data products. We had ~25 consultants in the US and were focused on deployment and light/medium customization. Our selling point was that all consultants were like surgeons and did focused work. We were not a staff augmentation group. Two great things came from this 1). We didn't have enough people to support multi-year enterprise projects and all the BS that comes with that. If a customer had a big project we'd bring in a partner (e.g. Accenture). 2). Individual consultants could push back on unreasonable asks. For example, more than once I got asked to configure something (e.g. databases, firewalls, etc) that the company I worked for did not sell. I could simply say that I could provide info (e.g. schema recommendations, what ports to open), but the customer had to find somebody else to do it. If you work for a big consulting company the services manager will come in, say we can do it, and things just grow more complex from there as more and more people get dragged into things. Or worse, the services manager leans on you to do something totally out of your expertise because they don't care. At least 75% of the projects I worked on were reasonably scoped and budgeted. Of course 3 years after I started somebody somewhere decided the consulting team needed to generate more revenue and take on bigger projects.

nighthawk648 7y ago
While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are always going to be interacting systems and having knowledge of other systems only helps your job performance. When scoping for a client, there are many legal concerns at play. The scope, handed from the client, cannot be too specific technically. The concern is, if the systems change(due to firm changes, etc...) or one part of the implemented functionality is turned off (typically a free, or exit fee cost) certain technical verbiage would require contract arbitration and renegotiation. Maintaince fees are different. Most firms are paid significantly for the software produced, if they employees are not paid a proportionate amount, that’s the firms problem not the client. Unreasonable internal scopes are different then client scopes. You just emphasized you worked in a client facing business, I thought it was an interesting topic to discuss.
- apohn 7y ago
  >While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are a lot of on-premise software vendors who are exactly like this. The consulting group exists to deploy, configure, and customize their software. While the consultants may connect and integrate with other systems, it's just a bad idea to start configuring systems from other vendors. For example, the software we (the company I worked for) sold could pull data from MS SQL. One of our customers had a product from another vendor that stored real-time data in an MS SQL server. Except, it was stored in a funky table structure and the SQL server was installed as part of that product install. It wasn't a standalone SQL server the client installed separately. The customer asked us to pull data in real-time from that server. After about a day of digging, it was clear the other vendor never intended for data to be pulled from this database and I had a ton of concerns about locks and lost data. So I said they needed to talk to the other vendor about this. As soon as I said "data loss" my management agreed with the decision to not mess with that database. I could certainly talk about our system and what we were trying to do with the other vendor, but we wouldn't touch that SQL server unless they said do. Consultants at Mulesoft, Talend, and even Cloudera are going to do the same thing. They may pull data from other databases, but the sensible consultants aren't going to start making big changes to a customer's MS SQL server, even if the consultant is highly experienced with that database.