tl;dr: Make it easier and more effective for introducers to make connections for you by writing them specifically structured emails: Forwardable Introduction Requests (FIR).¹

In the last two weeks, I’ve been asked for 6 introductions to various people and ended up successfully making 2 of those introductions.

For every one of those 6 requests, I’ve liked the person asking and wanted to make the introduction. But the way the askers made these requests was both ineffective for the asker and also inefficient for me.

This was my prompt, if you will, to write up how I ask for introductions. This is what I want people to do if they want me to do an introduction.

Good introductions require work.

Making an introduction isn’t just connecting two people via email. A good introduction requires consent in advance from the introducee (the person to whom the asker is being introduced) and for the introducer to be able to communicate a lot of information about the asker.

Without asking the introducee in advance, the introduction becomes an ambush. So as the introducer, I always reach out first to the introducee to explain who the asker is, why they want to be introduced, and (ideally) why the introducee might benefit from or enjoy meeting the asker. I always ask the introducee if they’re willing to be introduced. If I’ve done a good job, the answer is usually yes.

As the introducer, I need to communicate three things to do a good job:

1. How I know the asker (some transfer of reputational capital is happening here).
2. Who the asker is.
3. A good reason for the asker to want this particular introduction.
4. A reason why the introducee might benefit from or enjoy being introduced to the asker.

As Alex Iskold has pointed out, compiling this information takes time. To do it properly takes more than 10–15 minutes, especially if it involves emailing the asker to explain why they want the introduction. The 4 introductions I didn’t manage to make? Those fell through because the asker didn’t give me enough information — or didn’t give me the information fast enough — for me to do a good introduction.

Askers can make requesting an introduction much more efficient and more effective by doing it for the introducer.

How to ask for an introduction.

Here’s my process, which I wish everyone would follow when asking me for an introduction. It might be helpful for you too.

1. Get clarity about my ask.

Before reaching out to an introducer, I do research to be as specific as I can about what I need and who might be able to provide it. Whenever I skip this step, I regret it (I get introduced to the wrong people, I waste an introducer’s time, etc.)

2. Ask the introducer if they’ll connect me.

Before assuming they’ll make an introduction, I send a quick email or message asking if they’d be open to it. Something like:

Subject: Would you be open to making introductions on [topic, as specific as possible]?

Hey [Introducer], I’m working on [project]. I’d love to connect with someone who [has expertise in X]. Would you be open to making an introduction if you know someone relevant? If yes, I’ll send you an email you can forward easily that has the relevant information about what I’m doing and what help I need. Also happy to get on a quick call to explain in a bit more detail. Let me know?

Many thanks in advance,

This serves two purposes for the introducer: It lets them decline easily if they can’t help (or they don’t want to), and it tells them that they won’t have to do any heavy lifting to help me out by making some introductions.

3. Send the introducer a Forwardable Introduction Request (FIR)

If the introducer says yes, I send them a FIR, which is a short email that is specifically written so that it can be forwarded without any modification on their part. The subject line is usually something like:

Subject: Know anyone you can introduce me to who [has relevant expertise]?

Hey [Introducer],

I’m working on [project] and would love to speak with someone about [specific need or expertise]. Do you know anyone who would be a good fit? Would love your thoughts and suggestions.

Thanks in advance! [Your Name, website, LinkedIn profile, or whatever is useful for the introducee to do a quick validation]

This type of FIR doesn’t specify the particular person I want to be introduced to. I’ve found this more useful because it allows the introducer to forward it more widely without needing to edit anything. This seems to increase my chances of getting a relevant but unexpected connection.

What happens next?

When I receive an FIR like this, as an introducer, I can forward it on by simply adding a brief line at the top to explain how I know the asker. Nothing else is needed from me other than to think about who I should forward it to.

The people I forward it to can reply if they’re interested or ignore it. If they do reply, I just add the asker’s email, and then my job is done. From there, it’s on the asker to follow up and make the most of the opportunity.

The bottom line

A good FIR saves time for the introducer, increases the likelihood that the introducer can cast a wider net for relevant introductions to make, and is more informative for introducees. A good FIR increases your chances of getting a useful introduction, and makes the process smoother for everyone involved.

gehayi:

mevima:

eruvadhril:

verschlimmbesserung:

