Dan North:

The purpose of testing is to increase confidence for stakeholders through evidence.

…

You are testing if and only if you are increasing confidence for stakeholders through evidence.

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.

A snapshot of the planning process at Netflix, Mailchimp, Asana, LaunchDarkly, and more.

Practical experience of using Ray Dalio’s believability metric.

Bill Parcells:

The only way to change people is to tell them in the clearest possible terms what they’re doing wrong. And if they don’t want to listen, they don’t belong on the team.

Those turnarounds taught me a fundamental lesson about leadership: You have to be honest with people—brutally honest. You have to tell them the truth about their performance, you have to tell it to them face-to-face, and you have to tell it to them over and over again. Sometimes the truth will be painful, and sometimes saying it will lead to an uncomfortable confrontation. So be it. The only way to change people is to tell them in the clearest possible terms what they’re doing wrong. And if they don’t want to listen, they don’t belong on the team.

Andrew Harmel-Law:

The moves in software delivery towards ever-increasing team autonomy have, in my mind at least, heightened the need for more architectural thinking combined with alternative approaches to architectural decision-making.

Ensuring our software teams experience true autonomy raises a key problem: how might a small group of architects feed a significant number of hungry, value-stream-aligned teams? Why? Because in this environment Architects now need to be in many, many more places at once, doing all that traditional “architecture”.

…

The Rule: anyone can make an architectural decision.

The Qualifier: before making the decision, the decision-taker must consult two groups: The first is everyone who will be meaningfully affected by the decision. The second is people with expertise in the area the decision is being taken.

Yaniv Bernstein:

Once I took on board that it was my job as an engineer to actually deliver impact, provide value, then I became a lot more engaged with my cross-functional partners.

A look at some manager onboarding processes.

Good technical design decisions are very dependent on context. Teams that regularly work together on common goals are able to communicate regularly and negotiate changes quickly. These teams exhibit a strong force of alignment, and can make technology and design decisions that harness that strong force. As we zoom out in a larger organisation an increasingly weak force exists between teams and divisions that work independently and have less frequent collaboration. Recognising the differences in these strong and weak forces allows us to make better decisions and give better guidance for each level, allowing for more empowered teams that can move faster.

The Curse of Knowledge describes the cognitive bias or limitation that makes it very difficult for humans to imagine what it would be like not to possess a piece of information, and hence to properly put themselves in the shoes of somebody with less knowledge than them.

…

The first, and most important, is to overcommunicate. What exactly is meant by overcommunicating? To me, it is two things: (1) repeat your key messages a lot more often than seems reasonable or comfortable; and (2) when in doubt about whether your audience has a particular piece of important context, always err on the side of providing that context.

Overcommunication may seem inefficient but when it comes to communication, robustness is far more important than efficiency. Remember that the costs are asymmetric: communicate too much and you pay the cost of small amounts of wasted time, but communicate too little and it could lead to major disasters.

When you’re shaping an org in practice, the work you’re doing usually decomposes to manipulating three levers: structure, incentives, and culture (or, as Andy Grove puts it ‘contractual obligations, economic incentives, and culture’). A good org designer knows that they must pay attention to the interplay between all three elements.

…

I bring up the interplay between structure, incentives and culture because I think highlighting this interplay serves one other purpose: it enlarges the discourse around org design. If you focus on org structure alone, every solution to an org design problem is necessarily a restructuring. This is unrealistic. And, from experience, there are whole classes of problems that may be patched by a change to an incentive system or via a tweak to org culture instead.

The philosophy of games, why we play them, and how it relates to modern polarisation and conspiracy theories.

Breaking non-fiction books down into three kinds with advice on how to read them.

A look at how Etsy tailored their search results to individual customers.

Eugene Yan:

Rule #1: Don’t be afraid to launch a product without machine learning.

Machine learning is cool, but it requires data. Theoretically, you can take data from a different problem and then tweak the model for a new product, but this will likely underperform basic heuristics. If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.

To recharge themselves, individuals need to recognize the costs of energy-depleting behaviors and then take responsibility for changing them, regardless of the circumstances they’re facing.

The article covers four dimensions of energy: body, emotions, mind, and spirit.

George Fairbanks:

