Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: