> If you’re doing what you’re told to do, they are paying you too much.
I'm glad Kent Beck got that one out. I work for a Big Tech that pays (comparatively) well, and sometimes there is lot of ambiguity. Some new hires have a hard time adapting, and complain that they lack direction or have nothing to do. When these kind of companies pay you big bucks, part of the job is to be proactive at finding and solving the problems in your organization.
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.
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.
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.
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"?
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.
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.
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).
"getting paid too much" is literally what corporations exist to do. why is it acceptable/moral for corporations to make unlimited profits, but bad for an individual human person to do so?
To be clear, that’s not a judgement. I think if people want to exist within those bounds it is completely sensible to do so, and I agree that companies get more out of people who step outside those bounds.
But it’s still dull. It’s dull to describe. It’s dull to aspire to. It’s just against the idea we’re drilled in as kids to dream big and make great stuff.
But dull is fine, dull puts money on the table and means that you have more time to do things you don’t find dull outside of work.
Not going to bore you with personnal experience ,but I learned the hard way that the more you are going out of your way to help org and coworkers, the more they expect from you and once your are near burned out, everybody is quick to forget how much you've done. From now on I vowed to do the absolute minimum to keep my job.
I can empathize with that. It’s certainly an area I’ve found myself in where you’re taken for granted.
The way I’ve found to adapt to that is to make my impacts known and learn to say “no” or “later”. And of course, as the article says, on-boarding others to unburden me.
If I tell people that I was responsible for something, it sticks and people start telling others when questions about it come up.
If I say no to people or tell them that I’ll help later , they start to value the impact of my absence.
It’s easy to be graciously taken for granted but imho it’s not too hard to control your outward narrative to change that, and in turn reduces burn out.
I developed and managed a team of professional services consultants and I have the opposite view. Teammates who needed me to explicitly tell them what to do are ok if they’re interested in growing beyond that but not otherwise. Ideal team members would see problems coming down the track, identify a solution, implement it, and brief me before I heard about it from someone else. If I thought their solution was not workable, I have a window to redirect them. If not, they solved a problem and I make a note so I can help them get promoted later.
Granted my PS practice ain’t no Google, but subordinates who require direct instruction for any longer than it takes to get comfortable are for the birds.
I'm currently in a similar situation by the sound of it.
There's an ebb and flow of inbound projects, and one of the engineers has taken advantage of his down time by building out infrastructure and reusable platforms. He pauses that and resumes paid work for clients as they come. I love it - he gets a lot of satisfaction out of building what he thinks we'll need without explicit deadlines, and consults me and his direct manager as necessary. His work is inspiring the more junior engineer on the team to learn and work more creatively and productively. That frees me up to establish better relationships with our Sales and Success teams to bring us new and better clients, which in turn increases their close rates. With the right people and environment, you can create a positive feedback loop that is fairly self-sustaining.
I'm not sure I agree. If I'm paying you nearly half a million a year as a US FAANGish senior engineer, I'm not going to have much patience for the excuse that "my manager didn't find enough high-value work for me to do". Compensation like that, to me, implies a higher degree of ownership and responsibility.
If you're a junior engineer, or sitting somewhere on the left-hand peak of the bimodal software engineer compensation curve [0], then sure, I'd expect your manager/PM/TL to slice up some reasonably high-impact work for you to take care of. Otherwise, bug PMs for ideas. Learn the basic shape of the organization you work in. Draft some one-page proposals and pitch them.
Don't expect to get paid like a heart surgeon just for crushing well-scoped React feature requests.
Yeah. I've never had that sort of comp but for long stretches of my career I've largely charted my own path. While my first manager in my current job and I always got along very well, he traveled a lot, I traveled a lot, and I never expected much in the way of specific direction. If I had a question I asked him.But we largely did our own things under a general umbrella. Probably atypical but I was hired pretty atypically as well. (Basically a position was created for me.)
> Expecting ICs to "find something and kill it" signals desperation
Ugh. Way to misrepresent GP. Table stakes for strong engineers is to be able to proactively find and solve problems in products (among other things.) Of course, they'll need the support of the larger organization, managers, PMs, etc., but they're are not just a bunch of drones that take orders.
If you want management to tell you explicitly what to do, expect management to be paid MUCH more than you. And if it's explicitly not your job, hopefully you never question or disagree? (And yet... if your management is expected to make all the calls themselves, in practice, that's gonna risk getting it wrong more frequently - there's only so much time in the day to be fully up to speed on all the decisions and branch points in plans.)
Complexity is fractal, you can often find important solutions to important problems as an individual without needing to be "crowdsourcing the direction of the company."
Good individuals who can let their managers focus on organizational things and solve technical things are valuable. Otherwise, if you just execute a list of tasks, you're pretty interchangeable.
I'm glad Kent Beck got that one out. I work for a Big Tech that pays (comparatively) well, and sometimes there is lot of ambiguity. Some new hires have a hard time adapting, and complain that they lack direction or have nothing to do. When these kind of companies pay you big bucks, part of the job is to be proactive at finding and solving the problems in your organization.