7 ms·

The Framing of the Developer

175 points by KingOfCoders 7y ago

bryanrasmussen 7y ago
Actually I don't think of an elephant when you tell me not to think of an elephant, I think of the word elephant, specifically "huh, they said don't think of an elephant, now they are going to say see you can't stop thinking of elephants but I'm only thinking of the word and not thinking of the object. Why is that?"
narag 7y ago
I've never been in a place where it was pretended that there is no person with authority to tell you what to do, whatever that person is called, and that person's ass is the one that's kicked in case things don't work. What this article describes is alien to me: an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. There are multiple problems with that system. From the outside you can ask without concerning yourself with priorities or tradeoffs. From the inside, different persons can push in different directions.
- routerl 7y ago
  an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. I've just left a place like this, largely for this reason. Someone with impressive credentials was hired by the senior leadership and given project ownership. The problem is that neither this person's education, nor their work experience, had anything to do with software; they'd never worked on a software project before. Relatively quickly, I started noticing exactly the dynamic you've described. If the backlog was growing (which it always is), engineering would get reprimanded and have the whip cracked on us. But when we'd reach objectives, we'd get no recognition or even acknowledgement, while the "product owner" would get showered in praise. After passing our first major feature milestone, the "product owner" was literally greeted with a bottle of champagne on their desk. It took me a few weeks (read: too long) to trust my perception that most of the "delays" came from how terribly the requirements were written, and how often they changed for arbitrary reasons that created no value. 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". In retrospect, I was in the exact no-win scenario you described, in which my team owned every failure but no successes.
  - qw 7y ago
    > 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 according to how you understand it and ask directly ("Is my understanding correct"). If the PO changes its mind, document that as well. It shouldn't be necessary, and in many companies it is not, but some environments are toxic.
    - JoshuaDavid 7y ago
      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 because the question had to be answered one way or the other, so they flipped a coin (and thus there is no special reason to believe changing it is dangerous). Always document product decisions. "Documenting" doesn't have to be a big process, and you don't really need to make polished documentation, but at the very least dump your notes from when decisions are made somewhere permanent and searchable (github comments / jira comments / even slack messages in a non-dm channel count). Your future self will thank you.
      - routerl 7y ago
        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?").
quickthrower2 7y ago
There is always a backlog and product manager. Roles! Not necessarily job titles. The question is who is / are managing the backlog and what criteria they use. If you claim to have no backlog then you basically come to work each day fresh and choose something to work on - but don’t plan on continuing that tomorrow because to do so would mean you actually do have a backlog! It might not be a Jira backlog but it exists in the minds of the devs at least. So if we have a backlog then who should control it? Good question and it depends on the company and the skills of the staff including the developers. It also depends on how much it is wanted that developers do business strategy and to what degree they do it. Leaving it all to a product owner can be OK if they do their job properly and understand the technical trade offs and really listen to both the technical and business sides. It can’t just be chucking shit in the backlog. So, like nosql vs. vim or tabs vs. microservices, it’s going to be another horses for courses, best tool for the job kind of decision. Each company needs to carefully consider their strategy for basically: deciding what to work on.
mikekchar 7y ago
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 pairs of programmers, if they are not changing pairing partners regularly, if the developers are not co-located and importantly coding at core hours, if you are not TDDing your code, if you are not ruthlessly refactoring, if you are not integrating all of your code several times a day (I like several times an hour!), etc, etc, etc, then you are not doing XP. I think its very fair to say that XP as a movement has failed, although I think it has contributed mightly to the tool chest of developers. I do also think it's fair to call out XP on its lack of program management. Any successful XP team needs to sort that out and leaving it to the programmers is rarely the correct solution. Just my usual rant on this topic :-). I'm sure it is surprising to many people that XP can be wildly successful, so I try to speak up when I see this repeated.
- marcus_holmes 7y ago
  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.
  - mikekchar 7y ago
    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 extent that it covers -- there are lots of areas of software development that XP does not cover at all and where you can fail easily while still using XP). I think one of the problems with XP as a movement was that it actually became more vague over time. I actually think that the original 12 rules are better than the current 12 rules. I have implemented XP in real situations using real people with real politics and management issues. It has worked incredibly well for me. It does not work in all situations and all political environments with all management issues. You need to be very careful when selecting XP to make sure that the situation you are using it in is appropriate.
