Hey there, fellow accidental techie! π
Reader, quick question. Look at your project list right now.
How many of those items are there because something broke? How many because someone complained? How many because a vendor sent you an email at exactly the right moment of weakness?
If the honest answer is "most of them" β you're not alone. You're just doing what accidental techies do. The work gets defined by whoever is loudest, whatever is most urgent, and whatever landed in your inbox this week.
That's what this issue is about changing.
This is issue three of The Four Bridges. We've covered Skills (how to stop underselling what you've already built) and Relationships (why your network is infrastructure, not a soft skill). This one is about Projects. Not just how to run them better, but who gets to decide which ones happen at all.
Before we get into it β one thing this week.
Next Wednesday, April 29 at 1 PM ET, I'm hosting a free LinkedIn Live session: From Accidental to Intentional: The Four Bridges Every Nonprofit Tech Leader Needs to Cross.
If you've been following this series, this is the live version. All four bridges, the full framework, and I'll be taking questions in real time. There's also something special for people who show up live that I won't be sharing anywhere else.
It's free. It's an hour. And it's built for exactly the person reading this newsletter.
|
|
From Accidental to Intentional: The Four Bridges Every Nonprofit Tech Leader Needs to Cross
|
What's in this issue:
β
Who's writing your project list β and why it's probably not you
β
The intentional vs. reactive project gap β how one deliberate pilot changed how leadership saw my role
β
Three moves to make this month β audit your time, propose one small pilot, and report results in the language that actually gets budget
β
The Four Bridges Webinar β free LinkedIn Live session next Wednesday, April 29 at 1 PM ET, with something special for people who show up live
β
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
When TAG was migrating our AMS to Salesforce, we were also planning our annual conference β our biggest event of the year, by a long stretch.
Most people would have let those two things collide and dealt with the fallout. We made a deliberate choice not to. We built intentional downtime into the Salesforce implementation so the conference could get the attention it needed. We front-loaded everything we could β gave our implementation partner detailed requirements early so they could keep building without us in the room. We cut our check-ins, moved to email summaries, made decisions asynchronously. The migration kept moving. The conference got executed. Neither one bled into the other.
That decision didn't come from a project management textbook. It came from recognizing that two major initiatives couldn't both run on pure reaction at the same time. Someone had to decide what got protected and when. That someone was me.
And that's the thing most accidental techies don't realize they're allowed to do.
Here's how most accidental techies actually build their project list.
Something breaks. You fix it and it becomes a project. A staff member complains about a tool. You research alternatives and it becomes a project. A vendor emails you three times. You take a demo and it becomes a project. Your executive director reads an article on a plane and mentions it in a meeting. It becomes a project.
Some of those are genuinely worth doing. But look at who's driving them. It's not you. Your judgment about what the organization needs, your read on where the real inefficiencies are β that stuff doesn't make the list because nobody asked for it. Other people's urgency fills the calendar, and you get very good at solving the problems they notice.
The ones you notice don't make the list.
When our organization moved to fully remote during the pandemic, I could have spent the next year in pure reaction mode, putting out fires as staff ran into problems working from home. Instead, I picked one process to actually fix: onboarding.
We were already heavy Slack users, so I found an app called Donut that could automate onboarding tasks and reminders from the moment we sent the formal hiring letter. We built a full 30/60/90 day plan for new hires and ran it automatically β check-ins, task assignments, feedback collection β without anyone manually managing every touchpoint. The new hire got a structured experience. The team got time back. And the feedback loop meant we could improve it with every hire.
It was a contained pilot. Six weeks to set up. A real pain point I identified, not one someone handed me. And because I wrote up the results in terms leadership could actually see β faster ramp-up time, less manager overhead, measurably better first 90 days for new staff β it opened a much bigger conversation about what else we could automate.
That's how it works. Not grand proposals. One small thing you initiated, documented honestly, and reported in the language of people who control the budget.
Join The Accidental Techie Community in Linkedin
|
Here's where to actually start. Three moves, this week.
This week, do a rough time audit.
What percentage of your current work is reactive β fixing, responding, fielding something β and what percentage did you actually choose? You don't need a time-tracking app. A 10-minute honest look at last week is enough. Most accidental techies are surprised by how lopsided it is. That number is your baseline.
In the next 30 days, propose one small pilot.
Not a system overhaul. Not a vendor evaluation. One contained project, four to six weeks, that solves a pain point you've identified on your own. Keep the scope small enough that a no isn't a big deal and a yes requires minimal approval. The point isn't to impress anyone. The point is to start deciding what you work on instead of waiting to be assigned it.
When it works, report back in the right language.
Not technical terms. Time saved. Staff hours redirected to actual program work. Processes that no longer require your direct intervention every time. Leadership doesn't say yes to technology. They say yes to outcomes. Give them the outcome first, and the technology becomes easy to explain.
The accidental techies who get asked "what else could we do?" are the ones who already answered "here's what I tried."
One more bridge. Communication β how to make sure the work you're doing actually registers with the people who decide what gets resourced. Honestly, it might be the hardest one yet.
Until then,
Hugo
P.S. The June cohort is coming together. Small group, six weeks, built around these four bridges with real accountability built in. If you've been reading this series and recognizing yourself in it, that's probably not a coincidence. Waitlist at theaccidentaltechie.org/waitlist.
Four Bridge Assessment
I put together a short assessment that gives you a clearer picture of where you're strong, where you're surviving, and where the real work is across all four bridges.
|
β