Why I Don't Believe in 'Networking' (And What I Do Instead)

I hate traditional networking. It's low-leverage and fake. As I pivot from freelancing to Cloud & SaaS, I'm using code, content, and 'Proof of Work' to build a career magnet instead.

I’m standing in a room in Dublin. The air conditioning is too loud, the pizza is cold, and the beer is warm. I’m wearing a name tag that’s peeling off my hoodie. A recruiter approaches me, glances at my chest, and asks, "So, Emmanuel, what’s your stack?"

I freeze. Not because I don't know my stack. But because this entire interaction feels fundamentally broken. It feels like a transaction where both sides are trying to extract value without providing any upfront.

This is "networking."

And honestly? I hate it. I don't believe in it.

Since moving to Ireland to study for my Masters in Cloud Computing, the number one piece of advice I get from career services and industry veterans is: "You need to network." They want me to go to meetups, shake hands, add people on LinkedIn, and send polite DMs asking for "coffee chats."

But here is the reality I’ve found pivoting from high-volume WordPress freelancing to Cloud Engineering and Indie Hacking: Traditional networking is a low-leverage activity. It scales linearly. You talk to one person, you make one impression. If you’re lucky, they remember you in six months.

I prefer high-leverage activities. I prefer systems. I prefer Proof of Work.

The Problem with asking "Can I pick your brain?"

When I was churning out WordPress sites, I didn't get clients by taking them out to lunch. I got clients because the algorithm saw I had five stars and a portfolio that looked good. It was meritocratic. The work spoke for itself.

Now that I'm architecting serverless solutions on AWS and building SaaS apps with Next.js, the game is more complex, but the rules of leverage remain the same.

The problem with traditional networking is that it asks for permission. It asks for someone's time - their most non-renewable asset. When you send a message saying "Hey, I'm a Cloud student, can we connect?", you are creating a burden.

I decided to stop doing that. Instead of networking, I started focusing on Signal Generation.

Signal Generation is the art of doing cool stuff and doing it in public. It’s about being so good they can't ignore you, but also making sure "they" can actually see it without you having to tap them on the shoulder.

My Alternative: The Permissionless Portfolio

If you want to be a Cloud Engineer or an Indie Hacker, your code is your currency. Not your handshake.

Instead of telling people I understand infrastructure, I build it. And I don't just build it; I document the hell out of it. This is what I call "Asynchronous Networking." It works while I sleep.

For example, I recently needed to deploy a scalable API. I could have just done it and kept quiet. Instead, I turned it into a reusable Terraform module. I wrote a blog post about the specific challenges of state management in AWS.

Here is what that actually looks like. Instead of a resume bullet point saying "Proficient in Terraform," I publish a repo that solves a specific problem:

resource "aws_s3_bucket" "state_storage" {
  bucket = "my-terraform-state-bucket"

  versioning {
    enabled = true
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_dynamodb_table" "state_locking" {
  name         = "terraform-state-lock"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

When I share this, I'm not asking for a job. I'm providing a solution. Other engineers see this. They critique it. They star it. That interaction is worth a thousand awkward conversations over cold pizza. It establishes competence immediately.

The "Indie Hacker" Approach to Career Growth

I view my career the same way I view the SaaS products I build. I am the product. The market is the employers or clients. Networking is just marketing.

In the Indie Hacker world, we talk about "Building in Public." This is just networking for introverts who value efficiency. When I'm working on a Next.js project using Supabase, I share the wins and the bugs.

Let's say I'm struggling with Row Level Security (RLS) in Supabase. A traditional networker would ask a mentor. I go to Twitter or a Discord community, post the code snippet, and ask for a specific fix.

I might post something like this:

// Trying to lock down user profiles but allowing public reads
// Is this RLS policy efficient for a table with 1M+ rows?

create policy "Public profiles are viewable by everyone."
  on profiles for select
  using ( true );

create policy "Users can insert their own profile."
  on profiles for insert
  with check ( auth.uid() = id );

create policy "Users can update own profile."
  on profiles for update
  using ( auth.uid() = id );

By doing this, I engage with other developers on a technical level. We bond over the shared trauma of debugging. That is a real connection. I have made more meaningful connections debugging Postgres policies in a Supabase Discord channel than I ever have at a "Tech Mixer."

Content as a Magnet

Writing is the most scalable form of networking.

When I write a deep-dive article on how to migrate a monolith to microservices on Azure, that article travels further than I ever could. It enters rooms I'm not invited to. It sits in the inbox of a CTO on a Sunday morning.

But you have to write about the hard stuff. Not "Top 10 VS Code Extensions." You need to write about the problems you solved that made you want to pull your hair out.

For instance, handling webhooks in a serverless environment is tricky. Timeouts, retries, idempotency. If I solve that using AWS Lambda and SQS, I write it down.

People find the article via Google. They read it. They realize, "Okay, Emmanuel knows his stuff." Then they look at my 'About' page. Then they email me.

That is Inbound Networking.

The dynamic is completely flipped. I am not the requester; I am the resource. In negotiations for a contract or a salary, being the resource gives you immense leverage.

The "Help First" Methodology

If I do have to interact directly with people, I use the "Help First" rule.

Most people network by taking. "Give me a referral." "Review my CV."

I try to network by giving. If I see someone struggling with a Next.js 14 server action issue on a forum, I don't just scroll past. I write a loom video or a code snippet solving it.

// Server Action for form submission in Next.js 14
'use server'

import { createClient } from '@/utils/supabase/server'
import { redirect } from 'next/navigation'

export async function signup(formData: FormData) {
  const supabase = createClient()
  
  const data = {
    email: formData.get('email') as string,
    password: formData.get('password') as string,
  }

  const { error } = await supabase.auth.signUp(data)

  if (error) {
    return { error: error.message }
  }

  redirect('/account')
}

Sending someone a working solution creates a debt of gratitude. It's human psychology. They remember you as the guy who fixed their auth flow.

If you do this consistently, you build a reputation as a problem solver. Reputation is the only network that matters. It’s durable. It survives platform changes. It survives market crashes.

Why This Matters for Cloud Engineering

In the world of Cloud, trust is everything. Companies are handing you the keys to their infrastructure. One bad config change can cost them thousands of dollars in minutes or expose their user data.

They aren't going to hire you because you have a firm handshake. They are going to hire you because they have seen your GitHub activity graph. They are going to hire you because they read your breakdown of the AWS Well-Architected Framework.

I am currently diving deep into Azure for my Masters. I could just study the slides. Instead, I'm building a hybrid-cloud simulation. I'm breaking things on purpose to see how the monitoring tools react.

When I interview, I don't talk about "passion." Everyone is passionate. I talk about the time I accidentally created an infinite loop in a Lambda function and how I set up billing alarms to prevent it from happening again. That is a story that resonates with engineers.

The Freedom of Opting Out

There is a massive mental health benefit to opting out of traditional networking. It removes the desperation.

You stop viewing people as rungs on a ladder and start viewing them as fellow builders.

It aligns perfectly with my goal of freedom. I want to build systems that work without me. My "network" should also work without me constantly maintaining it. By planting seeds - articles, code repos, helpful forum posts - I am building a network that grows organically.

So, if you see me at a tech event in Ireland, say hi. I’m not anti-social. But don't be surprised if I'm more interested in talking about your database schema than your job title.

And if you don't see me at events, it's because I'm at home, shipping code.

Practical Steps to Stop Networking and Start Building

If you want to pivot like I am, here is the playbook. It applies whether you are doing WordPress, Cloud, or SaaS.

Kill the Resume, Build the Portfolio: A resume says what you did. A portfolio shows what you can do. Move your best work to the front.
Open Source Everything: If it doesn't contain sensitive keys, it should be public. Your dotfiles, your learning notes, your failed projects. It shows activity.
Write for Two People: Write for yourself (to remember) and for the one person who has the exact same error log as you. Don't try to write for the masses.
Engage in Niche Communities: Leave the broad "Tech Twitter" and find the specific discord for the library you are using. Be the most helpful person there.

We are engineers. We build things. We optimize systems. Why are we trying to use a networking system from the 1980s that relies on physical presence and paper cards?

Update your stack. Update your career strategy. Build something today.