Guys, why do you call Terry Pratchett either a type of antelope or an astroid?

It was called the lucky clacks tower, Tower 181. It was close enough to the town of Bonk for a man to be able to go and get a hot bath and a good bed on his days off, but since this was Überwald there wasn’t too much local traffic and - this was important - it was way, way up in the mountains and management didn’t like to go that far. In the good old days of last year, when the Hour of the Dead took place every night, it was a happy tower because both the up-line and the down-line got the Hour at the same time, so there was an extra pair of hands for maintenance. Now Tower 181 did maintenance on the fly or not at all, just like all the others, but it was still, proverbially, a good tower to man. 

Mostly man, anyway. Back down on the plains it was a standing joke that 181 was staffed by vampires and werewolves. In fact, like a lot of towers, it was often manned by kids. 

Everyone knew it happened. Actually, the new management probably didn’t, but wouldn’t have done anything about it if they’d found out, apart from carefully forgetting that they’d known. Kids didn’t need to be paid. 

The - mostly - young men on the towers worked hard in all weathers for just enough money. They were loners, hard dreamers, fugitives from the law that the law had forgotten, or just from everybody else. They had a special kind of directed madness; they said the rattle of the clacks got into your head and your thoughts beat time with it so that sooner or later you could tell what messages were going through by listening to the rattle of the shutters. In their towers they drank hot tea out of strange tin mugs, much wider at the bottom so that they didn’t fall over when gales banged into the tower. On leave, they drank alcohol out of anything. And they talked a gibberish of their own, of donkey and nondonkey, system overhead and packet space, of drumming it and hotfooting, of a 181 (which was good) or flock (which was bad) or totally flocked (really not good at all) and plug-code and hog-code and jacquard …

And they liked kids, who reminded them of the ones they’d left behind or would never have, and kids loved the towers. They’d come and hang around and do odd jobs and maybe pick up the craft of semaphore just by watching. They tended to be bright, they mastered the keyboard and levers as if by magic, they usually had good eyesight and what they were doing, most of them, was running away from home without actually leaving.

Because, up on the towers, you might believe you could see to the rim of the world. You could certainly see several other towers, on a good clear day. You pretended that you too could read messages by listening to the rattle of the shutters, while under your fingers flowed the names of faraway places you’d never see but, on the tower, were somehow connected to …

She was known as Princess to the men on Tower 181, although she was really Alice. She was thirteen, could run a line for hours on end without needing help, and later on would have an interesting career which … but anyway, she remembered this one conversation, on this day, because it was strange. Not all the signals were messages. Some were instructions to towers. 

Some, as you operated your levers to follow the distant signal, made things happen in your own tower. Princess knew all about this. A lot of what travelled on the Grand Trunk was called the Overhead. It was instructions to towers, reports, messages about messages, even chatter between operators, although this was strictly forbidden these days. It was all in code. It was very rare you got Plain in the Overhead. But now …

‘There it goes again,’ she said. ‘It must be wrong. It’s got no origin code and no address. It’s Overhead, but it’s in Plain.’

On the other side of the tower, sitting in a seat facing the opposite direction because he was operating the up-line, was Roger, who was seventeen and already working for his tower-master certificate. 

His hand didn’t stop moving as he said: ‘What did it say?’ 

‘There was GNU, and I know that’s a code, and then just a name. It was John Dearheart. Was it a—’ 

‘You sent it on?’ said Grandad. Grandad had been hunched in the corner, repairing a shutter box in this cramped shed halfway up the tower. Grandad was the tower-master and had been everywhere and knew everything. Everyone called him Grandad. He was twenty-six. He was always doing something in the tower when she was working the line, even though there was always a boy in the other chair. She didn’t work out why until later. 

‘Yes, because it was a G code,’ said Princess.

‘Then you did right. Don’t worry about it.’ 

‘Yes, but I’ve sent that name before. Several times. Upline and downline. Just a name, no message or anything!’ 

She had a sense that something was wrong, but she went on: ‘I know a U at the end means it has to be turned round at the end of the line, and an N means Not Logged.’ This was showing off, but she’d spent hours reading the cypher book. ‘So it’s just a name, going up and down all the time! Where’s the sense in that?’ 

Something was really wrong. Roger was still working his line, but he was staring ahead with a thunderous expression. 