iphone_elegance 7y ago
I'm eagerly awaiting the next project management fad to make writing software less enjoyable.
gregdoesit 7y ago
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 were created by engineers, not product managers. Newsfeed. GraphQL. A/B testing frameworks. The difficulty comes both when growth slows - and it’s hard to have impact without cannibalising another team’s impact - as well as when having more impact actually causes harm to the company on a different direction. While engineers were optimising for engagement, tweaking the news feed algorithm to show items you were likely to click on, sensationalist content (sometimes: fake news) was over-promoted. While the ads team optimised for ad engagement by exposing various metrics, they exposed metrics that turned to public uproar later on. The idea of only optimising for impact is a great short-term strategy. Long-term it is not nearly as black-and-white. 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.
- jbay808 7y ago
  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.
- CoolGuySteve 7y ago
  I always think of the Business Dudes episode of Adventure Time: https://www.youtube.com/watch?v=_mxB_OlSsKI 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!"
- davedx 7y ago
  > 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.
Supermancho 7y ago
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 things. The frame says: Finishing means success. If we work from the backlog, we’ll have success. If we complete all the things I as a product owner have in my vision, we will have success. > If a product fails in this frame, it is because we have not implemented the whole vision of the product manager. No. It's a plan of things that the team might do. The backlog (and if you're lucky, the prioritization) is ever-changing. Many of the planned features aren't even controlled by the product manager, but by other dependencies (teams, markets, etc). This is why the product owner and product manager ends up being the same solitary role. It's efficient. You can pursue building ANYTHING FOREVER, so it doesn't even make sense to claim the backlog is a goal/finish line. > In the backlog frame success is tied to implementing the items of the backlog. No, that's your frame. It's not the paradigm. I like product managers. It's not my business to work harder, because I have an eventual productivity cadence (from collected metrics) which is what they have to work with and communicate to interested parties. Other than some light competition between peers, I'm not responsible for pushing to meet arbitrary goals. Everything is a negotiation. As a resource, I am what I am and we're all working together.
- luckylion 7y ago
  It's PR/link bait for Startup Coaching, don't read too much into it.
blueboo 7y ago
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?
- allgreed 7y ago
  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 >idea< to maybe do sometime in the future and "plans" for the shortlist of concrete activities that we >plan< to implement soon. As 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.
jzer0cool 7y ago
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.
29athrowaway 7y ago
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.
- AmericanChopper 7y ago
  > 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.
  - luckylion 7y ago
    > 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 heard a talk at some conference where that was recommended. It took getting the CEO into the issue via back channels to clear that out. Imho the percentage of PMs, POs etc that have no clue what they are doing is much, much higher than in any technical role. If they're good at bullshitting, they can usually talk their way out of being blamed for their failure and switch to a different company later.
    - AmericanChopper 7y ago
      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.
ciprian_craciun 7y ago
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.
dangrover 7y ago
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.
- coldcode 7y ago
  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.
  - Gollapalli 7y ago
    ... was this a software company? That’s horrifying.
    - coldcode 7y ago
      Our business uses a lot of in house (and out house) software, but we don't sell software or hardware.
cousin_it 7y ago
I don't understand why 1) developers are promoted based on impact 2) developers are given tasks by PMs 3) PMs choose tasks based on impact. This makes no sense to me. Either get rid of the PM role and put engineers in control of choosing impactful tasks, or change the promotion criteria.
bob1029 7y ago
This seems like such an obvious thing to me. When an issue comes up for prioritization during review, we simply ask "What value does this bring to the business". Every single meandering bullshit conversational path we happen to find ourselves upon can be immediately curtailed by stating these words. Technical folks may not like hearing it all the time, and it doesn't necessarily have to be the dominating factor 100% of the time (i.e. side-projects, 20% time code activities, etc). But, this is the penultimate tool for ending arguments and separating the bullshit from the reason people are receiving paychecks. Very scary time-crunch episodes can in many cases be diffused by simply going to the customer and asking them, "Out of these 10 things, if you could have 3 by the end of the month, which would you pick?" I think you would instantly get a picture of how you should prioritize your efforts to drive value for them. I strongly suspect that if you can meet incremental targets in descending order of value (as perceived by the customer), you can keep virtually anyone happy. Hitting customer targets successfully is also very good for morale and can further compound productivity on all ends.
- ikiris 7y ago
  This kind of thinking is how you run a good business into the ground chasing local maxima. Ask Kodak
