Things to think

  • Engineering productivity can be measured is a bold statement, after so many years of trying to quantify software development. In this article, the author states that most metrics you try to get from a team, can - and will be challenged by engineers. The most simple example is to measure lines of code. Engineeres will find ways to improve the number of lines of code tremendously, without affecting effectivity. On the other hand, not measuring at all won't help either. The bottom line of the article is to measure blockers:

Engineering should instead be about effectiveness: "How able is this engineer to effect positive impact?"

  • Quality of developer tools
  • Frequency and quality of internal activities (like meetings or code reviews)
  • Focused maker time (free from disruptive meetings)
  • Easy access to documentation
  • Psychological safety on the team
  • Work-life balance
  • Presence of other high-performers
  • A fair system of rewards

Screenshot from a talk Gunter Dueck gave about Intrapreneuring

Intrapreneur's Commandments

Documentation done right

There are four categories of documentation:

  • Tutorials (learning oriented)
  • How-to guides (problem oriented)
  • Reference (information oriented)
  • Discussions (understanding oriented)

These categories need structurally be kept apart.

Tutorials

Tutorials are supposed to be the hardest part of a documentation to create. Let a beginner do an exercise to learn using the software. The point is practical knowledge, not theoretical knowledge. Tutorials need to be concrete and not abstract. There should be no explanation. There should be no options or choices of the path. The tutorial writer is in charge of that path. The tutorial must be reproducable under all circumstances.

How-to guides

Recipes to solve a problem to achieve an outcome. In contrast to a tutorial, the learner would not even be able to formulate a problem to solve. How-to guides do not need to start at the beginning. They can assume basic knowledge of the domain. Again, no explanations. They get in the way of actions. Choose practicability over completeness.

Reference

References are purely descriptive. They are supposed to describe the machinery. A reference should not explain what can be assumed as general knowledge of the topic. The reference’s structure should resemble the code base. The wording should be consistent.

Discussions / Background material / Explanation

Clarify and illuminate a topic. Give context and discuss alternatives. Outline conflicting opinions. Make connections. It should not contain guides or technical reference.

Reference

Why incentive plans cannot work

This is an article by Alfie Kohn published in 1993 in the Harvard Business Review Magazine. It cought my interest because of its relevance today.

Kohn claims that many companies and their managers believe in a reward system to motivate employees for better performance. He gives a number of reasons, based on scientific research, for rewards to miss the point every time. Rewards are for example

piece-work pay for factory workers, stock options for top executives, special privileges accorded to Employees of the Month, and commissions for salespeople

Rewards only achieve one thing: temporary compliance. They will lead to movement but not motivation. So the question is, do we strive for excellence? For long term growth? Or just for a quick, short-term goal.

Rewards do not create a lasting commitment. They merely, and temporarily, change what we do.

At least two dozen studies have shown that rewards will not lead to better outcomes. A study by McKinsey could not find any difference in return for shareholders among 90 companies that use rewards and those which don't.

  • People doing excellent work are not driven by money. They are excellent because they intrinsically love what they do.
  • Rewards and Punishment are two sides of the same coin. They are manipulative. Being controlled has a punitive character over time. Not receiving an expexted reward has the same effect as a punishment. This ultimately leads to a controlled workplace and not one that empowers learning, exploration and progress.
  • Rewards only know winners and losers. They divide what was used to be a team into rewarded and punished people.
  • Rewards hide underlying reasons. It is not wise to introduce rewards if there are causes for bad performance. Reasons for bad performance, among others, are too strict hierarchies, workers unable to collaborate, inadequatly prepared workers for the job, sacrifice long-term growth for short-term goals.
  • Rewards discourage risk taking. With "This for that", people facing a reward will focus on the "this", not the "that".
  • Any form of pay-per-performance makes people less enthusiastic. There are a few theories trying to explain this observed behaviour.

The number one casualty of rewards is creativity. As the late John Condry put it, rewards are the “enemies of exploration.”