I will try to post at least once a month from now on!

Moving on, I’ve been pretty vocal lately on LinkedIn about Governance and Privacy by design in relation to GDPR and what practices are good and what are absolutely bad to have in your engineering team.

There’s a recurring scene I’ve lived through (and I bet many of you have too): someone asks for a data subject access request (DSAR), and suddenly the entire company is playing hide and seek with databases, backups, and log files. Marketing swears the data is in HubSpot. Engineering shrugs toward Postgres. Someone remembers a dusty S3 bucket with “user_logs_2018.zip.”

That’s not compliance. That’s chaos.

And under GDPR, chaos is expensive.

GDPR Isn’t Just Law, It’s Architecture

The GDPR gets framed as legal overhead, a box ticking exercise for the lawyers. But the truth is simpler (and scarier): it’s an architecture problem. The regulation is clear about what you can’t do: hoard personal data forever, forget about retention, or shrug off backups.

The less obvious part? GDPR pushes you to design systems differently. Privacy by design and by default isn’t a slogan, it’s Article 25 of the regulation. It means your database schemas, pipelines, and log configurations need to assume that data must one day be deleted, anonymized, or ported elsewhere.

Treating compliance as an add on is like deciding you’ll install brakes after the car’s already on the highway. You can try, but you’ll either crash or pay a fine the size of your annual revenue.

Data Governance: Boring Until It Saves You

Nobody gets excited about data governance. It’s rarely celebrated at board meetings, and if you call it a “cost center,” you won’t be wrong about how most execs see it. But it’s the only way GDPR stops being an existential risk and starts being a competitive advantage.

If you don’t know where data lives, who can touch it, or how long it stays, you don’t have governance, you have a time bomb.

And GDPR doesn’t care whether you’re Meta or a 10 person SaaS startup. You’re expected to know, to control, to prove. “We think it’s in staging” is not a compliance strategy.

The Myths We Tell Ourselves

• “It’s just a log.” Nope. IP addresses, device IDs, session tokens, all personal data. Keep them forever “just in case” and you’re violating storage limitation. Legitimate interest for debugging exists, but it doesn’t give you a free pass to hoard.

• “We’ll clean this up later.” Translation: “we’ll wait until a regulator or a breach forces us.” By then, “later” comes with a 4% of revenue price tag.

• “We’re too small to matter.” Small businesses don’t dodge fines. They just get smaller fines more often, cookie banners misconfigured, DSARs ignored, data retained too long. Death by a thousand cuts.

Privacy by Default Means Building Differently

Here’s the cultural shift GDPR forces: instead of designing systems that can delete or anonymize data if needed, you design them so they always do, unless there’s a reason not to. Retention policies, automated deletions, anonymized logs, those aren’t edge case features. They’re defaults.

When you hear “privacy by design,” don’t picture a checkbox. Picture:

• Every pipeline with a retention mechanism.

• Every backup with an expiration timestamp.

• Every log with anonymization baked in.

And yes, that means telling your engineers that “keep everything forever” is no longer a valid data model.

How to Actually Build Privacy by Design

It’s one thing to say “privacy should be baked in from the start.” It’s another to make that real in pipelines, schemas, and day-to-day decisions. Here are some patterns I’ve seen work (and break less often under audit):

• Purpose-driven schemas. Don’t dump everything into one giant warehouse. Split by purpose (marketing, finance, support) and tie access roles directly to those purposes. In Snowflake, that looks like:

create schema marts_marketing;

grant usage on schema marts_marketing to role role_marketing_read;

grant select on all tables in schema marts_marketing to role role_marketing_read;

If you can’t answer why you’re storing something, you probably shouldn’t.

• Minimize early. Don’t collect everything “just in case.” Strip or anonymize PII at ingestion—especially logs. In app pipelines, it can be as simple as masking emails before they ever land:

# Example regex for log redaction