There are two parts to software development: creating a design and expressing it as code. The code is tangible but the design is conceptual. Keeping a project healthy means doing both well. Here’s my concern: whenever you mix the conceptual with the tangible, it’s easier to neglect the conceptual. When you miss a tangible target, it’s obvious, but when you miss a conceptual target, you might not recognize it, or might rationalize that, because it’s impossible to measure, you were really quite close.

Blindly applying a factory process to software development will drive improvements to the tangible part (the code) at the expense of the conceptual part (the design). We see plenty of examples of this today, where teams have great feature velocity at first, are puzzled when velocity slows, and eventually the project is abandoned. As Cunningham warned, if we bolt features onto an existing codebase without consolidating those ideas into the code, the design will suffer, and over time “[e]ntire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation.”

Casey Winters:

there’s one big thing that needs to change for wartime CPOs I want to cover today, and that is prioritization and evaluation.

Lara Hogan:

So, when a fraught issue arises, how can we help our organization move forward in a way that actually builds rather than breaks trust? Over time, and after many communication mistakes, I honed a four-part template, covering the following

Ryan Singer:

After I have a lay of the land, the next step is to determine what to work on first, second, third etc. Not every concern in the product provides equal value to the customer. Some parts are core to the problem. Without them the app has no purpose. Others are necessary but have nothing to do with the domain, like user-authentication.

Bungay Stanier explains how advice-giving goes bad; the three personas of your Advice Monster; and the powerful act of staying curious a little longer.

Jonathan Cornelissen:

Relegating all data knowledge to a handful of people within a company is problematic on many levels. Data scientists find it frustrating because it’s hard for them to communicate their findings to colleagues who lack basic data literacy. Business stakeholders are unhappy because data requests take too long to fulfill and often fail to answer the original questions. In some cases, that’s because the questioner failed to explain the question properly to the data scientist.

​…

A data-literate team makes better requests. Even a basic understanding of tools and resources greatly improves the quality of interaction among colleagues. When the “effort level” — the amount of back-and-forth needed to clarify what is wanted — of each request goes down, speed and quality go up.

​…

Shared skills improve workplace culture and results in another way, too: They improve mutual understanding. If you know how hard it will be to get a particular data output, you’ll adjust the way you interact with the people in charge of giving you that output. Such adjustments improve the workplace for everyone.

Liz Keogh:

As the Peter Principle suggests, we tend to rise to the level of our incompetence… but that’s not actually such a bad thing, as long as we can learn fast, safely. The best way to do that is to make sure things are safe-to-fail, which usually means putting appropriate feedback loops in place. In a human system, that usually means feedback.

…

Sometimes it’s the simplest thing in the world, and we forget to do it. Clarifying why you want something allows people to make autonomous decisions about how best to work towards the outcome you want; or (even more important) give you information about the context you were unaware of that will cause difficulty getting that outcome.

Timothy R. Clark:

Low-velocity decision making. In a nice culture, there’s pressure to go along to get along. A low tolerance for candor makes the necessary discussion and analysis for decision making shallow and slow. You either get an echo chamber in which the homogenization of thought gives you a flawed decision, or you conduct what seem to be endless rounds of discussion in pursuit of consensus. Eventually, this can lead to chronic indecisiveness.

Pete enumerates some patterns of teams and code ownership.

You need to take a step back and view data on a macro level, not micro. As the founder, you should care more about the trends not the constant, inexplainable anomalies.

…

One of the really frustrating parts of running a business is that many times we just don’t know the answer to “why?”.

Why did churn go up 10%? Why are trial conversions decreasing? Where did all these new users come from? Why is our growth half of what it was last month?

Many of those questions have no answer and trying to find an answer will cause you to rip your hair out.

A curated collection on the missing aspect of managed time in programming.

A look at how Skyscanner support their people’s transition from individual contributer to managers.

Lovingly craft those commits, friends.

Bezos considers 70% certainty to be the cut-off point where it is appropriate to make a decision. That means acting once we have 70% of the required information, instead of waiting longer. Making a decision at 70% certainty and then course-correcting is a lot more effective than waiting for 90% certainty.

…

Reversible decisions can be made fast and without obsessing over finding complete information. We can be prepared to extract wisdom from the experience with little cost if the decision doesn’t work out. Frequently, it’s not worth the time and energy required to gather more information and look for flawless answers. Although your research might make your decision 5% better, you might miss an opportunity.