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

I love that anecdote and it's a great illustration of the difference between demanding and empowering. Thanks for sharing.


Extending that anecdote, let's consider typical reasons for Ted's failure:

+ Project not properly defined/scoped + Ted not put in role that fits what he can do + Ted not given the right help or tools + Ted not given enough time + Ted not getting what he needs from team + Ted is incompetent and/or not engaged + Ted is competent and engaged but has some other issue hindering his work

Only the final two relate directly to Ted, 90% of the time are not the problem, and in 99% of cases would best be discussed 1:1 with Ted.

The others should be proactively raised by Ted and/or the team, and rarely impact only one individual. If they aren't raised, putting them on the table in a team meeting won't fix that problem.

A team discussion meanwhile, 99% of the time, is best focused on how the team can improve or fix what is broken...as a team. For example a functioning team would quickly put most of the possible problems listed above on the table.


Not to be too harsh on Ted, but in all the above scenarios, isn't he still responsible for not bringing the issues to discussion some time before the deadlines passed? That lack of communication on his part is a pretty big liability, assuming the deadlines are at all important.


Thats the beauty of being in management. The answer to this question is entirely within the manager's interpretation.

Yes, if you don't like Ted, or if you're harried and doing a bad job, why not call the whole thing 'his fault'. He should have read your mind, gone beyond the norm for his job and dreamt outside-the-box solutions to all the problems you didn't know he would face while providing him with questionable tools to do the job. And your word is what counts to HR and other managers.

If you're trying to accomplish the task rather than promote yourself or denigrate Ted, or simply if you're effective, you should take responsibility for defining the goal, setting realistic expectations, creating failsafes to stop things before they affect the whole project, and providing proper support & guidance.


Someone has worked for Amazon!





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

Search: