How Far Does Your Work Reach?
Last week, I had the opportunity to speak at a conference about measuring the impact of agentic projects. The room was engaged, the questions were sharp, and a few people even stayed afterward to keep talking.
It went well, but the impact stayed with the people in that room. Here's how I expanded that reach.
Share what you learned
When I got back, a few people at work asked how the talk went. I could have said, "It went great," and moved on.
Instead, I put together a write-up and shared it with others in the company. It covered:
- The topic and how I positioned it for that audience.
- An exercise I ran at the start and how the room responded to it.
- The lessons I took away, including what I'd adjust next time.
- A recording of my talk for context.
That write-up gave the work additional life. Marketing folded parts of it into a public post, and people from other parts of the business started engaging with it, including people I rarely work with.
The initial talk reached about 100 people. The write-up helped me reach thousands.
We're all putting in the work. If we don't talk about it and give others a chance to learn from it, our impact is always going to be limited.
Why we avoid sharing our work
Writing an internal post took a fraction of the effort the talk did, but most don't feel comfortable taking this step. It's important to understand why you are feeling this way so you can push past it. Here are 3 common reasons for not taking the next step to promote what you have done:
It feels finished. Once something wraps up, you're ready to move on. The migration shipped, the incident closed, the talk is over. Going back to write about it feels like extra work. But the details are freshest right now, and in two weeks you won't remember the ones that made it useful.
It feels like bragging. Writing about your own work can feel self-promotional, especially if you've spent years assuming good work gets noticed on its own. Write for the reader. Focus on what happened and what you learned, and leave out how well it went.
You assume nobody cares. You can't predict who will find your work useful. I wrote my post for the handful of people who asked about it. The people who ended up building on it weren't the people I was writing for.
Writing is a knowledge transfer
A useful write-up tells people what happened and what they can take from it.
A simple structure for a write-up
What it was: one or two sentences of context.
Why it matters to the reader: who should care, and what problem it touches for them.
What happened: the decisions you made and how things played out, including what didn't go to plan.
What you learned: the part only you can share.
Where to go deeper: the recording, the doc, the PR, or the dashboard.
This works for far more than conference talks:
- After an incident, a short write-up on what broke, how you found it, and what to watch for saves the next on-call engineer an hour of digging.
- After a migration, a note on what you planned, what surprised you, and what you'd do differently helps the next team that has to run one.
- After a spike or proof of concept, a summary of what you tried and what you ruled out keeps someone else from repeating the same dead ends.
I've written before about the value of writing things down so you're not explaining the same thing five times. A write-up does the same job here. Anyone who asks "how'd it go?" can get the full answer without you repeating it.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
You can only take it so far
I didn't decide to fold my write-up into a public post, and I didn't decide which teams would find it relevant. Other people made those calls.
You control how far you take your work. You don't control who picks it up after that. So take it far enough that someone else can run with it.
Sharing your work helps your career
The projects that help you grow usually come from someone deciding to bring you in. That decision depends on what they know about how you think and what you've done. I wrote about this in The Projects You Never Hear About.
A write-up puts your work in front of people who wouldn't otherwise see it. Someone on another team reads how you handled a hard migration, and the next time they have one, they think of you. Your manager has something concrete to point to when they make the case for your growth.
Share the edges so others can take it
A finished write-up can read like a closed loop. You did the work, here's what happened, the end. That makes it easy to read and hard to build on.
The parts other people can pick up are the edges: the places where your work stops and someone else's could start. Name them when you share:
- What's still open. The question you didn't get to answer, or the part you'd test next if you had more time.
- Where else it might apply. If the lesson from your migration could change how another team plans theirs, say so.
- What you'd change next time. My write-up included what I'd adjust in the talk, which gave readers something to react to beyond the recap.
- Who should talk to you. A single line inviting people working on something similar to reach out gives them a reason to start the conversation.
You won't know which edge someone will grab. Marketing found one I didn't expect. Your job is to make the edges visible, then let others take it from there.
The first time you share work this way, it will feel awkward. By the third or fourth, it becomes part of how you finish things.
The next time someone asks how something went, you can say "it went great," or you can give them something they can learn from and pass along. The second takes a little more effort, and it keeps your work going after you've moved on.