Jacob Kaplan-Moss:

What’s a transition file?

It’s a document that you prepare for whoever ends up succeeding you in your role. It should contain all the information you’d want them to know to ensure as smooth a transition as possible. Done right, the document should help them step into your role with a minimum of disruption.

James Stanier:

When you’re staring a huge, challenging project in the face, don’t align your team around just getting it done. Instead, align your team around continually reducing uncertainty.

You reduce uncertainty until the software exists. You reduce uncertainty by doing: prototyping, designing, writing code, and shipping. Each of these actions serve to reduce the uncertainty about what is left to build.

Zero Defects means the goal would be considered ‘failed’ if there were even a single defect, so even if the intention behind the goal was good, it puts great pressure on people to find other ways to achieve this impossible objective.

Eric Melloul:

Another important capability is assembling an ecosystem of partners and suppliers that do the work for you. Because of limited resources, you cannot do it all.

…

The ability to be more patient and take more risks is what sets midcaps apart.

…

I see many companies move from an incentive structure that was based on growth and profit to one based exclusively on profit. That drives the wrong behavior because it forces managers to focus on cost instead of growth, short term instead of long term.

Aaron Lerch:

Hiring for additivity requires intentionality. It seeks to answer the question “how does this person change us for the better?” It avoids both stagnation and a lift-and-shift cultural change.

Farnam Street:

Sometimes doing nothing at all or removing inputs is the better approach.

Derek Thompson on how solving finite games can ruin the infinite games that surround them.

Dina Denham Smith and Alicia A. Grandey:

Leaders are expected to attend to employees’ mental and physical health and burnout (while also addressing their own), demonstrate bottomless sensitivity and compassion, and provide opportunities for flexibility and remote work — all while managing the bottom line, doing more with less, and overcoming challenges with hiring and retaining talent. They should appear authentic, but if they get too honest about their distress, others may lose confidence in their leadership, known as the “authenticity paradox.”

This whole article resonates with my experience.

Jason Yip:

Organizational effectiveness in market development is efficiently running a lot of experiments to find promising opportunities.

Organizational effectiveness in growth and maturity is efficiently building, scaling, iterating, and exploiting capabilities in order to maximize business value.

Organizational effectiveness in decline or commodity / hygiene capabilities is reducing total cost of ownership.

Charity Majors:

The strategy for a fulfilling, lifelong career in tech is not to up the ante every interval. Nor is it to amass more and more power over others until you explode. Instead:

1. Train yourself to love the feeling of constantly learning and pushing your boundaries. Feeling comfortable is the system blinking orange, and it should make you uneasy.
2. Follow your nose into work that lights you up in the morning, work you can’t stop thinking about. If you’re bored, do something else.
3. Say yes to opportunities!! Intensity is nothing to be afraid of. Instead of trying to cap your speed or your growth, learn to alternate it with recovery periods.
4. If you aren’t sure what to do, make the choice that preserves or expands future optionality. Remember: Most startups fail. Will you be okay with your choices if (& when) this one does too?

Noah Brier:

Lumpers think splitters are neurotics, and splitters think lumpers are careless.

Camille Fournier:

Either way, it is important to realize that these more senior levels are not a measure of betterness, or quality, or raw intelligence and technical skills. They are instead a measure of demonstrated impact and confidence in the scope of work that the person can be tasked to accomplish. The people who get these promotions are trusted to navigate the systems of the company, to understand what is valued by the people around them and where to spend their time, because they have done just that.

Cam Daigle:

I’m hoping this system helps you have better meetings – that the people running the meeting feel like it’s worth their time to run them, and that the people in attendance feel like their presence there matters.

Anthony Murphy:

Having overlap is deliberate and a good thing. It helps create shared accountability and remove any bottlenecks or single-points of dependencies.

Roger Martin:

Use every opportunity to talk to customers — both end-customers and channel (if your business sells through a channel). You don’t have to be at all formal or scientific about it. Make it easy to get started by doing it in a comfortable situation. If you have stores, wander a few of them talking to customers. If you are B2B, tag along with salespeople. Don’t have an agenda. Just soak in the customer thoughts, reactions, and behaviors.

…

Strategy is a team sport in which better strategic decisions arrive out of productive interpretations of diverse data and insights. Force yourself to learn how to integrate multiple views into your strategy-making by never engaging in strategy work alone. And I mean: never. That is what will get you the dialogue practice you need.

Tony Stubblebine:

Many things at Twitter were broken to the point that they could bring the entire site to a halt. Greg’s strategy, now distorted through multiple retellings and my own foggy memory, was to focus on short-term triage rather than long-term fixes.

Essentially, he realized that a collection of temporary, duct-taped fixes was the only thing that would give the Twitter team the breathing room to start working on longer-term fixes.

I think of this in school grade terms. Greg went looking for all the Fs and then turned them into Ds. Then he turned all the Ds into Cs and then all the Cs into Bs, etc.

Advice on managing stress and how to create conditions for rest and recovery.

Derek Thompson:

Role-switching is important not because quitting is so wonderful, but rather because sampling from different skills and fields is helpful, provided that you’re prepared to pounce on an area that clicks for you. Explore, then exploit.

…

He argues at one point that artists and other professionals feel happiest when their “body or mind is stretched to its limits in a voluntary effort to accomplish something difficult and worthwhile.”

Richard Mironov:

Prioritization is more than an analytical/intellectual exercise. It’s an organizational challenge with natural disagreements among stakeholders. Product leaders need to think about motivating the right kinds of participation and addressing the emotional issues that arise. Spreadsheets and models are necessary, but not sufficient.

A post that looks at various aspects of being a senior leader.

I personally have a fondness for framing the role as building the machine that builds the machine and all that entails.

Richard Marmorstein:

