Hey there, fellow accidental techie! π
Reader, think about the last time you explained a technology issue to your executive director or manager.
What expression did they make?
Not rhetorical. That expression is data.
Most accidental techies do genuinely good work. They build skills, they cultivate relationships, they lead real projects. And then they walk into a meeting and describe what they did in task language, leadership nods politely, and the budget conversation goes nowhere.
The work was real. The communication didn't land. And nobody taught you the difference.
That's what this issue is about.
This is the fourth and final bridge in the series. We've covered Skills (how to stop underselling what you've already built), Relationships (why your network is infrastructure, not a soft skill), and Projects (who gets to decide what you work on). This one is Communication β how to make everything you've been building visible to the people who can actually resource it.
What's in this issue:
β
The expression on your ED's face β and what it's actually telling you
β
Task language vs. mission language β a side-by-side look at how the same work lands completely differently depending on how you describe it
β
The Point of View tool β a sentence structure from human-centered design that leads with the human problem instead of the technical one
β
Three moves to start this week β rewrite your role description, prepare one POV statement, and change how you open the next tech problem conversation
β
Watch the recording β missed today's LinkedIn Live on all four bridges? The replay is up now
β
The Intentional Techie Cohort β 6 weeks of deep work starting June 2026
β
Jobs in nonprofit tech β this week's roundup of roles worth a look
β
What I'm reading β resources across the sector worth your time
Before we get into it β one thing this week.
Yesterday, I ran a live session walking through all four bridges together β the full framework and real examples. If you were there, thank you. If you missed it, the recording is available now.
This is the clearest version of everything I've been building toward in this series. If you're going to watch one thing before enrollment closes for the June cohort, make it this.
|
|
From Accidental to Intentional: The Four Bridges Every Nonprofit Tech Leader Needs to Cross
|
The moment I stopped explaining the technology
A few years into my time in operations leadership, we had to significantly harden our organization's digital security. This wasn't a minor update. It was a full overhaul of how every person on staff accessed their tools, authenticated into systems, and protected organizational data. A major undertaking, and a real change management challenge.
My first instinct was to explain what we were implementing. New authentication requirements. Single sign-on. Stricter password policies. Tools staff had never used before.
The blank stares came fast.
So I stopped explaining the technology and started explaining the people behind it. Staff would have one simple way into every application they needed. No more fifteen separate passwords. No more getting locked out of something critical right before a deadline. The organization would operate at a significantly higher level of security, and that security wouldn't depend on each individual person figuring out how to protect themselves.
That version landed. Same initiative. Same requirements. But the second version gave people something they could actually connect to β and gave leadership something they could say yes to.
The realization came quickly after that: my job wasn't to be technically accurate. It was to be strategically clear.
Those aren't the same thing.
Why technically right doesn't mean strategically clear
Most accidental techies describe their work in task language. That's how they learned. You figured out a system, fixed something, and when someone asked what you did, you described what you technically did. It's accurate. It's also almost completely invisible to leadership.
Nobody approves a budget line for "database maintenance." They approve budget for "making sure our development team can trust the data they're working from."
Leading with what matters to the person across the table is different work entirely from technical explanation. Both are useful. But one of them opens doors and one of them gets you a polite nod and a changed subject.
Here's what that looks like side by side:
| Task Language |
Mission Language |
| "I manage the database." |
"I help our team make data-driven decisions." |
| "I do IT support." |
"I solve tech problems so staff can focus on the communities we serve." |
| "Our CRM has data integrity issues." |
"Our team spends three hours a week manually correcting data that should be automated. That's three hours not going toward donor relationships." |
| "I set up new laptops." |
"I reduce onboarding time so new staff can hit the ground running." |
Same work. The right column gives someone something to respond to.
One tool that helped me get consistent about this came from human-centered design: the Point of View statement. Simple format.
[Person] needs [something] because [reason that connects to the mission].
You lead with the human problem before you get anywhere near the technical solution.
Here's an example. "Our program staff need quick access to client records during home visits because slow login processes cut into the time they have with the families they serve."
That sentence tells leadership who is affected, what they need, and why it matters to the mission. No jargon. No assumed knowledge. And critically, it makes you look like someone who understands the problem, not just someone who knows how to fix it. When you bring that into a meeting instead of a system requirement, the conversation changes entirely.
The question you ask works the same way. "What's broken?" signals that you're there to fix something after the fact. "What's slowing your team down that technology might be able to help with?" signals that you're there to think with people before something goes wrong. Same room. Completely different dynamic.
At every organization I worked at over 15 years, I pushed for Operations to have regular time in all-staff meetings. Updates, upcoming changes, feedback from the whole team. Most people thought of it as a housekeeping slot. I thought of it as practice. By showing up consistently with information that mattered to staff, using language that respected everyone's time, and treating those five minutes like they counted, I built something that a single big presentation could never create: a track record. So when a real decision needed to be made, people already trusted that I understood what mattered to them.
That trust doesn't get built right before the important meeting. It accumulates in the small ones.
There's also a harder thing to name here. In nonprofit culture, a lot of us were taught to serve, to stay in our lane, to not take up too much space. For accidental techies, that often looks like staying in technical mode even when we have something strategic to contribute. Describing your work in task language can feel like humility. Sometimes it's actually a habit of making yourself smaller than you are.
How you narrate your work determines who gets to shape it. And the people shaping technology decisions at your organization should include the person who actually understands the technology.
Join The Accidental Techie Community in Linkedin
|
Three moves you can make this week
Rewrite how you describe what you do.
Take your job title or how you'd answer "what do you do?" and rewrite it without tasks or systems. Try this format: "I help [who] do [what] so they can [mission-level result]." Share that new version with one person this week and see how it lands. Notice the difference in how they respond.
Prepare one Point of View statement before your next meeting.
Before the next time a tech issue comes up in a team or leadership conversation, write one sentence using the structure: [person] needs [something] because [reason]. Use it when the moment arrives. You're giving people a reason to lean in before the technical explanation starts β which makes the technical explanation land completely differently.
Change how you open the next tech problem conversation.
Before explaining what's wrong with a system, explain what it's costing. Time lost. Capacity diverted. A specific number if you have one. When leadership understands what a problem is costing the organization, the case for fixing it makes itself.
This is the last of the four bridges.
Skills was about recognizing what you've already built.
Relationships was about who has your back before things break.
Projects was about deciding what you work on rather than waiting to be assigned it.
Communication is what makes all three visible to the people who can actually resource them.
The bridges don't work alone. The whole point is that they compound.
If you've been reading this series and seeing yourself in it, that's not a coincidence. The June cohort is the structured version of this work β six weeks, 15 people, built around all four frameworks with real accountability and a peer group who understands exactly what your job is actually like. Enrollment is about to open and you won't want to miss early bird pricing.
β
β
|
|
Join the June Cohort
Sign up for the Waitlist to receive the annoucement
|
Until next time,
Hugo
P.S. The first thing you do from this series probably won't feel significant. The thirty-seventh thing will. If you have committed to following at least one action from this series, please reply to this email. I want to hear from you + accountability ;)
Join the Waitlist
A 6-week cohort program for nonprofit professionals ready to stop firefighting and start shaping technology strategy.
Join the waitlist for early access and beta pricing.
|
β