> 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?
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.
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.
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.
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.)