Links

Think of me as a web crawler with taste.

It’s Time to Accept That Pay for Performance Doesn’t Work

Roger Martin:

First, PfP is an extremely blunt instrument. Roy’s machine shop illustrates it well. The incentive doesn’t skew behavior a bit: it skews behavior immensely. Almost half of the total observations are in a narrow band around the rerate line. And it isn’t even a management-defined line. It is the guesstimate of workers as to at what point management might take deleterious action. Management isn’t even in control of the impacts of its own system.

CUPID—for Joyful Coding

Dan North:

The five CUPID properties are:

  • Composable: plays well with others
  • Unix philosophy: does one thing well
  • Predictable: does what you expect
  • Idiomatic: feels natural
  • Domain-based: the solution domain models the problem domain in language and structure

Also this belter from Martin Fowler.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Alignment over Autonomy

Jean-Michel Lemieux:

“I thought that was my job — to take away all this crap from you and let you do your CEO thing. I thought you wanted me to be autonomous. I need autonomy.”

He said sure, but you should cheat “and use my brain to help you”.

Know How Your Organisation Works

Cindy Sridharan:

Unless you understand “why” things are the way they are (and there often is a method to every madness, if you’re patient to dig deep enough), any proposal you might have on “how” to improve the situation might end up very much going against the grain, making it that much more of an uphill task for your proposal to be accepted. Furthermore, it’ll make it seem as though you put in no effort to understand the history of the system, which doesn’t exactly breed a lot of confidence into why you should be entrusted with fixing the system.

On Being a Manager or Director

David Copeland:

And to make a long rambling story even longer and more rambling, being a manager or director or VP is kinda like this all the time. You just navigate fucked up policy after policy, deciding which pushback will work or which you have the energy for

And you will reach a limit because it’s fucking exhausting to unwind corporate cognitive dissonance all day every day, and so a bunch of unfair, ridiculous things just persist because you don’t have the mental wherewithal to keep fighting for everything.

(this is not even to account for doing the exact same thing for product and technical stuff on your team). Knowing your limit of this is a good indicator if you would succeed and enjoy management at any given scope of team/size of company

Encourage Management Collaboration to Integrate Leading and Serving Others

Johanna Rothman:

When managers collaborate, they can collaborate on the entire management job. That job is to create an environment where everyone can do succeed, in service of a greater goal.

Instead of changing the management structure, the organization can change the management collaboration.

Instead of separating leadership from serving people, integrate leadership and serving at all levels.

Everything Must Be Paid for Twice

David Cain:

One financial lesson they should teach in school is that most of the things we buy have to be paid for twice.

There’s the first price, usually paid in dollars, just to gain possession of the desired thing, whatever it is: a book, a budgeting app, a unicycle, a bundle of kale.

But then, in order to make use of the thing, you must also pay a second price. This is the effort and initiative required to gain its benefits, and it can be much higher than the first price.

But no matter how many cool things you acquire, you don’t gain any more time or energy with which to pay their second prices—to use the gym membership, to read the unabridged classics, to make the ukulele sound good—and so their rewards remain unredeemed.

To Share the Work, Share the Decisions

Jessica Kerr:

This is participatory sense-making. When we want to work on a thing together, and we need a shared understanding to do it right, then everyone gets to participate in constructing that understanding.

Shared understanding doesn’t come from “I share my understanding, and you adopt it.” it comes from “I share my knowledge, you share yours, and we construct a new understanding together.”

Accountability in Software Development

Kent Beck:

“Holding accountable” is code for blame, the attempt to avoid or deflect consequences. Blame is a weak premise from which to work. Blame requires that you spend time and energy protecting yourself. In an environment of blame it is not safe to say what you do and don’t know. Blame leaves everyone worried about who is out to get them. All the energy they spend hiding could be spent interacting and adding value to the project. Work gets done much less efficiently.

Accountability is a powerful premise from which to work. Working well and visibly builds strong relationships. Accepting responsibility sets the stage for satisfaction in a job well done. It’s a pity that the word “accountability” is misused, because the misuse obscures a useful concept.

Accountability can be offered, asked, even demanded, but it cannot be forced. “I hold you accountable,” doesn’t make sense. “I blame you,” or, “I hope you will accept the consequences,” are at least honest, even if they are a toxic basis for a working relationship. Managers can request or demand accountability. For example, a manager could ask that the software be ready to deploy at the end of every week so that the team’s progress is visible. From the other side, accountability can be offered even if it isn’t requested. “I can show you a log of how I spent my time last week,” is an offer of accountability.