Keep work fresh by teaching your successors and investing a bit in long-shots
51–54 of 54 posts
Re: Keep work fresh by teaching your successors and investing a bit in long-shots
#52Earlier quoted context omitted.
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 proje…
Re: Keep work fresh by teaching your successors and investing a bit in long-shots
#53> 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 i…
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.
Re: Keep work fresh by teaching your successors and investing a bit in long-shots
#54Earlier quoted context omitted.
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 th…
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 compa…