Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Accountability Problem

jamesshore.com

Post reply on HN
Print view View original

61–62 of 62 posts

Re: The Accountability Problem

#61

Post by boruto »

ozim wrote: post #30

I liked the article, it is really in depth. Thing is I am taking the opposite approach because author has different goals. Author gets to be VP of engineering on company that has multiple product teams and he gets to sit at "the table". I am engineering lead for a company that has one dev team, I can give my opinions and run stuff however I want but I don't get a sit at the table. The way I see it if I would like to…

Does you team hire? Haha. But yeah, In my current team EM also drops the ball for his own growth or agenda. Not sure how one can handle that.

Re: The Accountability Problem

#62

Post by mateo411 »

Esophagus4 wrote: post #31

A bit rambling and meandering, but some decent points in there I guess. Lost me on the elephants. Setting goals on estimated value vs measured value is the difference between a process goal and an outcome goal. I guess the idea is you can’t control outcomes, but you can control your process inputs. In baseball, for example, if you want to be a good hitter, don’t set a goal to hit .300, set a goal to do the things tha…

>For example, Sales teams are often compensated on revenue generated (outcome), but what if you did a good job (process) but didn’t hit your numbers because the market was just really bad in your vertical? A good leader will recognize this and still compensate you (i.e. hold you accountable) appropriately rather than punishing you for the outcome.

A good leader might try to keep you on the team, if they like you and you miss your numbers for a couple of quarters. From what I've seen, Sales is pretty brutal. It's quite common for Sales folks to lose their jobs, even if there are circumstances outside of their control. If they do keep you on and you don't meet your OTE, you will get paid less. In many ways their job is harder and has more risk than software engineers trying to deliver a software project on time. Which also very hard to do!

Post reply on HN