Then Grandad said: ‘Very clever, Princess. You’re dead right.’

‘Hah!’ said Roger. 

‘I’m sorry if I did something wrong,’ said the girl meekly. ‘I just thought it was strange. Who’s John Dearheart?’ 

‘He … fell off a tower,’ said Grandad. 

‘Hah!’ said Roger, working his shutters as if he suddenly hated them.

‘He’s dead?’ said Princess. 

‘Well, some people say—’ Roger began. 

‘Roger!’ snapped Grandad. It sounded like a warning. 

‘I know about Sending Home,’ said Princess. ‘And I know the souls of dead linesmen stay on the Trunk.’ 

‘Who told you that?’ said Grandad. 

Princess was bright enough to know that someone would get into trouble if she was too specific. 

‘Oh, I just heard it,’ she said airily. ‘Somewhere.’ 

‘Someone was trying to scare you,’ said Grandad, looking at Roger’s reddening ears. 

It hadn’t sounded scary to Princess. If you had to be dead, it seemed a lot better to spend your time flying between the towers than lying underground. But she was bright enough, too, to know when to drop a subject. 

It was Grandad who spoke next, after a long pause broken only by the squeaking of the new shutter bars. When he did speak, it was as if something was on his mind. ‘We keep that name moving in the Overhead,’ he said, and it seemed to Princess that the wind in the shutter arrays above her blew more forlornly, and the everlasting clicking of the shutters grew more urgent. ‘He’d never have wanted to go home. He was a real linesman. His name is in the code, in the wind in the rigging and the shutters. Haven’t you ever heard the saying “A man’s not dead while his name is still spoken”?’

- From Going Postal by Terry Pratchett

tl;dr: “gnu” is a term of respect from Sir Pratchett’s books that means “keep saying their name, keep saying their name.”

The really great thing is, it wasn’t planned.

After Terry Pratchett died, “GNU Terry Pratchett” started flying all over the internet. Tweets, Tumblrs, blogposts. People emailed and DMed each other with the news and the message. Coders for websites and blogs put the message into their code so that  “GNU Terry Pratchett” could never be removed from the internet. Sir Terry’s daughter said that she was astonished–that no one had expected this. 

Sir Terry’s fans found a way of using his own writing to memorialize him. To say, We love you. We remember you. And we won’t let you be forgotten.

That message is still true.

Click here to go see the bonus panel!

Hovertext:
This is another one of those 'is Zach okay' comics and the answer is Zach is cashing in on ennui HARD.

Some people today are discouraging others from learning programming on the grounds AI will automate it. This advice will be seen as some of the worst career advice ever given. I disagree with the Turing Award and Nobel prize winner who wrote, “It is far more likely that the programming occupation will become extinct [...] than that it will become all-powerful. More and more, computers will program themselves.”​ Statements discouraging people from learning to code are harmful!

In the 1960s, when programming moved from punchcards (where a programmer had to laboriously make holes in physical cards to write code character by character) to keyboards with terminals, programming became easier. And that made it a better time than before to begin programming. Yet it was in this era that Nobel laureate Herb Simon wrote the words quoted in the first paragraph. Today’s arguments not to learn to code continue to echo his comment.

As coding becomes easier, more people should code, not fewer!

— Andrew Ng

Tags: ai-assisted-programming, ai

