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

The Framing of the Developer

svese.de

Post reply on HN
Print view View original

51–60 of 67 posts

Re: The Framing of the Developer

#51

Post by routerl »

JoshuaDavid wrote: post #25
qw wrote: post #21

Earlier quoted context omitted.

> Choice example: does a time period "from January 2019 to January 2020" include two Januaries? The answer to this question would change, sometimes twice a week, when asked of the "product owner". Unfortunately, the only way you can protect yourself is to have a paper trail. If the PO says something, write it down in your tracker (Jira, Trello etc.), or at least an email. If the PO is unclear, write the answer accord…

Though even in a non toxic environment you should document any product decisions and why they were made. Your PM now could be the most amazing and helpful person in the world, but in 3 years it may be important to know if there is an important reason a time period from January to January includes both Januaries (and thus something important will stop working if you change it) or whether that was an arbitrary decision…

This is good advice, but in my case the "product owner" was too invested in seeming competent (by, e.g., over-confidently and over-emphatically making decisions that turned out to be coin-flips). Finally, there was no accountability for product ownership; other than the engineers, no one at the company was positioned, or willing, to notice/address the delays in the project that were caused by the product owner changing their mind arbitrarily.

So, while I did spend a few months documenting all these issues, the company itself had not made room for engineering-led process improvements. Noticing that, I started spending political capital on trying to fix it, which is incredibly stressful, slow, and unrewarding work. After a few months of this, I finally came to my senses and realized that, this not being my company, I would not accrue any of the benefits of improving their processes. Time to leave.

The lesson, for me, has been to avoid working at companies that are either not product-focused (in which case engineering is just a cost-centre, having extremely low status within the organization), and to avoid stubbornly non-technical founders (i.e. any founder/owner who refuses to care about their engineering department beyond asking "is it done yet?").

Re: The Framing of the Developer

#52

Post by allgreed »

blueboo wrote: post #9

If a prioritized list of not-yet-implemented features and issues is unhelpfully called a “backlog”, what should it be called? An “impact queue”? An “improvement roadmap”? Is this just a matter of language?

I've managed a few projects and IMO the state of the art in terms of wording is "ideas" for the long list of tasks that might be a good >ideaplanAs for your a bit sarcastic proposals [did I read that correctly?], I see the following problems: - "queue" implies meaningful ordering and you don't get to skip or totally rearrange a queue without a good reason in most situations that involve a queue - "roadmap" according to Cambridge dictionary is a form of plan, which doesn't quite cut if for describing the can-be-postponed-without-consequences part of the backlog.

Regarding the matter of language: I'm assuming [in this context] the presupposition that words are tools. And you can do a good job with crappy tools and vice versa. Yet there is a correlation between tool quality and the outcome. Example: the WIP limit in kanban - sometimes referred to as "work in progress limit". Why the hell would you like to limit progress? But when you change it to "in process" the whole concept suddenly makes a lot more sense. If everything is in process nothing will ever get done, so putting a limit on that ensures output.

Re: The Framing of the Developer

#53

Post by zeku »

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…

If you head to youtube and lookup a channel called something like: JomaTech you will find a guy who just recently quit Facebook. He was a Data Scientist Analyst as they call it there(according to him).

It seemed he liked working at FB but he mentioned several times how your impact is your tracked metric and if you didn't have impact then who cares what you're doing.

I think it can be flawed because if your team doesn't like you and youre a Data Scientist? Well now they aren't going to listen to your compelling data and your impact is a 0. Or if they have some other motive, it could even be one person with power on your team!

Obviously I'm describing the worst, but it seems a flawed system.

Re: The Framing of the Developer

#54

Post by hinkley »

pacala wrote: post #46
TheOtherHobbes wrote: post #43

Earlier quoted context omitted.

That's because "bringing value to the business" is confused with "increasing quarterly profits." The problem is poor valuation. All of the above can be process lubrication. The actual value comes from the process that goes on top of them. But if they're not in place, process implementation is going to have a lot of unnecessary friction, which reduces the eventual value of the core business process. Some businesses ge…

Exactly right. Building cowboy software with intense schedule pressure and best practices corner cutting it's likely to give you both late releases and bug backlog long enough to circle Earth three times. There will be more bugs, and bugs will be more time-consuming to fix.

And the people who could rectify the situation get the message that their opinions/judgement aren’t valued and give up or go to work someplace else.

I think perhaps people don’t realize that “you get what you measure” has deeper layers to it. You get actions, you get people who are comfortable with those actions, and then you get friction to change this new status quo.

