3 ms·

I completely agree. I've foudn that skill never goes away no matter how far you get. The trick is as you go higher up, spotting what comes next and knowing how

I completely agree. I've foudn that skill never goes away no matter how far you get. The trick is as you go higher up, spotting what comes next and knowing how to solve it faster. > They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting. I had a great manager when I was fresh and I watched someone else on the team go down this path and succeed. I know now that the difference was that they knew what was going to bite us in 2 weeks/2 months, and that it was partially experience and partially they had info on where the project was going that I didn't. But had I looked at what they were doing and mimic'ed it, I would have failed.

spdionis 1y ago
You can go on sidequests but first you need to accumulate sufficient credibility.
- rcxdude 1y ago
  This is it, pretty much. If you do your own thing and it works, then you'll come out well. If you do your own thing and it fails, you'll look bad, while if you do what yiu're asked you're going to be much safer. So if you go off-piste you should have some confidence it'll work.
  - maccard 1y ago
    > if you go off-piste you should have some confidence it’ll work Just remember that the definition of “working” is in the eyes of your manager. Assuming they’re competent and not pointy haired boss, then they might have different goals and priorities to you. I’d you end up diverging from them, even if what you did is technically good and a good fit for the project, you’ll probably have a bad time.
    - rcxdude 1y ago
      Yes, you do still need to solve a problem that is considered a problem and at least around the same level of importance of whatever you were supposed to be working on, preferably greater.
monkeyelite 1y ago
> spotting what comes next and knowing how to solve it faster This is such a strange mindset to me. Part of staff engineer is learning you don't need to solve tomorrow's problems. You solve it with the constraints you understand and leave room for expansion if needed. Why do we have the opposite belief organizationally? And why as a manager would you want your top workers to be speculating about things you might want rather than achieving at the tasks you gave them? (This is a genuine question.)
- alchemism 1y ago
  In certain tribal societies, there is no "chieftan" per se, there is just the guy who happens to be correct about things more than everyone else, so his opinion gets the most weight.
- maccard 1y ago
  It’s obviously way more nuanced than 2/3/5 lines of text on both sides but; It’s not about speculating vs achieving what I’ve assigned them. It’s an over simplified example but if an engineer has two tasks to be completed that are dependent, it’s poor engineering for task A have to be re-done for task B to work (imagine an API that has ambiguity in the definition of done). A good engineer thinks just a little bit farther ahead. At a staff+ level, 8: expect them to not only consider that but to consider “how likely is it what I’m going to have to re do this work” and scope accordingly, or to come to me and say “hey, every feature we add to service Alpha, we end up having to do XYZ to it, but with Beta we don’t”. They spend 10x more time than me writing code so they know that better than I do. My team know my priorities, know what I value and know the areas I’m keeping an eye on. If one person is continually going on unhelpful tangents then that’s a single person issue to be handled with them directly. YMMV with team sizes, team maturity, and where you are with your product dev.
  - monkeyelite 1y ago
    That makes sense. I guess seeing the full lifecycle is always how I think about software I work on. I can do a better job of communicating that’s what I’m doing and why the approach I’m using (of doing less) actually helps us to be able to make changes.

spdionis 1y ago

You can go on sidequests but first you need to accumulate sufficient credibility.

rcxdude 1y ago
This is it, pretty much. If you do your own thing and it works, then you'll come out well. If you do your own thing and it fails, you'll look bad, while if you do what yiu're asked you're going to be much safer. So if you go off-piste you should have some confidence it'll work.
- maccard 1y ago
  > if you go off-piste you should have some confidence it’ll work Just remember that the definition of “working” is in the eyes of your manager. Assuming they’re competent and not pointy haired boss, then they might have different goals and priorities to you. I’d you end up diverging from them, even if what you did is technically good and a good fit for the project, you’ll probably have a bad time.
  - rcxdude 1y ago
    Yes, you do still need to solve a problem that is considered a problem and at least around the same level of importance of whatever you were supposed to be working on, preferably greater.

monkeyelite 1y ago

> spotting what comes next and knowing how to solve it faster This is such a strange mindset to me. Part of staff engineer is learning you don't need to solve tomorrow's problems. You solve it with the constraints you understand and leave room for expansion if needed. Why do we have the opposite belief organizationally? And why as a manager would you want your top workers to be speculating about things you might want rather than achieving at the tasks you gave them? (This is a genuine question.)

alchemism 1y ago
In certain tribal societies, there is no "chieftan" per se, there is just the guy who happens to be correct about things more than everyone else, so his opinion gets the most weight.
maccard 1y ago
It’s obviously way more nuanced than 2/3/5 lines of text on both sides but; It’s not about speculating vs achieving what I’ve assigned them. It’s an over simplified example but if an engineer has two tasks to be completed that are dependent, it’s poor engineering for task A have to be re-done for task B to work (imagine an API that has ambiguity in the definition of done). A good engineer thinks just a little bit farther ahead. At a staff+ level, 8: expect them to not only consider that but to consider “how likely is it what I’m going to have to re do this work” and scope accordingly, or to come to me and say “hey, every feature we add to service Alpha, we end up having to do XYZ to it, but with Beta we don’t”. They spend 10x more time than me writing code so they know that better than I do. My team know my priorities, know what I value and know the areas I’m keeping an eye on. If one person is continually going on unhelpful tangents then that’s a single person issue to be handled with them directly. YMMV with team sizes, team maturity, and where you are with your product dev.
- monkeyelite 1y ago
  That makes sense. I guess seeing the full lifecycle is always how I think about software I work on. I can do a better job of communicating that’s what I’m doing and why the approach I’m using (of doing less) actually helps us to be able to make changes.