{ {;;} {*;;}

tags: strategy, embedded, abstracted, uncertainty
Link: embeddedstrat

This is #1 in a series on seven tensions that lead to common misunderstandings about strategy.

—

A misconception about strategy

Stripped all the way down, strategy is about making decisions under uncertainty. Strategy requires understanding the current situation ’97 what resources you have, what constraints you face ’97 and deciding where you want to go (which must be both different and better). But the path between where you are and where you want to be is never obvious. There’s always uncertainty about what the desired end state should be, and even more uncertainty about how to get there. Strategy, then, is fundamentally about creatively using resources and circumventing constraints to walk an uncertain path.

This makes strategy sound like a conceptual, high-level exercise ’97 a planning process full of charts, models, and frameworks, culminating in a boardroom deck. That’s certainly how strategy is usually approached: As something abstracted away from day-to-day reality, best discussed in air-conditioned meeting rooms, with glossy slides to persuade decision-makers. (Also take a look at my previous article on why strategy is not the same as planning.)

This view of strategy is not just limited; it’s actively misleading. Good strategy can never be purely abstracted. It must be embedded in the mundane, everyday realities of an organisation.

An example illustrates the downside of abstracted strategy. I once worked with a company that framed its strategic problem as: ’93We’re not innovative enough. Our competitors release new products twice as fast as we do, and those products gain traction with customers.” They hired an expensive strategy consultancy (one of the usual suspects) which eventually led to a standard boardroom play ’97 budgeting more resources and support for the R&D team. Despite the increased investment, the number of successful product launches barely budged.

Turns out the problem wasn’t a lack of funds. The real problem (not visible without spending a lot of time watching the team work together) was that the R&D team didn’t have a shared language for what made a good product. Without an agreed way to define and assess product potential, the well-intentioned team was unable to make collective decisions about which ideas to invest their limited time in developing. Throwing more money at the problem didn’t fix it. The strategic problem wasn’t one of money; it was a problem with everyday human interaction.

This is why good strategy can never be purely abstract: The seemingly trivial aspects of an organisation matter far more than they get credit for. A team that doesn’t have a clear way to talk about what makes a product ’93good” will struggle to develop good products ’97 even if it has enough money and headcount and a nice new skunkworks building in a different city to work out of.

What I’m called embeddedness here means recognising that every organisation functions on multiple levels. There’s the abstracted level of senior management in the boardroom, but there’s also the ground-level reality of teams and individual contributors (and levels in between). Strategy that only makes sense in the boardroom is often bad strategy. Good strategy needs to be embedded so that it accounts for, makes sense to, and works with the different levels of the organisation. Embedded strategy recognises the importance of the mundane and the unsexy.

Embedded strategy isn’t just useful for avoiding obvious strategy mistakes (like misdiagnosing a problem and throwing resources at the wrong solution). It also enables strategic sophistication that abstract approaches simply can’t see.

In another organisation I worked with, an embedded approach to strategy revealed a hidden but powerful resource and how to turn that into a usable asset. The organisation had an R&D team in which senior members were very productive because they each had an accurate and refined awareness of what made new products stylistically consistent with previous products. Unfortunately, junior members did not have this awareness and were much slower in product development.

An embedded approach revealed that the fastest and most effective way to grow this awareness was by engaging in detailed feedback between team members. The resulting intervention was a weekly team meeting for giving and receiving feedback on any work in progress. This simple, nearly cost-free intervention became the key to speeding up and improving the quality of product development across the entire team. Previously, senior team members held valuable but largely tacit knowledge about what made their products distinctive. Junior team members, lacking consistent access to this knowledge, had to figure things out themselves, slowly.

But with a structured team all-hands discussion every week, senior team members began sharing critical insights in a way that was natural, digestible, and actionable. This solution to the strategic problem (of needing to speed up new product development to stay competitive) didn’t emerge from an abstract strategy exercise. It came from looking deeply at how work was actually getting done and finding underutilised opportunities within existing structures ’97 an embedded approach to strategy.

The third reason embedded strategy is superior is that strategy inevitably involves changing how organisations work. Change is hard. Even the most carefully planned strategic shift will fail if the people responsible for implementing it don’t understand it, don’t believe in it, or don’t see how it connects to their day-to-day work. Abstracted strategy often fails precisely because it lacks this embedded connection. Abstracted strategy is designed at the top, pushed downward, and resisted at every step.

Embedded strategy, by contrast, is naturally framed in ways that make sense to the people enacting it. When strategy is developed with an awareness of the realities of work on the ground, the resulting changes are not only easier to implement ’97 they are more likely to work and to stick.

So, embedded strategy is good strategy for three reasons:

1. It avoids misdiagnosing problems and making obvious mistakes about solutions.
   
2. It enables creative, high-leverage interventions by making full use of organisational resources that an abstracted view would not even see.
   
3. It makes change more implementable by designing and framing it in ways that resonate with the people who must execute it.
   
   Good strategy doesn’t live in boardroom presentations. It lives in how work actually gets done. If you’re trying to make strategy work better in your organisation, the question to ask isn’t just ’93What should we do?” but ’93What should we do that would make sense throughout the organisation?”
   
   If this embedded approach to strategy resonates with you, let’s talk about making it work in your organisation.
   
   
   
   
   
   
   —
   
   I’ve been working on tools for learning how to turn discomfort into something productive. idk is the first of these tools.
   
   And I’ve spent the last 15 years investigating how organisations can design themselves to be good at working in uncertainty by clearly distinguishing it from risk.}

