The Framing of the Developer • Hacker News Board

Re: The Framing of the Developer

#11

Post by jbay808 » Wed, May 06, 2020, 6:55 AM UTC

gregdoesit wrote: post #7

One of the most well-known companies using what the author calls “impact frame” is Facebook. There, engineers’ promotions and perf used to be heavily dependent on their impact. Developers needed to be aware what the business impact of their work was, thus they needed to measure (using the excellent tooling available). This model worked very well while the company was growing. Lots of features core to Facebook today w…

Incentivizing your staff to optimize a measure is always dangerous. You'd better be darn sure that that measure is a very good approximation of your utility function.

Re: The Framing of the Developer

#12

Post by jzer0cool » Wed, May 06, 2020, 7:03 AM UTC

Really like the diagram. I thought at first "frame" as in the architecture, like a picture frame. Then, it was "frame" as blame why something was not delivered. But then ... if read just ... right ... it is both.

Re: The Framing of the Developer

#13

Post by CoolGuySteve » Wed, May 06, 2020, 7:06 AM UTC

gregdoesit wrote: post #7

One of the most well-known companies using what the author calls “impact frame” is Facebook. There, engineers’ promotions and perf used to be heavily dependent on their impact. Developers needed to be aware what the business impact of their work was, thus they needed to measure (using the excellent tooling available). This model worked very well while the company was growing. Lots of features core to Facebook today w…

I always think of the Business Dudes episode of Adventure Time: https://www.youtube.com/watch?v=_mxB_OlSsKI

It's so blunt that it's great, the business dudes are so adept at optimization while ignoring externalities.

"These poor souls are lost without jobs, we can't ignore their plight!"

Re: The Framing of the Developer

#14

Post by davedx » Wed, May 06, 2020, 7:16 AM UTC

gregdoesit wrote: post #7

One of the most well-known companies using what the author calls “impact frame” is Facebook. There, engineers’ promotions and perf used to be heavily dependent on their impact. Developers needed to be aware what the business impact of their work was, thus they needed to measure (using the excellent tooling available). This model worked very well while the company was growing. Lots of features core to Facebook today w…

> My take is the optimum is in-between. Engineers should have an understanding and input on the business impact. But the strategy and prioritisation framework does need to come top-down, aligned with the long-term goals of the business.

I used to work for a small-ish Dutch energy company, and they went to a great effort at implementing this kind of framework, I thought it was great. We basically had huge quarterly roadmaps pasted onto one big wall of the office, and you would frequently see the product, marketing, sales and C-level people stood there discussing and prioritising. The transparency here meant anyone could wander up and see what the strategy was for the quarter and therefore what would be prioritised. It was sometimes gloriously messy but you really felt included and incentivised to work towards the company's common goals. Wish everyone did this.

Re: The Framing of the Developer

#15

Post by luckylion » Wed, May 06, 2020, 7:54 AM UTC

Supermancho wrote: post #8

This seems like a very specific set of experiences has set this developer up to make broad statements that do not fit with my reality. > Feeling in control is one of the main drivers for happiness. I'm not sure this person has ever developed a product, on their own. Feeling like you have some control is not the same thing as being in total control. > The word backlog makes you think you are always behind finishing th…

It's PR/link bait for Startup Coaching, don't read too much into it.

Re: The Framing of the Developer

#16

Post by 29athrowaway » Wed, May 06, 2020, 8:03 AM UTC

That is why you need engineering leadership that can keep the PM in check, and can veto PM decisions if they endanger the product in a way only engineers can understand, or want to understand.

And that engineering leadership needs to be independent enough from the PM, so that the PM cannot appoint redundant/agreeable scapegoats with no engineering weight.

Maybe you can still allow the PM force their hand on engineering, but that should be a procedure involving a written and signed release form so that the PM is directly responsible for their own decisions, without scapegoats.

Re: The Framing of the Developer

#17

Post by ciprian_craciun » Wed, May 06, 2020, 8:21 AM UTC

I liked the idea of "impact" prioritization of "work-items". (In fact I don't think this is something new, as I would assume many already prioritized their "backlog" based on how "important" that item was, although perhaps they didn't name that metric.)

However the author fails to answer one key question: what is "impact"?

I understand that a definitive answer can't be easily given, as it could range from increasing users / sales, taking head-on another competitor, putting out a completely new product / feature, etc.; but I would have expected at least some hints about this.

Because without even a fuzzy definition of "impact" we just rename "metric" (or "KPI", or whatever is the latest trend) as "impact".

Based on his example of Apple and the introduction of iPhone, I would assume by "impact" he means: a revolutionary "product" (or in other cases feature) that follows a road not taken by other competitors.

Re: The Framing of the Developer

#18

Post by dangrover » Wed, May 06, 2020, 8:26 AM UTC

The framing he speaks of in the beginning is the crappy framing developers, by default, apply to themselves. I remember when I was an engineer I had a similar mentality and felt like I was at the kids' table. Maybe that's why I got sick of it and became a PM.

Good PMs certainly do not think primarily in terms of backlogs and stuff to ship; developers who are not curious about impact and fetishize implementation details think this way. Nor do they judge engineers purely as a function of their ability to crank through the backlog (rather, it's their responsibility to set correct expectations with leadership and reconcile the problems to be solved with the resources available to execute against them).

Impact starts with prioritizing problems relative to the state of the world, not prioritizing solutions or features like we normally think of as on a backlog. Once you do that, the backlog comes pretty naturally.

Re: The Framing of the Developer

#19

Post by 29athrowaway » Wed, May 06, 2020, 8:34 AM UTC

gregdoesit wrote: post #7

One of the most well-known companies using what the author calls “impact frame” is Facebook. There, engineers’ promotions and perf used to be heavily dependent on their impact. Developers needed to be aware what the business impact of their work was, thus they needed to measure (using the excellent tooling available). This model worked very well while the company was growing. Lots of features core to Facebook today w…

There is also the bus factor.

If critical business functions depend on a piece of software maintained by one person, the organization has a problem.

If you decide to become dependent on a piece of software, that software better be well documented, tested, audited and maintained by a group of people with certain level of redundancy in case one of them is not available or leaves the organization.

Re: The Framing of the Developer

#20

Post by marcus_holmes » Wed, May 06, 2020, 8:42 AM UTC

mikekchar wrote: post #5

I like the diagram in the middle of the article and think it has a lot of value, but I want to comment on the "XP failed" aspect of the article. I've very rarely seen any team actually implement XP. The rare times I've been able to do so, it has worked spectacularly well. However, the constraints are difficult to deal with and XP in its original form only works with small, co-located teams. If you have more than 3-4…

This is the "no true scotsman" thing that plagues SCRUM too. The "you're not doing it right, so obviously it's not working for you" argument.

If a team attempts to implement XP, and fail, then XP failed. Any discipline that doesn't work in real situations using real people with real politics and management issues, doesn't work.