Re: The Framing of the Developer

#55

Post by coldcode »

dangrover wrote: post #18

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 detai…

Maybe you work in a sane company. I work in a company where every freaking VP, SVP, EVP, P and various C wants something different and battles between themselves; all the while we are trying to develop the last thing anyone said, right up until it all changes. We spent 18 months on a single project in which change accelerated over time, every single feature changed in radical ways, and then in the last 3-4 months they insisted that since we hadn't shipped anything we would need to work extra hard on the latest set of things or there would be hell to pay. And then when we got it done anyway cancelled the whole project on the day before the CEO announcement–so they could start on yet another one of these that someone had convinced them was better. Sigh.

Re: The Framing of the Developer

#56

Post by hinkley »

29athrowaway wrote: post #16

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 engineeri…

We used to have a QA manager to tag team with, but they got rid of QA and we happily obliged. Once in a while you could rely on the operations/IT people for this, but we are trying to get rid of them as well.

So far this is really working out well for managers.

Re: The Framing of the Developer

#57

Post by tstrimple »

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…

One thing I learned at my time at Microsoft is when a measurement becomes a metric, it ceases to be a good measurement. So much effort goes into gaming metrics which roll up to impact people's salaries that you can no longer really trust the results.

Re: The Framing of the Developer

#58

Post by AmericanChopper »

luckylion wrote: post #37
AmericanChopper wrote: post #26

Earlier quoted context omitted.

> if they endanger the product in a way only engineers can understand If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership. I can’t think of any examples critical risks I’ve encountered that couldn’t be communicated concisely to non-technical stakeholders.

> If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership. Or extremely incompetent PMs. I've had one PM be confronted with the documentation of something where it clearly said "don't do this, it's wrong and will ruin everything" (which, totally by coincidence, is what he was told by someone on the team before). He still demanded it to be done because he had…

But you’re not talking about a risk that only an engineer can understand. You’re talking about a risk that somebody else in the organisation is trying to hide from their own boss. Which is a completely different thing.

Re: The Framing of the Developer

#59

Post by SkyBelow »

mikekchar wrote: post #24
marcus_holmes wrote: post #20

Earlier quoted context omitted.

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.

I can understand what you are saying, but there are some very subtle and difficult things in the world. The fact that only a very few people in the world can be successful with the things that make a concert pianist successful does not mean that concert pianists have failed. I will absolutely agree that XP is not a discipline for the masses, but it is incredibly effective for those who are able to use it well (to the…

>The fact that only a very few people in the world can be successful with the things that make a concert pianist successful does not mean that concert pianists have failed.

Or does it mean they have failed at making a guide?

If you have a guide 'how to be a professional concert pianist' and people who faithfully follow it only have a 1 in a 1000 chance of succeeding, perhaps it is a bad guide. Now, maybe everything in the guide is necessary, but it isn't sufficient. It may also be the best guide around, as every other has a success rate of 1 in 10,000 or worse. However that doesn't mean it is a successful guide. It is still failing to capture something that is needed to become a successful guide that can be spread to the masses.

If it is guide for how a successful pianist can become even better, then perhaps it is a problem of too many people thinking themselves successful pianist when they aren't. So maybe what we need is to better focus on identifying which organizations aren't mature enough to adopt something like XP so they stop trying out a path that will fail because they aren't ready for it.

Re: The Framing of the Developer

#60

Post by AmericanChopper »

29athrowaway wrote: post #49
AmericanChopper wrote: post #26

Earlier quoted context omitted.

> if they endanger the product in a way only engineers can understand If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership. I can’t think of any examples critical risks I’ve encountered that couldn’t be communicated concisely to non-technical stakeholders.

For every position, there is a chance of a bad hire. PMs are no exception. Every productive employee has a chance of losing motivation and start underperforming. Again, PMs are no exception. You organization needs ways to detect and "fix" situations caused by a person not living up to their role. Balance of power between product and engineering is one of such circuit breakers.

A balance of power between engineering and product ownership is a terrible idea. The role of engineer doesn’t necessarily require any understanding of the customers needs. If you have an engineering team that understands them well, it’s either because of competent product ownership, or it’s a complete coincidence. Engineering should not have control over what is built, or have the power to override product owner’s decisions. Product owners should not have control over how things are built, or the ability to override engineering leadership’s decisions. They’re simply different areas of responsibility, there is no need at all for a balance in power between the two, and creating one for the purpose of avoiding bad decisions is just as likely to be used for avoiding good decisions, or decisions that conflict with somebody’s personal taste or political objectives.
Post reply on HN