There’s nothing wrong with a fondness for data. The trouble begins when you begin to favor bad arguments that involve data over good arguments that don’t, or insist that metrics be introduced in realms where data can’t realistically be the foundation of a good argument.

Chris Stjernlöf:

When reading Robert’s Rules of Order, I learned two things that struck me as deeply important, which I had misunderstood in the past:

• The purpose of debate is not winning, it’s about information sharing.
• Votes should not need to be counted, the result should be clear anyway.

Sam McAfee:

Many organizations still focus the majority of their decision making on one person or one small group of people at the top. This concentration of decision making isn’t just inefficient, it’s degenerative. No organization that maintains such centralized control over decisions will be able to adapt at the speed required by today’s markets.

…

The other key to promoting autonomy is to ensure individuals and teams have the skills they need to act on the clarity that comes from strategic thinking. Skills are honed through delegation. Managers must practice delegation to successfully develop new skills in their direct reports. And yet, good delegation skill is more rare than it should be.

…

Teams can then take the clarity they capture from long-term strategic thinking, the capabilities they’ve built by having decisions delegated to them, and combine them into action that is fast, flexible, and responsive.

Skills that lead to good code stewardship.

Kara Cutruzzula:

Why is defensiveness such an obstacle to collaboration? When we get defensive, “we put way more into self-preservation than we do into problem-solving,” Tamm says. “We’re trying to prove that we’re right rather than search for creative solutions.” When this happens in a workplace, it can be a recipe for chaos and failure.

…

OK, now that we understand the dangers of defensiveness, here’s what we can do about it. You can start by learning to spot the warning signs of defensiveness in yourself. When you feel yourself experiencing them, pay attention and take action. According to Tamm, here are the 10 most common warning signs that you may be getting defensive: A spurt of energy in your body; sudden confusion; flooding your audience with information to prove a point; withdrawing into silence; magnifying or minimizing everything; developing “all or nothing” thinking; feeling like you’re a victim or you’re misunderstood; blaming or shaming others; obsessive thinking; and wanting the last word.

John Cutler:

We confuse clarity/coherence and certainty. If clarity/coherence equals certainty, and a strategy is supposed to be clear and coherent, then unless we are certain, we can’t have a strategy. Meanwhile some high percentage of the audience for our strategy wants certainty. If they haven’t heard confident certainty, then they haven’t heard a strategy.

…

The unlock, I think, is realizing that you can confidently communicate a coherent strategy that also acknowledges uncertainty. You know what you know. You assume what you assume. You believe what you believe.

Dave Bailey provides a manager’s guide to holding their teams accountable.

Jason Yip:

• Authority-focus: “Not my job, not my problem.”
• Responsibility-focus: “What is the right thing to do? How can I help?”

Responsibility-focus reflects the belief that “we’re in it together”.

Jason Yip:

When you work in team-based product development, you will need to deal with drift.

By drift, I mean an increasing mismatch in understanding about:

• the problem we’re trying to solve;
• the solution we’re attempting;
• each other and how to relate.
• Drift in shared understanding creates confusion, mistakes, and generally a bad working experience.

…

Daily standups ensure understanding is integrated across a team at least once a day.

Dave Kellog:

In the end, there are two types of things that CEOs can potentially stress about:

• Things they can control. They shouldn’t stress over these because they should do something about them, instead.
• Things they can’t control. They shouldn’t stress over these because doing so will not change the outcome. Worse yet, it may well change the outcome — for the worse — over the things they can control.

Ergo, CEOs should never stress about things. QED.

I’m still a sucker for code editors.

Suggestions for how to make meetings worthwhile.

Miriam Posner:

You could say, then, that by the late 1960s, software development was facing three crises: a crying need for more programmers; an imperative to wrangle development into something more predictable; and, as businesses saw it, a managerial necessity to get developers to stop acting so weird.

Peter Seibel:

A feedback process 100% aimed at professional growth would, I suspect, be totally divorced from promotions and compensation bumps. Not because those things should be unrelated to professional growth but because truly reflecting on how you can do better and being open to feedback from your peers and managers is already tremendously difficult; when you are also worrying about whether or not you’re going to get that promotion or raise you were hoping for, it’s probably impossible.

Lots more in there on feedback, biannual reviews, titles, promotions, and the role of management.

Dave Anderson:

A promotion to a higher job level puts you in a more influential position. You are being given more responsibility. It’s not a reward. Instead, it’s the company granting you more influence.

Of course, increased pay often accompanies a promotion. However, the added responsibility is the reason the company did the promotion, not the compensation.

Those who run the company are always looking for people to take on more responsibility. They’re looking for people who can come up with the next business idea, lead larger spaces, identify opportunities, and fix recurring problems. It is relatively easy to find people who are good at their jobs, and hard to find people capable of doing the next level job.

Circling back, companies promote people into larger responsibilities when that person looks like a leader. Leaders identify their own opportunities.

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.

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.”

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”.

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.

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

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.

Ben Adam:

Amazon effectively operates like a federation of smaller companies. There are (extremely) large organizations, which break into divisions, and then into small, functionally independent teams.

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.

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.”

Jason Yip:

Alignment and autonomy are not two ends on a scale but two dimensions on a 2x2 matrix.

Clear and candid.

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.

Eradication of all latent failures is limited primarily by economic cost but also because it is difficult before the fact to see how such failures might contribute to an accident. The failures change constantly because of changing technology, work organization, and efforts to eradicate failures.

…

Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes.

…

Hindsight bias remains the primary obstacle to accident investigation, especially when expert human performance is involved.

So many more nuggets of wisdom in there.

I pretty much highlighted the lot.

The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions. These placeholders/slots contain the server-rendered HTML output from their corresponding widget. They denote regions that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML.

Loads of fantastic advice.