s/[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/[redacted]/gi

If you don’t land it, you don’t need to delete it later.

• Retention as default. Data should die on schedule. Lifecycle rules in storage buckets, TTL columns in databases, and automated jobs to purge expired rows. For example, in Snowflake:

create or replace task purge_user_events

schedule = 'USING CRON 0 3 * * * Europe/Rome'

as delete from user_events where expires_at <= current_timestamp();

Deletion shouldn’t be a sprint you run before an audit.

• Mask or tokenize by default. Keep analytics useful with hashed identifiers or masking policies, and reserve raw access for the rare role that truly needs it.

create masking policy mask_email as (val string) returns string ->

case

when current_role() in ('ROLE_PRIVACY') then val

else '***'

end;

alter table raw.users modify column email set masking policy mask_email;

Most queries never need the real email address anyway.

• DSAR readiness. A subject index or crosswalk model that maps all identifiers back to one subject saves you from the DSAR scavenger hunt. In dbt, that might be a simple crosswalk model. If a user asks for their data, you should know exactly where to look.

• Synthetic data in dev/staging. Stop pushing prod PII into lower environments. If you must sample, mask deterministically so joins still work. With dbt + Faker seeds, it’s trivial. Debugging shouldn’t require real customer data.

Compliance as Strategy

Here’s the real kicker: companies that take GDPR seriously don’t just stay out of trouble, they build trust. Users feel safer. Deals close faster when procurement sees strong governance. And ironically, systems that are compliant are usually cleaner, cheaper, and easier to maintain.

The worst fines don’t come from regulators. They come from the wasted time, the messy architectures, and the seven year old zip file nobody remembers until it lands you in the news.

So next time someone tells you GDPR is “just legal stuff,” remind them: it’s actually technical debt. And unlike other kinds of technical debt, you don’t get to decide when you’ll pay it down.

Final thought: GDPR isn’t going away. It will keep evolving, AI, biometrics, whatever comes next. The only winning move is to stop thinking of compliance as a tax, and start thinking of it as design.

Because “just a log” can end up costing a lot more than a log.

Simple enough, right?

But within an hour, we realized we had a problem:
What exactly did they mean by ARR?

Because Finance had one definition.
RevOps had another.
Same acronym. Same company. Two conflicting truths.

If we had jumped straight into the build, we would’ve delivered something technically sound and strategically useless.

What no one had said out loud (but everyone assumed):
Their definition of ARR was the definition.

The Real Skill: Mediation

This is the quiet part of the job that no one teaches:

• Interpreting vague requests before they become misaligned outputs.

• Mediating between stakeholders who think they’re aligned, but aren’t.

• Unpacking not just what someone’s asking for but why they’re asking in the first place.

When you do that well, you don’t just build dashboards.
You reconcile competing worldviews.
You turn tension into clarity.
You stop being just the “data person” and become something else entirely:
a conflict resolver.

It’s uncomfortable work. It means slowing things down. It means telling smart people they’re not aligned. But it’s what turns data from a function into a force.

Where This Shows Up Every Day

Business → Data
A request like “build an ARR dashboard” sounds clear.
But unless you ask:

• Who uses this?

• What’s it for: forecasting, performance reviews, investor reporting?

• Why is this definition different from the others?

...you’ll end up reinforcing silos and confusion. You’ll bake disagreement into production.

Data → Business
The other half of the job is making the outputs legible.
It’s not enough to be technically correct, you need to communicate in a way that builds consensus and action.

Interpretation isn’t about dumbing things down.
It’s about making complexity useful. And usable.

Why It’s Rare (and Why It Matters)

This skill doesn’t show up in bootcamps.
It’s not measured in performance reviews.
There’s no “cross-functional nuance” badge on LinkedIn.

But it’s the skill that prevents:

• Useless reports

• Mismatched goals

• “Why doesn’t this metric match what Finance has?” Slack threads

It’s the invisible thread that holds real impact together.

How to Practice It

A few things that help me when the ambiguity kicks in:

• Assume nothing. Especially when two teams use the same word. Clarify it out loud. Put definitions in writing.

• Ask how the data will be used. A dashboard for Finance isn’t the same as one for the exec team, even if the metrics look similar.

• Reflect misalignment back to the room. “It sounds like we’ve got three different ARR definitions. Can we agree on which one serves this use case best?”

• Write documentation that captures trade-offs. “Here’s why we chose this version of ARR and what it does not represent.”

These aren’t technical skills.
They’re connective ones.
And they’re what separate builders from strategic operators.

Final Thought

If your stakeholders always agree with your dashboards, you’re probably just confirming their biases

If your job was just to write code, you’d already be done.

But that’s not the job.
The job is to make meaning out of ambiguity and still ship something that works.

Have you ever had to reconcile conflicting definitions across teams?
How did you handle it?

Drop a story in the comments. I promise that someone else has lived it too.

So of course, I decided to build a self-service data platform.

It wasn’t an obvious move.
People usually wait until pain becomes intolerable. Until the data team is swamped, dashboards are breaking, and nobody trusts the numbers. That’s when self-service feels justified.

I didn’t wait.

Not because I wanted to future-proof everything. Not because I love semantic layers.
But because I knew that if we didn’t start early, we’d bake in bottlenecks that would cost us 10x later.

The Vision: Data Without a Middleman

The idea was simple.
Product teams should be able to onboard their own data, calculate metrics, and build dashboards without depending on us for every step.

That meant rethinking the data team’s role.
Not support. Not dashboard monkeys.
But enablers. Builders of a platform that others could use.

We shifted toward that mindset early. And it’s already paying off.

But as with anything ambitious, reality had other plans.

Where Theory Breaks Down

Self-service sounds clean in theory.
In practice, it’s a balancing act. And some days, a circus act.

Here’s what we learned.

1. Self-service doesn’t mean stepping away

When the stakes are high, a new product launch, a major strategic shift, you don’t wait for teams to become fluent in your data tooling. You jump in. You work alongside them. You act like a product team.

The platform helps them move fast. Your hands-on support helps them not crash.

2. Context isn’t optional

You can give people the sharpest tools in the world.
But if they don’t understand the data, its lineage, quirks, caveats, they’ll misuse it.

Self-service requires storytelling. Documentation. Slack threads.
Sometimes, it just means sitting down and talking through what a metric actually means.

3. Some things just shouldn’t be self-served

Recurring reports? Go for it.
Prepping metrics for a board meeting with three definitions of 'active user'? Maybe not.

We learned to pick our battles.
Not everything needs to be democratized. And that’s okay.

So What Does “Success” Look Like?

Not perfection. Not purity.
Just adaptability.

A good self-service setup doesn’t remove the data team.
It frees the data team, to focus on deeper problems, build smarter tools, and step in where it actually matters.

Here’s what’s working for us:

• Flexible roles. We help when needed, fade into the background when we’re not.

• Data literacy, not just access. Teaching teams how to interpret data is more valuable than giving them more dashboards.

• Iterating in the open. We update our tools, metrics, and training in response to real needs, not just a roadmap.

The Hard Truth

Self-service is not a checkbox you tick.
It is not a maturity model level.
It is a bet, that with the right scaffolding, people will step up and use data well.

Sometimes they do. Sometimes they need help.
But when it works, it scales better than any dashboard ever could.

If you're navigating a similar transition, I’d love to hear your take. What’s worked in your org? Where did it break down?

(And if you need a laugh, this comic absolutely nails it: Self-Service Analytics Comic – Holistics)

I thought the hardest part would be scaling pipelines, setting up architectures, choosing the right stack.
I was wrong.

The real challenge?
Building belief: in the data, in the systems and in each other.

Because when the numbers get uncomfortable, when dashboards reveal inconvenient truths, when people start quietly doubting the story the data tells, that is when leadership shows up.
Or doesn’t.

The Myth of Technical Leadership

When you first step into leadership, it’s easy to think the hardest work will be technical.

After all, that is what got you here:

• Knowing the tools

• Debugging the weird failures

• Writing the plans everyone else followed

But managing data teams isn’t about out-coding your team.
It’s about creating an environment where people can face uncertainty together, and keep moving.

The best systems in the world are useless if the people around them don't believe in what they are building.

And belief isn’t built by architecture diagrams.
It is built, slowly and stubbornly, through trust.

Three Lessons Nobody Tells You

There are things you only learn the hard way.
Here are three of them.

1. Trust Is Your Real Product

Your dashboards?
Temporary.
Your tech stack?
Already aging.

But trust?
Trust compounds.

If your team, and your company, trust the data, they make better decisions, faster.
If they don’t, every meeting becomes a battlefield of second-guessing.

Technical issues are solvable.
Broken trust quietly erodes everything until the team falls apart.

2. Translation Beats Perfection

Early in my career, I obsessed over getting every data model just right.

Now?
I know that half my job is translation.

Translating messy business questions into technical requirements.
Translating complicated models back into language normal humans can act on.

The best data leaders are not the ones who build the perfect pipeline.
They are the ones who can explain what the pipeline actually means, and why it matters.

3. Data Work Is Emotional Work

You are not just building systems.

You are dealing with:

• Founders terrified their KPIs are a lie

• Teams who feel blamed by the numbers

• Analysts scared they will be scapegoated when data exposes bad decisions

Good leadership means making space for these emotions, without letting them derail the work.

The hardest conversations you will have will not be about schemas or queries.
They will be about what the numbers say, and whether people are ready to hear it.

Closing Reflection

Nobody prepares you for this side of data leadership.

They hand you technical books.
They recommend project management frameworks.
They tell you to learn the latest tool.

But nobody tells you the real work is human.
Hard conversations, quiet moments of doubt, small daily choices to tell the truth even when it is easier not to.

Leading data teams is not about having all the answers.

It is about helping people trust the journey, even when the numbers feel uncomfortable.

And maybe that is why it matters so much.

Since I moved back I started being interested in the Italian real estate market because I might want to buy soonish. However here the market is very different from what I’ve been used in Ireland.

In Ireland when you want to sell your house you set a price, usually pretty low, to get people in the door and then there will be an auction with all interested parties bidding against each other until a set time.

In Italy, usually, they set a higher price, higher than what they’d settle for and then you negotiate down to meet in the middle.

So the question I want an answer for is: what is a reasonable price for the kind of apartment I might be looking for?

If I just look at the ads on the usual websites I only get one side of the medal. Unfortunately there’s no open property price registry in Italy where you can just browse how much a property was sold at. There are ways, using SPID (a form of ID you can use in Italy to access a bunch of governmental websites) to know sale prices up until the building, but you have to know exactly what you’re looking for and there is no way to scrape it or get an overview.

From Excel to Streamlit (with several detours)

Once I requested the CSV dataset from the Italian Revenue Office, I was this close to opening it in Excel. But then I thought… nah. That’s not the vibe.

I wanted to explore new tools. I wanted a better way to slice and understand the data. So I built this little web app using Streamlit. It’s simple, but it works. And apart from a touch of Python, I used a whole stack I’d never touched before:

• uv (instead of pip)

• DuckDB (lightly)

• Streamlit for the UI

• Github Actions for automation

• Cloudflare Tunnels for easy deployment

• And a healthy dose of curiosity

Source code’s here, by the way: GitHub repo

Building it, breaking it, fixing it

The codebase is admittedly a bit messy. I even tried building an interactive map of Italy, clickable down to the municipality level, but that rabbit hole got deep fast. Priorities, right?

Here are a few small things that worked:

• To avoid re-creating tables on every reload, I used a quick DuckDB check:

try: conn.execute("SELECT 1 FROM _initialized LIMIT 1")

• Plus a simple table init block:

conn.execute("CREATE TABLE _initialized (initialized_at TIMESTAMP);")
conn.execute("INSERT INTO _initialized VALUES (CURRENT_TIMESTAMP);")

• I cached dropdown options like this:

@st.cache_data(hash_funcs={duckdb.DuckDBPyConnection: id}) 
def get_regions(conn): 
  return conn.execute("SELECT DISTINCT Regione FROM luoghi ORDER BY     Regione").df()

• And I used some very naïve if logic to keep state across Streamlit reloads. It works… mostly.

As for uv, I have to say: it’s smooth. Definitely faster than pip, with solid docs and zero headaches. I might keep using it.

And then there’s GitHub Actions. Somehow, after over a decade in tech, I’d never used it. I’ve worked with GitLab CI, Jenkins, Azure Pipelines…you name it. But GitHub Actions felt refreshingly powerful. You could run entire data pipelines there for free. Should you? Probably not. Could you? Definitely.

Last shoutout: Cursor. That thing is an absolute productivity cheat code. Way beyond Copilot. I still need to try Windsurf, but wow!

Here’s a bonus pic of me, deep in Cursor mode:

What’s next?

The data is useful, but not perfect. It doesn’t factor in property conditions or energy ratings, so there’s still a gap.

Next step? I’d love to compare this dataset with listings from popular real estate websites to see how asking prices stack up against actual transaction averages. That’ll also give me a better excuse to explore DuckDB more seriously.

Another idea: loading all the historical files to build a time series of prices across regions and municipalities. Because nothing says “fun” like a good old price trend analysis.

Want more nerdy real estate experiments and data deep-dives like this? Hit subscribe and stick around.

When people ask me how to start a career in data, I know what they’re really asking.

They’re not looking for a roadmap. They’re looking for permission.
Permission to start messy. Permission to not know everything. Permission to learn in public without feeling like a fraud.

I get it. I’ve been there.
Eyes wide, twenty browser tabs open, one foot in a Udemy course and the other in a YouTube tutorial about Docker. It felt like everyone else was fluent in Spark, Kubernetes, and five flavors of SQL.

Meanwhile, I was still Googling “what is a data pipeline.”

Here’s the truth: everyone starts like that. The people you admire now once had no idea what a left join did. They just stuck around long enough to stop panicking every time someone mentioned “partitioning.”

II. If I Had to Start Again (From Scratch)

Let’s pretend I lost all my experience. No resume, no network, no projects. Just curiosity, Wi-Fi, and a bit of time.

First, I wouldn’t try to master everything at once. That was one of my earliest mistakes, and it left me more anxious than informed. Instead, I’d keep things simple and aim to solve real problems. That means learning just enough SQL and Python to do useful things. Not to impress recruiters or ace quizzes, but to answer questions with data and automate the boring stuff.

I’d avoid building another dashboard about Netflix movies. I might help a friend’s side hustle clean up their client list, or organize data for a local non-profit. Even cleaning up a messy spreadsheet teaches you more than you’d think. There’s something magical about building for someone who actually needs it.

And as I worked, I’d document everything. I’d post the wins, the errors, the ugly in-between bits. Not because I’m a content creator, but because when you share your learning out loud, you create accountability and attract people who want to help or hire you.

I’d resist the urge to hop from tool to tool. There’s always another library, another framework, another “must-learn” concept. The people who grow fastest tend to be the ones who go deep enough on one thing to build something functional. Confidence follows consistency, not complexity.

III. Analyst, Engineer, Scientist: Pick the One That Feels Like You

One of the first decisions you’ll face is what kind of data role to pursue. The titles sound interchangeable, but the day-to-day work is wildly different.

If you love finding patterns, answering questions, and making charts that tell a story, you’ll likely enjoy being a data analyst. It’s less about engineering and more about curiosity and communication.

If you get excited by systems, pipelines, and making things run reliably behind the scenes, data engineering might be your lane. It’s about building and maintaining the infrastructure that moves data from place to place.

And if you’re drawn to modeling, stats, and testing ideas with real-world data, data science could be a fit. But it’s not all machine learning and magic. It’s often slow, iterative, and messy.

You don’t need to choose forever. Just start where your strengths are and follow the problems that keep your brain buzzing.

IV. You’re Not Behind

It’s easy to look around and feel like you’re already late. Like the doors have closed and everyone else got a head start.

But the truth is, most people are winging it more than they admit. Everyone’s highlight reel hides a lot of fumbling behind the scenes. Even now, I find myself Googling things I’ve supposedly known for years.

You’re not behind. You’re just early.
And if you keep showing up, keep building, and stay curious, that early start will turn into real momentum.

Let’s Keep the Conversation Going

If you’re breaking into data, I’d love to hear what you’re working on. What’s confusing? What’s exciting? What’s stopping you from taking the next step?

Hit reply or leave a comment. And if this helped, send it to someone else navigating the same fog.

This space is big enough for all of us. You don’t have to figure it out alone.

Everywhere I have worked, the jokes are the same.

"Must be nice, just sitting in meetings all day."
"What do managers even do?"
"My manager just forwards emails and books meetings."

Honestly, I get it.

Early in my career, I thought the same. Management looked like a weird career graveyard for people who could not or would not code anymore.

Then I became a manager.

And I realized two things.

First, yes, there are absolutely terrible managers out there. Lazy ones. Political ones. Clueless ones. Managers who are exactly the stereotype.

Second, and way more important, good management is some of the hardest, messiest, most emotionally draining work I have ever done.

Not because it is complicated like writing code.

Because it is complicated like dealing with humans.

Especially when you are managing an international, fully remote team, spread across cultures, languages, and timezones, where communication is hard, trust takes forever, and context disappears in an instant.

So this is not a defense of managers.

This is a field report.

Here is what the job actually looks like when you care. Here is what keeps us up at night. Here is why good management is invisible, and why invisible work is still work.

And maybe, just maybe, next time you think your manager does nothing, you will pause.

Not for long.

Just long enough to wonder what they are doing behind the scenes so that you do not have to.

1. The Invisible Work of Engineering Management

One of the biggest misconceptions about engineering managers is that we do nothing. Or worse, that we only do meetings and status updates and then go around taking credit for other people’s work.

The reality is that the job is absolutely packed with work, but most of it is invisible if you are not the one doing it. It is invisible because it happens in conversations, in Slack DMs, in documents nobody reads, in fights you prevent before they happen. It is invisible because it looks like "talking" but it is actually "thinking through problems together." It is invisible because good management removes friction before you even notice it was there.

But the real killer is context switching.

As an IC, you usually have 1 or 2 big problems in your head. As a manager, you juggle 15 at any given time. Someone’s unhappy with their project. Someone else is underperforming. You need to review next quarter’s hiring plan. There is an exec review coming up. Oh and your team just accidentally shipped a bug to production. Meanwhile, you are also supposed to write a performance review for someone while another person needs coaching on stakeholder communication.

Your brain never stays in one place long enough to feel productive. Instead, you hop between topics like a browser with 75 tabs open, all auto-refreshing and screaming for attention.

Your calendar? Forget it. Meetings show up like pop-up ads. One-on-ones, team syncs, skip-levels, leadership calls, hiring interviews, stakeholder updates, ad-hoc "quick chats" that are never actually quick.

Add to this the fact that decisions never stop coming. You are constantly making choices, about people, projects, priorities, words. And while many engineers love the clarity of solving a technical problem, management is the opposite. There is rarely a clean, right answer. There is only tradeoff after tradeoff after tradeoff.

By the end of the day, you are exhausted not because you "worked hard" in the traditional sense, but because your brain has been running an emotional operating system at 100 percent CPU for hours. And most of that work is completely invisible.

2. Managing People is Hard, Managing Humans is Harder

Managing people sounds simple on paper. Set expectations, give feedback, check progress, unblock them, repeat.

Managing humans is an entirely different sport.

Every person comes with their own story, their own fears, their own triggers. What motivates one person drains another. What sounds like helpful feedback to you might sound like an attack to them. What sounds like silence to you might sound like disappointment to them.

You cannot treat everyone the same. That is not fairness, that is laziness.

The job is part coach, part therapist, part translator, part bad news delivery service. Some days people want advice. Some days they just want to vent. Some days they want you to shut up and listen. Knowing which day is today is an underrated skill.

Feedback is a minefield. Say it too softly and it gets ignored. Say it too directly and it crushes someone’s confidence. Say it at the wrong time and it ruins trust. Get it wrong enough times and people stop telling you the truth.

And when someone is struggling, it does not feel like a work problem, it feels like a human one. You stay up at night replaying the conversation. Did I say it wrong? Did I support them enough? Are they scared of me now? Are they scared for their job? Are they okay?

People issues are heavier than technical ones because code does not cry in one-on-ones.

Code does not feel stuck, or lost, or afraid. Code does not wonder if it is good enough. People do.

That is why managing humans is the hardest part of this job.

3. Remote, Async, Global: the Hard Mode

Managing a team is already difficult. Managing a remote, international, async team is playing the game on hard mode with friendly fire always on.

Forget all the management advice that starts with "just grab coffee together" or "swing by their desk." There is no desk. There is no coffee. There is only Slack, Zoom, Google Docs, and the eternal hope that your words land the way you meant them.

Trust, which is the foundation of any good team, takes forever to build remotely. In an office, you build trust almost accidentally. In little moments. Jokes by the coffee machine. Sighing about the same bad meeting. Seeing someone’s body language when they are struggling.

Remote strips all of that away. Now you have to manufacture trust on purpose. Write more. Talk more. Check in more. And still, sometimes it feels like yelling into the void.

And then there is culture. Not company culture, but actual culture. People from different countries carry different habits, different assumptions, different social rules.

Silence can mean respect in one culture, disapproval in another. Saying "no" directly is polite in some places, rude in others. Sarcasm is hilarious in one country, offensive in another. Feedback can feel clear to you and aggressive to them. Or too soft. Or just confusing.

Add to this the timezone problem. Async work sounds beautiful in theory. In practice, it means someone is always asleep when a decision needs to be made. Someone always waits longer. Someone always feels left out.

So you start overcompensating. Writing longer Slack messages. Recording Looms. Leaving detailed context in Jira tickets. And still someone will say "Sorry, I missed this" because of course they did, they are human, not a notification-processing machine.

Even video calls, which are supposed to bring people closer, drain your energy faster than real life. Staring at a grid of faces, trying to read micro-expressions through bad internet connections, wondering if that long pause means confusion or someone is just lagging.

Remote management is not just logistics. It is emotional labor at scale. Every message, every call, every decision needs extra care, extra clarity, extra patience.

Because when you cannot read the room, you have to build the room.

4. The Weight of Caring

This is the part nobody tells you about management.

The hardest part is not strategy. It is not performance reviews. It is not planning or process or communication.

The hardest part is caring.

Caring deeply, genuinely, fully about a group of humans who do not belong to you but who trust you, at least a little, with their time, their growth, and their well-being.

When you care, the job follows you home. It stays in your head when you are cooking dinner. It shows up in your dreams. It sits with you on weekends.

You worry constantly.

You worry that people are burning out but not telling you.
You worry that someone feels isolated and disconnected.
You worry that someone is unhappy but too polite to say it.
You worry that someone is about to quit and you did not see it coming.
You worry that someone is quietly disengaging because they feel stuck or underpaid or undervalued.

And you worry even more when it is your job to do something about it, but you are not sure what.

Sometimes you have to tell someone they are not performing. And you know that conversation will probably ruin their week. Maybe their month. Maybe their confidence. Maybe their relationship with you forever. But you have to say it because it is the job.

Sometimes you have to tell someone they are doing great, but the company cannot give them a raise right now. And it feels like lying, even if you are being honest.

Sometimes you have to protect your team from leadership chaos, layoffs, budget cuts, bad decisions. Not by hiding the truth, but by holding the weight of it until it is the right moment to share.

Sometimes you have to tell a team of smart, talented, committed people that their project is getting killed anyway.

And sometimes you just sit there, staring at Slack, wondering how to phrase one sentence that will carry the right amount of empathy, clarity, and honesty, without breaking the person on the other side.

It is invisible work.

It is emotional work.

And it is the part of management that nobody really prepares you for.

5. No Playbook, No Safe Answers

One of the most frustrating parts of being a manager is realizing just how little of the job comes with a clear answer.

Engineers love clear answers. This code works, that code does not. This query runs fast, that query times out. There is a bug, you fix the bug.

Management is not like that.

Management lives in the world of tradeoffs. Everything you do is a choice between imperfect options. Everything is situational. Context is everything, and context changes all the time.

You want to give people freedom but you also want consistency. You want transparency but you cannot always share everything. You want velocity but you cannot burn people out. You want psychological safety but you also have deadlines and performance expectations.

Every decision has second-order effects you cannot fully predict.

Make a decision too fast, people feel left out. Make it too slow, people feel blocked. Be too soft, people get complacent. Be too direct, people get defensive. Focus too much on the top performers, the rest feel ignored. Focus too much on struggling folks, the best people get bored.

And the advice out there? Absolutely useless half the time.

"Trust your team" but also "Be hands-on."
"Give feedback early and often" but also "Pick your battles."
"Be transparent" but also "Do not create panic."

You will get blamed either way.

Say yes to leadership, your team thinks you sold them out. Say no to leadership, you might be out of the loop next time. Try to keep everyone happy, congratulations, now nobody is happy.

But the worst part is this: people expect you to project clarity and confidence when very often you have neither.

You are figuring it out just like everyone else. Only you have to look like you are not.

Nobody wants to hear "I do not know" from their manager too often, even if it is true. Nobody wants their manager to sound uncertain, even if uncertainty is the most honest possible answer.

So you live in this weird state of mind where you are constantly doubting yourself, second-guessing decisions, replaying conversations, while also trying to be the calm, steady presence everyone needs.

There is no playbook for this. There is only judgment, experience, and luck. And even those fail sometimes.

6. Why We Still Do It

After all this, the obvious question is why would anyone willingly choose this job.

It is a fair question.

Most of the rewards of management are slow, subtle, and personal. There is no deploy moment. No green checkmark. No dopamine rush from closing a ticket.

But when it works, it really works.

When you see someone grow into a role they thought was too big for them. When you watch someone present confidently after months of working on their communication. When you see someone who once doubted themselves become the person others go to for help.

When the team gels. When people support each other without being told. When the culture is strong enough that you do not have to police it. When people say "this is the best team I have ever worked with" and you know they mean it.

That is what makes it worth it.

Management is not about power. It is not about control. It is not even about impact in the way ICs think about impact.

It is about shaping an environment where people can do their best work without fear, without politics, without burning out.

It is about designing systems of work, not just systems of code.

It is about building a little human infrastructure inside the messy world of tech.

It is about helping good engineers become good humans too.

But make no mistake. It is hard. It is messy. It is often lonely.

It is a job for people who can care deeply without losing themselves.

A job for people who can take hits quietly so their team does not have to.

A job for people who understand that success looks like other people shining.

And when it works, that is the best feeling in the world.

Look, I get it.

Engineers love to shit on managers. It is basically a sport at this point.

"They do nothing."
"They are just middlemen."
"They block me from shipping."
"They do not even write code."

Cool. But here is the thing.

If your manager really did nothing, your life would be absolute hell.

You would be in meetings all day. Fighting for resources. Arguing priorities with five other teams. Chasing feedback from stakeholders who ghost you. Trying to figure out why your compensation went nowhere for a year. Navigating company politics you do not even know exist.

Good management is invisible on purpose. It is not an accident. It is infrastructure. And like any good infrastructure, you only notice it when it breaks.

Bad managers make your life harder.
Good managers make your life quieter.

So sure, keep the memes coming. Keep roasting us in private Slack channels.

Just remember who is in the room fighting for your promotion while you are shitposting about how useless managers are.

Bad managers leave scars.
Good managers leave space.

And if it looks like we are doing nothing, that probably means we are doing it right.

Here’s the thing, remote work can be amazing. But only if we’re all intentional about how we do it. So here are some hard-earned tips, tricks, and general life lessons to help your remote engineering team not just survive, but actually work well together.

1. Write It Down or It Didn’t Happen

Remote teams live and die by documentation. If it’s not in a doc, a wiki, or a Slack thread with clear context, it’s just tribal knowledge floating around in someone’s brain... and that someone is probably on vacation next week.

Document decisions. Document processes. Document your weird edge case workaround that took you 4 hours and 3 existential crises to debug. Future you, and your teammates, will thank you.

2. Talk in Public. DMs Are Where Context Goes to Die.

Stop having all your technical discussions in DMs. I get it, it feels easier. No one will judge your half-baked idea or typos. But if your team doesn’t see the conversations, they can’t help. They can’t learn. And they definitely can’t debug that weird issue next time it comes up.

Use public channels. Thread your thoughts. Embrace a little digital vulnerability.

This is even more important for support and requests. Any request to your team should go to a public channel. Why?

First of all: context switch. If people come to you personally when they need something from your team, you kind of have to answer right? That distracts you from what you’re doing and it decreases your productivity. If there is a specific place where you can check all requests at once it’s much easier on you and it can be checked at your own pace and schedule.
Furthermore, you can get metrics on the amount of requests or the most common and so on.

3. Don't Just Say “Hello”. Don’t Ask to Ask.

“Hey.”
“Hi, can I ask you a question?”
Sure. You just did.

This one’s simple. If you need something, just say it. “Hey, I’m trying to figure out why this Lambda won’t trigger from this S3 event. Do you have 5 minutes to pair?” is so much more helpful than a five-message dance around the actual point. Respect everyone’s time, including yours.

Honourable mentions are: https://nohello.net/en/ and https://dontasktoask.com/

4. Meetings: Not Too Many, Not Too Few, Just Enough to Stay Sane

Too many meetings and everyone’s calendar looks like a game of Tetris played by a sadist. Too few, and suddenly people are going rogue on major architecture changes because “it felt right.”

The trick is to tune your meeting cadence to what your team actually needs. Weekly check-ins? Maybe. Daily standups? Only if they’re useful. Async updates? Fantastic, if people actually read them. Adapt, experiment, and don’t be afraid to kill a meeting that no longer sparks joy.

5. Create Accountability Without Creating Fear

Blame culture is the silent killer of remote teams. If folks are afraid to admit mistakes, they’ll just stop talking. And then you’ll be blindsided by the thing they didn’t say when prod goes down at 3am.

Instead, create an environment where owning up is safe. Where “I broke it” is met with “Cool. Let’s fix it together” instead of an all-hands investigation and a passive-aggressive postmortem.

Accountability works best when people feel trusted, not watched.

6. Celebrate Everything. Loudly. Often. Even the Little Stuff.

Got a teammate who finally cleaned up a mess of spaghetti SQL? Celebrate it. Someone fixed a flaky test that’s been haunting your CI like a ghost with bad timing? Shout them out.

Wins aren’t just launch-day fireworks. They’re the tiny victories that keep your team going. And in a remote world, you have to go out of your way to make people feel seen. Post gifs. Use emojis. Go full cringe if you have to.

Because when people feel celebrated, they stay engaged. And happy teammates build better things.

7. Overcommunicate Just Enough

In an office, you get all kinds of passive context. Who’s talking to whom, what project is hot, what’s breaking in real time. Remote? You get radio silence unless someone pipes up.

So yeah, overcommunicate, but with taste. “Just deployed the new version, watching logs” is great. “Taking lunch, had a burrito, mildly regretting it”... maybe keep that to the personal channel.

And please, say when you’re stuck. You’re not annoying anyone. You’re preventing the team from wasting hours guessing why the build’s broken.

8. Async ≠ Ignoring People

Async is powerful. It respects everyone’s time zones, schedules, and deep work. But it doesn’t mean “reply whenever you feel like it.” Especially when you’re blocking someone.

If someone tags you with a clear ask, acknowledge it, even just “got it, will reply by EOD.” Don’t ghost your team. Ghost your high school friends who ask for crypto advice instead.

9. Don’t Confuse Activity with Impact

“Online 9 to 6, green dot always on, Slack replies in under a minute.” That’s not productivity. That’s performance theater. And it burns people out fast.

Trust your team to manage their time. Measure outcomes, not hours. If someone disappears for a day and comes back with a beautifully optimized Snowflake model, you don’t need to know when they took their lunch break.

Micromanagement is just insecurity wearing a manager badge.

10. Rituals > Random Vibes

Remote teams need intentional culture, because you don’t get accidental culture from hallway chats. That’s where rituals come in.

Think: weekly demo day. Friday shoutouts. Monthly “what did we learn?” sessions. Even dumb traditions like “Meme Monday” can help a team bond across time zones.

Rituals make distributed teams feel less like isolated satellites and more like a weird little crew that actually wants to work together.

That’s a Wrap

Remote work isn’t rocket science, but it does require more than just Slack and Wi-Fi. Start with these ten things and you’ll already be ahead of 90% of teams out there.

Got a favorite remote work tip, or a horror story? Hit reply and share it, I might include the best ones in the next issue.

Let’s say you’re an Italian professional, and you’ve just landed a full-time remote role with a company based in the US or elsewhere in the EU. The catch? They don’t have a legal entity in Italy. So how do they actually hire you?

Good news: this setup is increasingly common, and there are two main paths that make it possible.

Option 1: Self-Employed with a VAT Number (Partita IVA)

Even though it’s technically “freelancing,” many people go this route for full-time remote positions where the company is your only client. You’ll open a Partita IVA and invoice the company monthly or bi-monthly as a contractor.

Important: this is still a full-time commitment, and the company expects you to work like any other employee, they just can't hire you directly.

Pros:

• Flexibility in how you manage your work and income.

• Potential tax advantages depending on your regime and deductions.

• You're not tied to an employer's payroll system or HR stack.

Cons:

• You’re fully responsible for taxes, VAT filings, INPS contributions, healthcare, and pensions.

• No built-in employment benefits unless you set them up yourself.

• You’ll need a good accountant—and strong nerves.

Time off? Most companies offer you paid vacation days, often even more than their internal policy, to make up for the lack of local public holidays coverage and other employee perks.

Option 2: Be Hired Through an Employer of Record (EoR)

An Employer of Record is a third-party service that hires you on behalf of the company. You’re employed by the EoR in your country (e.g. Italy), but you work full-time for the actual company that brought you in.

This is a great option when you want a “normal” employment contract and don’t want to deal with running your own business.

Well-known EoR providers include:

• Remote

• Deel

• OysterHR

With an EoR:

• You get a local employment contract.

• You’re enrolled in Italy’s national pension system (INPS).

• Contributions to your Fondo Pensione negoziale and TFR (severance pay) are handled.

• You receive standard employment benefits like paid vacation, sick leave, and sometimes extras like private health insurance.

In practice, it’s the same as being hired by an Italian company, but the EoR acts as the local employer, handling all the bureaucracy so your actual company doesn’t have to open a legal entity.

What About Job Security?

In Italy, whether you’re hired directly, through an EoR, or as a self-employed contractor, your job security depends more on the company’s stability and willingness to keep you than on the type of contract.

Yes, if you’re employed via an EoR, you benefit from standard employment protections like “tutele crescenti” and unemployment benefits (NASpI). As a freelancer, you don't get that safety net, but you do gain more control and flexibility, if that’s what you’re after.

TL;DR

🇮🇹 Italian remote worker
💼 Full-time role, one employer
🔁 No local entity? Two solid options:

1. Self-employed with VAT (Partita IVA) – More responsibility, more flexibility.

2. Hired via Employer of Record – Less admin, full employment protections.

Most structured companies today will support either route. Just be sure to negotiate with the full picture in mind, especially if you’re self-employed. That great monthly rate? It needs to cover more than just your time.

Already working this way? Thinking about switching? Hit reply, I’d love to hear how it’s working out for you.

So. Here we are.

It’s been 7 years since the last time I was able, and more importantly, willing, to do something tech-related outside of work (aside from tinkering with my homelab).

What have I been doing? Let’s rewind.

Seven years ago, I was streaming tweets about Christmas to a Raspberry Pi, using Spark and NLP to analyze which countries loved Christmas the most.

Why?
Because I wanted to get a better job abroad and grow in my career.

What happened?
I got the job.

Bank of America hired me in Dublin as a Data Engineer. Up until then, I was a big data jack-of-all-trades: spinning up clusters, writing jobs, choosing tech, with zero guidance. And it showed.

So I chose a big, structured company because that’s exactly what I needed.

There, I learned Agile, how to work in a big team, how to work in English, and how to properly use Scala. I went from knowing next to nothing to building a new framework that let the credit risk org spin up Spark batch jobs using just YAML.

But after a year, I was done. Bank pace is slow, and once I learned what I came for, I needed a change.

I joined Jet.com as a Senior Data Engineer. They were building a real-time streaming data platform, basically what I had started at BofA, but on steroids.

Things moved fast. Anything I merged went straight to prod. Any bug could wake up the person on call (sometimes me). At first, it made me cautious. Then I adapted.

In six months, I was designing new features, leading on-call, talking to stakeholders, and seeing my impact in real time, literally.

The war room buzz on Black Friday? Unforgettable. Some of the best engineers I’ve ever worked with, all focused on keeping everything running smoothly.

A year in, I was offered the Tech Lead role.

Then came a twist: Jet.com would be fully merged into Walmart.

I helped migrate Jet’s systems to Walmart’s stack. We moved from Nomad on Azure to a multi-cloud setup, Databricks on Azure, Dataproc on Google, Kubernetes for orchestration. I designed a system that could deploy all streaming jobs across any of those platforms with a single API call. Failover, hot/hot, you name it. Still the best work of my life.

I stayed for 3 years. I learned so much. Then Walmart decided to shut down the Dublin office, right as I was closing on a house in the suburbs to work remotely in peace.

No peace was granted.

I had to job hunt at the same time as dozens of other great engineers. I got some offers and joined Workday. I would’ve worked on massive-scale, multi-tenant Scala applications in the integrations org.

But it never clicked. Not the job, not the company. And then they announced a return to office.

Meanwhile, I’d started talking to a French startup I’d never heard of: Didomi. The role? Engineering Manager. Not the “sits-in-meetings-all-day” kind, the kind that shapes the data vision of the company, wears multiple hats, and codes when needed.

Fully remote from day one. I was sold.

At Didomi, I learned how consent management actually works. I dove into the legal requirements, designed the new system, hired the team, and got it to production. It took over a year, and it’s awesome.

In the meantime, I got married. I had a little girl.

And after 7 years in Ireland, we decided to move back to Italy. We love Ireland, but we also love watching her grow up surrounded by family. And Didomi made that move happen in days.

So… what have I been doing?

I took time to build a family, and a career.

And now I’m back to where I started, with a keyboard, an idea, and the urge to build something new.

I don’t know what exactly yet, but we’ll figure it out.

If you’re curious to follow along, whether it’s data, tech, or the messy middle, I’ll be here.