I tend to apply this to myself, within an organization (as opposed to those who like to generically try it all - fair enough). I've always been an enormous fan of touring the organization. Whether I join as a dev, or an exec, I always make it a point to spend some time with product, with support, and with marketing. It ends up providing me a unique vantage point. I encourage others to do the same, and when I 'control' onboarding, make it part of the process.
It's literally the fastest way to have someone get up to speed with the customer profile and product. They can play with it whilst listening in to support calls (if a thing). They can learn about pain points and "hard edges" that as developers we don't always come across.
The other powerful thing about being able to do everyone else's job is that you, personally, gain a lot of leverage, and in a lot of different ways. Someone else needs a favor? You probably know how to deliver. Something's on fire? You probably know what to do next, or at least who to call, no matter what's on fire today. Someone isn't budging on something? You might not have any bigger of a lever than anyone else, but you probably know exactly where to position yours, and exactly what it'll do when you apply a bit of force.
It's useful.
And then there's times like getting to charge your client $300/hour to drop stuff off at FedEx. Because you can do that and you're here and you'll get it done right -- no one needs to explain the idiosyncracies of this particular deadline or package contents; you've got it.
Even if that's not normally a senior consultant's job.
LOL! My bosses used to tell me that I need to learn to be more `rude` and not just do what others says because I can. I have learnt a lot and one of the biggest is to say NO, in big Uppercase—I can do anything for work but I won’t do that, NO, I won’t do that.
Sometime, I still do and I like the fun and thrill of locking in a hotel room after a meeting and coming out in lot less days these days (pppppsssstt, because of AI) and get into the next meeting showing off what can be done that was discussed 48 hours ago.
You don't do these things because they benefit your boss. (They might happen to, but that's not the point.)
You do them because they benefit you.
Not going to benefit you? There's lots of ways to say no to a back-channel request. Not a back-channel request? Then I guess it's not someone else's job!
I disagree with the centralization thought. I'm working on a project to create a central AI platform for a very large corporation. As you can imagine, such a large company already has several different platforms made by different branches within it. Each branch has something they are relatively happy with. But corporate sees this redundancy as waste, so they want to consolidate it into one.
The problem with one is the same with any other single source: you are stuck with whatever they offer on whatever timelines they provide. You are sharing this with a hundred thousand other people, so it's not tailored to your use case, but either made as generic as possible, or full of irrelevant features. Both of these cases make it worse for you.
I have often made in house libraries either based on or completely replacing a free equivalent because the free one doesn't meet our needs and has extra complications we don't need. Yes, it comes with its costs, but sometimes it's worth it for something that genuinely meets your needs.
By forcing everybody to use the same common platform, you are either forcing them to work around the mismatch between the platform and their needs, or your are forcing the platform to provide for everyone's needs. Neither is efficient and it harms every other user.
If you are going to make your own, you had better have a good reason for it, but you shouldn't be forced into a single solution for everything - it can end up being more expensive than making a few special purpose applications.
I have always enjoyed yosefk's writing, but I am not sure this is fair. He mentions Scaled Agile for Enterprise after saying:
> that many of them have long figured out that they’re really supposed to follow orders passed down the hierarchy
What I have seen in practice is that the people who actually care and bypass the hellish framework that is SAFE get berated for both "missing sprint goals / jeopardizing PI goals" AND half-assing work that comes in over side-channels. So maybe the ones that "have long figured out" how to navigate that system are onto something.
Is yosefk's approach the best for the company? I think so. But it also puts a lot of people under pressure, and I am unsure if it's wise to always put the company first.
I learned this the hard way. I have been training a bunch of 5-10 years experience tech-leads, architects, and what not. But on the job, I realized quite a lot cannot switch context and subject at all.
I've found people who have spent decades on one topic in a very specific vertical. It is amazing how they know EVERYTHING in that and I can listen with my jaws dropped to the floor for hours. Then I will wake up, with that spine-chilling shake all over my body on how patient and dedicated one has to be to be on that straight line their entire life.
The skill to distinguish on whether the extra work will help you get paid more in the future is essential. Developing this skill makes it a bet instead of just working more.
It's not possible to do everything. That's when your coworker that dedicates every waking moment to the job will outpace you and then set the standards.
I guess I should add "for someone else". In that case it's just bad negotiating skills, but at the same time companies have a lot more bargaining power over individual employees, and it's especially bad in the software industry.
I tend to apply this to myself, within an organization (as opposed to those who like to generically try it all - fair enough). I've always been an enormous fan of touring the organization. Whether I join as a dev, or an exec, I always make it a point to spend some time with product, with support, and with marketing. It ends up providing me a unique vantage point. I encourage others to do the same, and when I 'control' onboarding, make it part of the process.
It's literally the fastest way to have someone get up to speed with the customer profile and product. They can play with it whilst listening in to support calls (if a thing). They can learn about pain points and "hard edges" that as developers we don't always come across.
The other powerful thing about being able to do everyone else's job is that you, personally, gain a lot of leverage, and in a lot of different ways. Someone else needs a favor? You probably know how to deliver. Something's on fire? You probably know what to do next, or at least who to call, no matter what's on fire today. Someone isn't budging on something? You might not have any bigger of a lever than anyone else, but you probably know exactly where to position yours, and exactly what it'll do when you apply a bit of force.
It's useful.
And then there's times like getting to charge your client $300/hour to drop stuff off at FedEx. Because you can do that and you're here and you'll get it done right -- no one needs to explain the idiosyncracies of this particular deadline or package contents; you've got it.
Even if that's not normally a senior consultant's job.
LOL! My bosses used to tell me that I need to learn to be more `rude` and not just do what others says because I can. I have learnt a lot and one of the biggest is to say NO, in big Uppercase—I can do anything for work but I won’t do that, NO, I won’t do that.
Sometime, I still do and I like the fun and thrill of locking in a hotel room after a meeting and coming out in lot less days these days (pppppsssstt, because of AI) and get into the next meeting showing off what can be done that was discussed 48 hours ago.
You don't do these things because they benefit your boss. (They might happen to, but that's not the point.)
You do them because they benefit you.
Not going to benefit you? There's lots of ways to say no to a back-channel request. Not a back-channel request? Then I guess it's not someone else's job!
Nice reference
I disagree with the centralization thought. I'm working on a project to create a central AI platform for a very large corporation. As you can imagine, such a large company already has several different platforms made by different branches within it. Each branch has something they are relatively happy with. But corporate sees this redundancy as waste, so they want to consolidate it into one.
The problem with one is the same with any other single source: you are stuck with whatever they offer on whatever timelines they provide. You are sharing this with a hundred thousand other people, so it's not tailored to your use case, but either made as generic as possible, or full of irrelevant features. Both of these cases make it worse for you.
I have often made in house libraries either based on or completely replacing a free equivalent because the free one doesn't meet our needs and has extra complications we don't need. Yes, it comes with its costs, but sometimes it's worth it for something that genuinely meets your needs.
By forcing everybody to use the same common platform, you are either forcing them to work around the mismatch between the platform and their needs, or your are forcing the platform to provide for everyone's needs. Neither is efficient and it harms every other user.
If you are going to make your own, you had better have a good reason for it, but you shouldn't be forced into a single solution for everything - it can end up being more expensive than making a few special purpose applications.
I have always enjoyed yosefk's writing, but I am not sure this is fair. He mentions Scaled Agile for Enterprise after saying:
> that many of them have long figured out that they’re really supposed to follow orders passed down the hierarchy
What I have seen in practice is that the people who actually care and bypass the hellish framework that is SAFE get berated for both "missing sprint goals / jeopardizing PI goals" AND half-assing work that comes in over side-channels. So maybe the ones that "have long figured out" how to navigate that system are onto something.
Is yosefk's approach the best for the company? I think so. But it also puts a lot of people under pressure, and I am unsure if it's wise to always put the company first.
I do enjoy learning new things and having a generalist approach. But its not for everyone.
I learned this the hard way. I have been training a bunch of 5-10 years experience tech-leads, architects, and what not. But on the job, I realized quite a lot cannot switch context and subject at all.
I've found people who have spent decades on one topic in a very specific vertical. It is amazing how they know EVERYTHING in that and I can listen with my jaws dropped to the floor for hours. Then I will wake up, with that spine-chilling shake all over my body on how patient and dedicated one has to be to be on that straight line their entire life.
Nice post, but I would appreciate examples. Anyone has good examples of this, and of the "not like this" section?
Just work a lot more for the same pay. Great idea.
The skill to distinguish on whether the extra work will help you get paid more in the future is essential. Developing this skill makes it a bet instead of just working more.
Only if you add the hours for free and dont punch out when you should.
It's not possible to do everything. That's when your coworker that dedicates every waking moment to the job will outpace you and then set the standards.
This is what pretty much every “lifehack” type of tip boils down to, btw lol
I guess I should add "for someone else". In that case it's just bad negotiating skills, but at the same time companies have a lot more bargaining power over individual employees, and it's especially bad in the software industry.
For the benefit of humanity.
As long as you keep getting the performance review brownie points, because if you don't you are out and it doesn't matter.
Charging $300/hr to drop off FedEx packages is great until you realize you're the only one who knows where the tape is.