The four dangerous animals of product development

> Having a clearly defined prioritization process can help ensure all your team members understand how decisions are made and give them the confidence to actively participate.

"The boss said we have to do X" is a clearly defined prioritization process. Now go tell your team members that's how decisions are made (note the passive voice) and tell them to get on it already ("give them the confidence to actively participate").

“Why everybody sucks but you” “How to point out problems and suggest vague, empty solutions” “We asked GPT-3 to write an inane thought leadership piece”

Yep, stopped giving any credence to this article after this line.

In practice, data-driven is extremely hard. Most A/B testing is blindness dressed in nice clothes.

Data-driven is only cost-effective at some (large) scale, because you'll need actual experts and infrastructure.

Which has a lot more detail to it

> WOLF – Working On the Latest Fire

A long time ago, I was briefly involved with an organization in which management of software projects worked like this:

* Lots of projects were started and promised to stakeholders. Money was, most of the time, not really an issue because of the organizations size and various kinds of cash-flow.

* Marketing was always over-promising stuff which could be done. Lots of bingo words. Huge weight on design and leaflets.

* The organization was a matrix organization with, like, 100 people serving 30 or 40 projects. Developers were regularly pressed or shanghaied to take on more projects (the more senior developers had perhaps twenty or thirty projects they were participating in) which of course took focus off the running projects.

* Starting one's participation happened usually by sending people an electronic invitation in some kind of kick-off meeting in which they were more or less expected to participate, and telling them about their work package. It was considered inappropriate, almost rude, to say no. There would be no documentation or task defined in writing. People would meet a few times to vaguely discuss how things were going (using some kind of agile task chart), and point out dead-lines, but with nothing really concrete about the technical stuff.

* The idea was, I believe, that with so many people doing so many projects, it would help enormously if people joined and gathered knowledge from different projects in a synergy effect. One was always allowed to ask more experienced people for help. This happened mainly by submitting support tickets into a big bug-tracking system. Each ticket was assigned to a team working on the topic.

* The main idea to cope with all the projects at the same time was to modularize everything as to make it re-usable for different projects. Unfortunately, there was, however, very little time to define interfaces or APIs between these components.

* There was also the minor problem that it was somehow hard to retain people. One reason might have been the payment structure, or the career opportunities. There happened to be companies in the direct neighborhood which were paying substantially better. However, there were some senior die-hard staff members which were valiantly holding the flag. Unfortunately, the senior members were severely overloaded. They did not even came around to document basic processes. Unfortunately, that further increased their workload.

* When working on a project, sooner or later, one would run into a couple of issues which had no obvious answer. One would file them into the ticket system. A few of them would be answered, but not all, because of the overload of the other members. Then, one would become blocked. The best thing one could do was, to work on another topic. That was heavily encouraged by the creation of more tasks and projects. Now, think in a distributed system with lots of locks and messages and procedures in some kind of spaghetti graph. Because, from a certain point, other people would depend on one's own contribution, this could have the result that the whole project dead-locked without anyone really noticing. How would people have noticed? Everyone was very busy! Usually, such a stalled project would be kicked to run again two or three months later if some deadline was approaching or some report due.

* When these issues were brought up with lower managers, it was rather evident that they were aware of the problem. However, conversations about that ended all-too-often with the suggestion to pick up on a further project. So, it felt a bit like as if critical feedback up the command chain was not possible, or at least strongly undesired.

* Surprisingly, the result all of these efforts did not matter that much. It was somehow good enough to keep the organization going. One reason for this was surely that software was not an important product of the organization, or at least the top managers had the view that it was not a main priority.

With the distance of a few years, I am wondering if this structure was perhaps actually caused by some kind of micro-management. It was clear to me that the most developers would have hugely preferred to work on a much smaller number of projects. What would support this view is the experince how much organizations are often generally influenced by the top decision-making people.

On the other hand, I've come to the conclusion that most seemingly dysfunctions in organizations, or their parts, might have deeper causes, and, in a way, good reasons, in how the organization procures resources. What happens is inevitably also an optimization of this procurement of resources and of what is perceived as important.

Anyway, I'd be curious whether this kind of management pertains to some kind of pattern, and what is perhaps the best course of action one could take as a new developer in such a case. (I was pretty conflict-avoidant at that age, and I left that organization rather quickly, in spite of what could have been, at a technical level, rather interesting work).