[scarface_74]

Our guidelines (BigTech consulting department) on a high level are

L4 - problem and solution is well defined

L5 - problem is well defined, your responsibility to come up with a solution or at least be able to reach out to the right people for help.

L6 - neither problem nor solution is well defined

[singleshot_]

1) I don’t know what the problem is. 2) I can see the problem but I need to be told both the solution and how to implement it. 3) I see the problem and if you tell me the solution I can execute it. 4) I see the problem and I know the solution. Should I execute the solution? 5) advisory: I found a problem and I solved it.

Once you have a critical mass of threes and fives in the team you can go do something else and they can take over.

[scarface_74]

Is there ever a level as an IC that you don’t ask so me one should you implement a solution? Even when I was at a startup as a senior dev and the de facto “cloud architect” with a direct line to the CTO who fully trusted me. I would always ask “should I implement this”.

He would say no occasionally for business reasons or he would come back with suggestions based on his knowledge of the future directions of the company.

Even now, if I’m coming up with what I think is a novel solution where I am responsible for the project, I’ll reach out to a coworker for a sanity check or sometimes the actual service team (ie the team responsible for maintaining the AWS service I’m using) to see if there is a better way.

[singleshot_]

Maybe one difference is I didn’t really see our team as ICs so much as they were experienced postsale consultants. They might be alone at a client site making five to ten strategy decisions a day and I didn’t want them constantly bound up seeking permission to act from some dumb guy who had fewer details and a couple more years of experience. If they did something wrong that we needed to undo, that was often less challenging than if they had to chill out for an afternoon waiting for me to get up to speed.

[ip26]

What kind of scope are we talking about here? Is the L5 charged with "the website should load a bit faster", or "the flagship product is not competitive in the market"? Is the L6 individually grappling with "where will the entire industry be in ten years"?

[scarface_74]

I’ll defer to a developer for a better example. Even though my background is as a developer and my specialty in the consulting department is “application modernization” meaning I mostly work with application development using cloud services and “DevOps”, I don’t know how it maps to software development requirements.

For the consulting department, we are given a customer project. Depending on the complexity of a project, it will be split into “work streams”

L6 - the project lead responsible for understanding the scope of the entire project, how multiple teams work together and should be “strategic”. They should be able to suss out the customer’s pain points and orchestrate the different lanes of work.

L5 - “tactical” In a normal software development environment, I would consider this a team lead and where I am. Whatever “workstream” I’m over, I should be able to gather requirements, come up with action items and estimates, schedule meetings, present proposed solutions, implement them or find the right people for help, document the implementation, work with the customer to teach them how to use it, support it, expand it, etc.

On smaller projects, if there is only one workstream. I’m often the only technical resource.

The customer knows the business outcomes and pain points. It’s up to me to design a solution.

L4 - they are expected to be able to gather requirements and understand the problem. But need help designing and implementing a solution.

From a soft skills standpoint, an L4 consultant could probably go toe to toe with an L6. From a system design standpoint, an L5 could go toe to toe with an L6 since we do actually do system design as part of our day to day work.

Now actual development skills and passing a coding interview is a different story.

[ip26]

How large is a project in this explanation? 20 FTE? 200 FTE?

[dclowd9901]

And at any of those levels, you’re doing what the company is telling you (implementing actual specs vs creating specs).

[0xEFF]

Not at L6. Scarface is right, most of the time the org just knows something is wrong and they don’t know what it is exactly or how to fix it. Sometimes they don’t even know something is very wrong, while working on a defining problem 1 the L6 also identifies related problem 2 the org thought was minor but is actually major.

None of this is specified, there are no specs to execute up front. Much of it is defining the spec yourself and collaborating with the rest of the org to find out if other people agree with the spec.

[dagmx]

You’re missing that it’s:

- implementing the spec for an existing spec (L4)

- creating the spec for a prescribed product (L5)

- recognizing the need for the product in the first place and advocating to make it happen(L6)

Each level feeds the one below it.

[scarface_74]

At L6, the problem isn’t defined. They just know something is wrong.

[dclowd9901]

If the company is saying “your job is to find problems and solve them,” you’re still doing what the company is telling you what to do. I’m just saying that if a company wants me to do something, they better accurately define the position (and compensate appropriately).

[pedrosorio]

What is a BigTech consulting department?

[scarface_74]

The three major cloud providers all have in house consulting departments consisting of full time employees.

https://aws.amazon.com/professional-services/

https://cloud.google.com/consulting

https://www.microsoft.com/en-us/professionalservices/overvie...