- commandlinefan 7y ago
  "We need to add unit tests" "That brings no value to the business!" "We need continuous integration" "That brings no value to the business!" "We need version control" "That brings no value to the business!" "We need to upgrade from JDK 1.4" "That brings no value to the business!" "We need to safeguard user's data" "That brings no value to the business!" And on, and on, and on.
  - marcosdumay 7y ago
    Yes, that's how that question is normally used. But it's a lie, those often bring value to the business. If you are trying to answer it honestly, you will certainly get better results. But I am still not sure it won't bias you in a harmful direction.
wrnr 7y ago
Developers are not the audience of this article but it's subject, it's written for C-level executives, the targeted market of the company.
nobodywillobsrv 7y ago
All this discussion gets things wrong. Bring back negative feed back and pain to stake-holders. Creator must take the bullet. IT what happens when executive slaves want the paycheck without the responsibility. Failure to test organizations is another main problem. Can one person make a small change quickly? No? Then delete. Try again. Burn it down.
ascotan 7y ago
Interesting article, however I have a different take on it. Agile/XP was originally envisioned to reduce the impact of middle management/business processes on software development and put the customer and developer together to get things done. During the early days of XP/Agile this worked in certain areas where it was feasible to do so and there were not a lot of already establish business processes and business people who had a vested interested in preventing it. At some point middle/product/project managers realized that this was just another business process and adopted and morphed it as their own. Although agile was invented and made for developers, today only non-engineers are involved in 'agile'. As a result we have craziness like scrum master as a full-time non-development job that requires certification from a business process body. Additionally the process people have added a ton of process cruft (burn down charts, playing poker with card decks, etc.) All of which is mostly unnecessary business processes. So we're back to where we were before and developers and customers continue to be separated from each other. In the new world, engineering leadership is being replaced by non-technical business people with certifications. The has lead to less skilled teams of 'developers and testers' that are no longer guided by highly technical engineers that have either actual or perceived power in the organization. The net result of all of this is that developers are struggling in many orgs.
frandroid 7y ago
> I always wondered why it isn’t called “product debt” because product took the credit to get a feature faster and must pay back by investing the time to clean up. Technology is the bank that gave credit. I would expect massive pushback trying to push this framing...

175 points by KingOfCoders 7y ago

Actually I don't think of an elephant when you tell me not to think of an elephant, I think of the word elephant, specifically "huh, they said don't think of an elephant, now they are going to say see you can't stop thinking of elephants but I'm only thinking of the word and not thinking of the object. Why is that?"

narag 7y ago

I've never been in a place where it was pretended that there is no person with authority to tell you what to do, whatever that person is called, and that person's ass is the one that's kicked in case things don't work. What this article describes is alien to me: an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. There are multiple problems with that system. From the outside you can ask without concerning yourself with priorities or tradeoffs. From the inside, different persons can push in different directions.

routerl 7y ago
an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. I've just left a place like this, largely for this reason. Someone with impressive credentials was hired by the senior leadership and given project ownership. The problem is that neither this person's education, nor their work experience, had anything to do with software; they'd never worked on a software project before. Relatively quickly, I started noticing exactly the dynamic you've described. If the backlog was growing (which it always is), engineering would get reprimanded and have the whip cracked on us. But when we'd reach objectives, we'd get no recognition or even acknowledgement, while the "product owner" would get showered in praise. After passing our first major feature milestone, the "product owner" was literally greeted with a bottle of champagne on their desk. It took me a few weeks (read: too long) to trust my perception that most of the "delays" came from how terribly the requirements were written, and how often they changed for arbitrary reasons that created no value. 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". In retrospect, I was in the exact no-win scenario you described, in which my team owned every failure but no successes.
- qw 7y ago
  > 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 according to how you understand it and ask directly ("Is my understanding correct"). If the PO changes its mind, document that as well. It shouldn't be necessary, and in many companies it is not, but some environments are toxic.
  - JoshuaDavid 7y ago
    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 because the question had to be answered one way or the other, so they flipped a coin (and thus there is no special reason to believe changing it is dangerous). Always document product decisions. "Documenting" doesn't have to be a big process, and you don't really need to make polished documentation, but at the very least dump your notes from when decisions are made somewhere permanent and searchable (github comments / jira comments / even slack messages in a non-dm channel count). Your future self will thank you.
    - routerl 7y ago
      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?").

