Only somewhat related, but in my line of work (corporate law), where we work on a lot of different kinds of transactions, I find that my experience of working on a particular type of transaction can be roughly divided into five stages:
- Stage 1: The first few times you work on a particular type of transaction, you are completely lost. You've never seen these documents before, it all feels alien and scary (bearing in mind you are probably at an early stage in your career at this point). You need someone more senior to hold your hand through it all, and you feel like you're asking a million questions.
- Stage 2: You've gotten your head around the basic structure and don't feel so useless. You're learning a lot with every deal, which is exciting. You're still asking a lot of questions but they are more intelligent questions, and you are able to contribute meaningfully.
- Stage 3: You are by now quite experienced at this type of transaction. You can pretty much run things yourself. You love doing this work because you are good at it, you can speak confidently about it and people trust you with it. Hopefully by this stage, you have someone more junior who is just feeling their way through Stage 1, and you can support them.
- Stage 4: You've done so many of these deals that they all start to feel the same and it gets a bit boring. Hopefully by this stage the junior has moved on to Stage 2. They can at least handle the most tedious stuff, and with your support they are also getting familiar with the more complicated stuff.
- Stage 5: Your junior (not really a "junior" anymore) has moved on to Stage 3 and can take the day-to-day running of the deals out of your hands. You remain involved mainly in a supervisory role, making sure quality of service remains high and dealing with the occasional novel issue that crops up. But in general you have a lot more time now, to work on other types of transaction, and of course to go out and build out new client relationships so that the work keeps flowing. And hopefully you have a second junior moving into Stage 1 to repeat the cycle.
Outsider perspective: you have nailed the training pathway, at least conceptually. Many level five practitioners are so far out of touch with level one that they have a tough time getting anyone else to level three. Keep up your good work!
> Many level five practitioners are so far out of touch with level one that they have a tough time getting anyone else to level three.
I've commonly run into this, myself. By the time someone gets to level four or five, they tend to associate more with people of their own level and it has been so long since they were themselves a junior that it becomes hard for them to relate. They expect competence and familiarity with the process from their colleagues, even if said colleague is a fresh new hire.
It can be pretty tough to overcome, from both sides.
> 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 agree in principle and practiced this for many years. But I moved into a role where there is simply no time. I work too much just to keep up with the normal workstream and while I maintain the list, there is no chance I get to it which is even more depressing.
Gotta have a job that allows you that extra time to explore.
I like this a lot but I think the number can be different depending on the company.
In my company we have “let yourself be nerd sniped” as an core cultural value, I think we’d be closer to 60/30/10 or something like that. But it’s hard to tell for sure because sometimes the 10 blows up into a mad 5 week rabbit hole quest with, often but not always, spectacular results. Would suck if we’d not have those because some boss said 10% fun stuff is the max. I guess it balances out over the year but attaching a number makes it a rule. So on second thought, maybe less explicit can be better?
- I find 5% for any investments very low. It is hard to get deeper into a new topic with that level. Our work has very high context switching costs.
- at the moment I work one day on another project requiring a fair amount of learning. While I learn a lot this way I found the two project setup exhausts my ability to push yet another set of things forward. There are limits to my ability to manage initiatives.
- the whole agile treadmill can be leveraged by management against self management. I found slowing down things and pushing myself to explore alternatives in my 80% block helps a bit to stem the tide.
I rarely do. I recently started using sub-stack for blogging myself, and I added in a paid version as well just to annoy people haha :) Just kidding though - the paid version is for everyone who appreciates my work and who wants to help me continue writing. It takes quite a while to come up with content and posts and time isn't 'free'. The free version is for anyone who wants to continually get new posts in their inbox which attempt to explain concept topics in an intuitive and visual manner. Yes - the pop ups I agree are relatively annoying, but I appreciate what sub-stack is attempting to do regardless. If it were up to me, I'd simply include a subscribe button at the end of each post which asks the user whether they'd like a free or paid subscription should they click on it. That's me though. I'm not sure what type of UI testing they've done nor what effect that would have.
I wholeheartedly agree with this but want to add that the 80/15/5 split aren’t set in stone. It’s more like risk tolerance. The more you spend on the riskier activities (not exactly what you’re asked to do), the higher the chance of failure but the greater the reward. You can drive your team or organization in a completely different direction.
Fully agreed, though the exact proportion may or may not be applicable for the particular position. I've progressed in my career by doing exactly this and see how it has benefited me relative to those who don't do it (or just aren't interested in it). I've been lucky to have managers that have supported this by checking me when I've taken on too much and urged me to assign tasks to more junior team members (which in itself turned from the "other" work into my main work). It results in a healthy team where all those who are willing have the opportunity to grow and expand their skillsets.
> If you’re doing what you’re told to do, they are paying you too much.
Not keen on this mindset. I’m glad to keep myself marketable, but that’s my business. My company’s business is: am I making what you want? Good. Pay me.
then your career path would be severely limited. because frequently in many roles especially software development and engineering, the business needs are not well articulated. sometimes the business end does not know how to articulate them, sometimes they aren't aware of better technical solutions, etc. a valuable technical resource does not simply do what they're told - this can be done by any outsourced developer in india or vietnam, etc. a valuable technical resource also needs to try and understand what is the business objective and think and be able to research and propose potentially better solutions, and make recommendations for the betterment of the business. those are the kinds of people who get promoted into higher level roles that pay better. those are people who are not easily replaced.
I agree. When I hire a professional I expect them to tell me when what I want is wrong or tell me how it can be done in a better way.
IME some organizations are just not open to alternative suggestions. Some genuinely just want people to do exactly as they’re told and work within the limitations of their system without question. This is IMO the worst type of organization to work for. Even in these environments, I would hope that people speak up.
- Stage 1: The first few times you work on a particular type of transaction, you are completely lost. You've never seen these documents before, it all feels alien and scary (bearing in mind you are probably at an early stage in your career at this point). You need someone more senior to hold your hand through it all, and you feel like you're asking a million questions.
- Stage 2: You've gotten your head around the basic structure and don't feel so useless. You're learning a lot with every deal, which is exciting. You're still asking a lot of questions but they are more intelligent questions, and you are able to contribute meaningfully.
- Stage 3: You are by now quite experienced at this type of transaction. You can pretty much run things yourself. You love doing this work because you are good at it, you can speak confidently about it and people trust you with it. Hopefully by this stage, you have someone more junior who is just feeling their way through Stage 1, and you can support them.
- Stage 4: You've done so many of these deals that they all start to feel the same and it gets a bit boring. Hopefully by this stage the junior has moved on to Stage 2. They can at least handle the most tedious stuff, and with your support they are also getting familiar with the more complicated stuff.
- Stage 5: Your junior (not really a "junior" anymore) has moved on to Stage 3 and can take the day-to-day running of the deals out of your hands. You remain involved mainly in a supervisory role, making sure quality of service remains high and dealing with the occasional novel issue that crops up. But in general you have a lot more time now, to work on other types of transaction, and of course to go out and build out new client relationships so that the work keeps flowing. And hopefully you have a second junior moving into Stage 1 to repeat the cycle.