(UK readers! Did you want to read “The Unaccountability Machine”, but think “that huge great thing is far too heavy for my puny forearms”? Great news! It’s now out in paperback! American readers! Did you want to read “The Unaccountability Machine” but think “it’s not actually on sale here except for that brief period when the ebook edition was available”? Great news! It will be out on the first of April (or indeed “April First”)

Sigh. I do not want to get into the habit of fact-checking YIMBYism, but nor am I any good at resisting bait. Our Prime Minister, this week:

Is the future of the development really uncertain? It’s not so uncertain that they’ve stopped marketing it to off-plan investors, put it that way. What seems to have happened is that everyone agreed that a risk assessment and mitigation was needed (when you change the use from an office block, which is usually empty at weekends when cricket matches are played, to a block of luxury flats, which isn’t and might have children playing outside). The developer said “nobody can hit a cricket ball that far”, and Sport England (on the advice of the ECB, which has a model of such things apparently) said “yeah nah, professionals can, and this is a ground in the Yorkshire league system which surprisingly often attracts big-hitting ringers”.

And consequently, the Bingley planning committee is going to debate whether the planning condition should be varied – it is perhaps possible that the outcome will be that a £30m development will be abandoned over a few grand’s worth of safety netting, but I would bet otherwise. The development got planning permission in 2021, and then started work at leisurely pace in 2023, so I’m guessing that there have been other factors holding it up rather than just cricket.

Anyway …

This is a bee in my personal bonnet, because I actually do believe that the overuse of consultancy firms, and risk-aversion in planning is a big problem in Britain (watch this space for an extremely exciting publication along those lines!). It is actually kind of scuffed that when Sport England is right there, and the England and Wales Cricket Board has exactly the capacity needed, we have a system in which the only way that scientific knowledge about the trajectory of cricket balls can be part of the process is via duelling consultants’ reports.

But this is a really bad example. It’s not quite as bogus as “Homer Simpson doesn’t speak Welsh” or the “fish disco”. But it’s a bad example, where a minor hitch in a project, caused by what looks like laziness or calculated risk-taking on the part of a developer, is portrayed as a sign of deep sclerosis that makes it impossible to build anything anywhere ever.

And this sort of thing tends to discredit better examples, like the Sheephouse Wood Bat Shed, which I think is actually an important case study.

Which set me thinking about another slight pathology of the system. I would bet good money at short odds that somebody in Starmer’s office saw that he was doing a speech in Hull about planning, googled for examples of planning problems in Yorkshire and eventually turned up news stories about the cricket club thing.

And they did that googling because every policy speech in this area seems to need a “chortle”. (It’s the equivalent of a “Malcolm” folksy anecdote in a non-fiction book). We can’t just have a serious example of problems that the new initiative is meant to address, they need to be slightly whimsical and create a comic image. I think it very much started with the “health and safety gone mad” tradition in journalism, by way of the “bendy bananas” coverage of European regulations.

As I said before, this partly worries me because if you try to claim that the whole system is absurdly broken in every way, then it takes focus away from any serious consideration of which parts of it might actually be broken in specific ways, which in turn is an excellent excuse for not fixing anything. But it’s also just a cheap and unprofessional thing to do.

Seriously, I know I have readers in think tank land – stop doing this. Try to stop your colleagues from doing it. Write things like “is this just a chortle?” in margins. I get it, I know; policy is often difficult and boring, and it’s hard to get engagement without a quirky or amusing hook. But what you’re doing is exactly the sort of thing that has led to so many media death spirals, in that it’s chasing quantitative #numbers while ignoring the deleterious long term effect on the brand.

It's OK for some things to be boring. I might even write “in defence of tedium” one day, because it’s a means for people who don’t actually care about something to select out of having a view on it. Boredom is a form of pain; it takes the place of the wonderful imaginary machine which might administer a small electric shock to anyone publishing a #take without doing the background reading. Engagement has to be measured, at the end of the day, in something closer to kilobytes per second than headcount – it’s a concept of information flow. Don’t spend your time and energy advertising to people who don’t actually want the product.