quickthrower2 7y ago

There is always a backlog and product manager. Roles! Not necessarily job titles. The question is who is / are managing the backlog and what criteria they use. If you claim to have no backlog then you basically come to work each day fresh and choose something to work on - but don’t plan on continuing that tomorrow because to do so would mean you actually do have a backlog! It might not be a Jira backlog but it exists in the minds of the devs at least. So if we have a backlog then who should control it? Good question and it depends on the company and the skills of the staff including the developers. It also depends on how much it is wanted that developers do business strategy and to what degree they do it. Leaving it all to a product owner can be OK if they do their job properly and understand the technical trade offs and really listen to both the technical and business sides. It can’t just be chucking shit in the backlog. So, like nosql vs. vim or tabs vs. microservices, it’s going to be another horses for courses, best tool for the job kind of decision. Each company needs to carefully consider their strategy for basically: deciding what to work on.

mikekchar 7y ago

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 pairs of programmers, if they are not changing pairing partners regularly, if the developers are not co-located and importantly coding at core hours, if you are not TDDing your code, if you are not ruthlessly refactoring, if you are not integrating all of your code several times a day (I like several times an hour!), etc, etc, etc, then you are not doing XP. I think its very fair to say that XP as a movement has failed, although I think it has contributed mightly to the tool chest of developers. I do also think it's fair to call out XP on its lack of program management. Any successful XP team needs to sort that out and leaving it to the programmers is rarely the correct solution. Just my usual rant on this topic :-). I'm sure it is surprising to many people that XP can be wildly successful, so I try to speak up when I see this repeated.

marcus_holmes 7y ago
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.
- mikekchar 7y ago
  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 extent that it covers -- there are lots of areas of software development that XP does not cover at all and where you can fail easily while still using XP). I think one of the problems with XP as a movement was that it actually became more vague over time. I actually think that the original 12 rules are better than the current 12 rules. I have implemented XP in real situations using real people with real politics and management issues. It has worked incredibly well for me. It does not work in all situations and all political environments with all management issues. You need to be very careful when selecting XP to make sure that the situation you are using it in is appropriate.

iphone_elegance 7y ago

I'm eagerly awaiting the next project management fad to make writing software less enjoyable.

gregdoesit 7y ago

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 were created by engineers, not product managers. Newsfeed. GraphQL. A/B testing frameworks. The difficulty comes both when growth slows - and it’s hard to have impact without cannibalising another team’s impact - as well as when having more impact actually causes harm to the company on a different direction. While engineers were optimising for engagement, tweaking the news feed algorithm to show items you were likely to click on, sensationalist content (sometimes: fake news) was over-promoted. While the ads team optimised for ad engagement by exposing various metrics, they exposed metrics that turned to public uproar later on. The idea of only optimising for impact is a great short-term strategy. Long-term it is not nearly as black-and-white. 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.

jbay808 7y ago
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.
CoolGuySteve 7y ago
I always think of the Business Dudes episode of Adventure Time: https://www.youtube.com/watch?v=_mxB_OlSsKI 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!"
davedx 7y ago
> 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.

Supermancho 7y ago

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 things. The frame says: Finishing means success. If we work from the backlog, we’ll have success. If we complete all the things I as a product owner have in my vision, we will have success. > If a product fails in this frame, it is because we have not implemented the whole vision of the product manager. No. It's a plan of things that the team might do. The backlog (and if you're lucky, the prioritization) is ever-changing. Many of the planned features aren't even controlled by the product manager, but by other dependencies (teams, markets, etc). This is why the product owner and product manager ends up being the same solitary role. It's efficient. You can pursue building ANYTHING FOREVER, so it doesn't even make sense to claim the backlog is a goal/finish line. > In the backlog frame success is tied to implementing the items of the backlog. No, that's your frame. It's not the paradigm. I like product managers. It's not my business to work harder, because I have an eventual productivity cadence (from collected metrics) which is what they have to work with and communicate to interested parties. Other than some light competition between peers, I'm not responsible for pushing to meet arbitrary goals. Everything is a negotiation. As a resource, I am what I am and we're all working together.

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

blueboo 7y ago

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?

allgreed 7y ago
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 >idea< to maybe do sometime in the future and "plans" for the shortlist of concrete activities that we >plan< to implement soon. As 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.

jzer0cool 7y ago

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.

29athrowaway 7y ago

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.

AmericanChopper 7y ago
> 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.
- luckylion 7y ago
  > 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 heard a talk at some conference where that was recommended. It took getting the CEO into the issue via back channels to clear that out. Imho the percentage of PMs, POs etc that have no clue what they are doing is much, much higher than in any technical role. If they're good at bullshitting, they can usually talk their way out of being blamed for their failure and switch to a different company later.
  - AmericanChopper 7y ago
    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.

ciprian_craciun 7y ago

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.

dangrover 7y ago

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.

coldcode 7y ago
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.
- Gollapalli 7y ago
  ... was this a software company? That’s horrifying.
  - coldcode 7y ago
    Our business uses a lot of in house (and out house) software, but we don't sell software or hardware.

cousin_it 7y ago

I don't understand why 1) developers are promoted based on impact 2) developers are given tasks by PMs 3) PMs choose tasks based on impact. This makes no sense to me. Either get rid of the PM role and put engineers in control of choosing impactful tasks, or change the promotion criteria.

bob1029 7y ago

This seems like such an obvious thing to me. When an issue comes up for prioritization during review, we simply ask "What value does this bring to the business". Every single meandering bullshit conversational path we happen to find ourselves upon can be immediately curtailed by stating these words. Technical folks may not like hearing it all the time, and it doesn't necessarily have to be the dominating factor 100% of the time (i.e. side-projects, 20% time code activities, etc). But, this is the penultimate tool for ending arguments and separating the bullshit from the reason people are receiving paychecks. Very scary time-crunch episodes can in many cases be diffused by simply going to the customer and asking them, "Out of these 10 things, if you could have 3 by the end of the month, which would you pick?" I think you would instantly get a picture of how you should prioritize your efforts to drive value for them. I strongly suspect that if you can meet incremental targets in descending order of value (as perceived by the customer), you can keep virtually anyone happy. Hitting customer targets successfully is also very good for morale and can further compound productivity on all ends.

ikiris 7y ago
This kind of thinking is how you run a good business into the ground chasing local maxima. Ask Kodak
commandlinefan 7y ago
"We need to add unit tests" "That brings no value to the business!" "We need continuous integration" "That brings no value to the business!" "We need version control" "That brings no value to the business!" "We need to upgrade from JDK 1.4" "That brings no value to the business!" "We need to safeguard user's data" "That brings no value to the business!" And on, and on, and on.
- marcosdumay 7y ago
  Yes, that's how that question is normally used. But it's a lie, those often bring value to the business. If you are trying to answer it honestly, you will certainly get better results. But I am still not sure it won't bias you in a harmful direction.

wrnr 7y ago

Developers are not the audience of this article but it's subject, it's written for C-level executives, the targeted market of the company.

nobodywillobsrv 7y ago

All this discussion gets things wrong. Bring back negative feed back and pain to stake-holders. Creator must take the bullet. IT what happens when executive slaves want the paycheck without the responsibility. Failure to test organizations is another main problem. Can one person make a small change quickly? No? Then delete. Try again. Burn it down.

ascotan 7y ago

Interesting article, however I have a different take on it. Agile/XP was originally envisioned to reduce the impact of middle management/business processes on software development and put the customer and developer together to get things done. During the early days of XP/Agile this worked in certain areas where it was feasible to do so and there were not a lot of already establish business processes and business people who had a vested interested in preventing it. At some point middle/product/project managers realized that this was just another business process and adopted and morphed it as their own. Although agile was invented and made for developers, today only non-engineers are involved in 'agile'. As a result we have craziness like scrum master as a full-time non-development job that requires certification from a business process body. Additionally the process people have added a ton of process cruft (burn down charts, playing poker with card decks, etc.) All of which is mostly unnecessary business processes. So we're back to where we were before and developers and customers continue to be separated from each other. In the new world, engineering leadership is being replaced by non-technical business people with certifications. The has lead to less skilled teams of 'developers and testers' that are no longer guided by highly technical engineers that have either actual or perceived power in the organization. The net result of all of this is that developers are struggling in many orgs.

frandroid 7y ago

> I always wondered why it isn’t called “product debt” because product took the credit to get a feature faster and must pay back by investing the time to clean up. Technology is the bank that gave credit. I would expect massive pushback trying to push this framing...