ルカ-さん Luca-san

How to influence your company even if you are an intern

Intro

I’ve been thinking about this topic for a while and finally got inspired after reading this article: https://www.seangoedecke.com/how-to-influence-politics/. I agree with much of the author's view, but it feels narrow: it's very technical and realistically doable mainly at Staff level or above.

I believe you can influence a company at any level, even as a junior or intern, though there’s a caveat that some organizations are immovable. I’ve worked at places where no change was possible and you can’t perform miracles there. But in many companies, there are simple, practical ways to make things better.

It’s not easy and it takes effort, but when it works it’s a clear way to show value, deliver results, and get promoted quickly.

Table of Contents

How to practice influence

How is by doing something engineers typically hate: documentation. Specifically, write DACIs and RFCs. It’s not revolutionary if you think about it, but most people don’t actually do it.

Example: you join as an intern and notice that there are two different tools that are scanning code in the company repository (eg. GitHub). Why have different tools that overlap and provide the same coverage, and for which the company is likely paying double for? Sometimes there’s a good reason, but often there isn’t. What happens it that someone in the position to decide thought that 2 is better than 1, like in the 2000s when people installed multiple antiviruses thinking it was better.

You might ask around to find the backstory, and when no clear answer appears, most people stop. However this is your opportunity to influence the company: write a clear DACI (or RFC when appropriate) and push for a documented decision. In this case the alternatives are: 1) keep both tools, 2) pick one, or 3) introduce a different tool.

A good proposal should:

Content must be solid, but the essential skill is writing. Many ideas stall because engineers fail to present them well - remember, delivery is often more important than the actual content. We are in the age of chatbots and if there's one thing they excel at, is to rephrase text. So exploit the s*it out of it.

Goal

The aim is to get a clear, informed decision documented. It won't always be the best, most logical one, but having a written decision with supporting information is already a win.

This matters for security teams especially. Security decisions often affect the whole company (eg. introduce a new password policy), and the team must justify choices logically. Relying on vague “security” or “risk” buzzwords damages the team’s reputation and makes future collaboration harder.

Remember, security is 10% tech and 90% diplomacy. A security team's reputation matters more than most people realize. Collaboration is already hard and it doesn't help that the work is often asynchronous where security requests things to do while offering nothing in return. Also security teams are typically small compared to the rest of the company, so they depend on other teams' cooperation. If you damage that reputation by imposing arbitrary rules, people will avoid working with you unless absolutely necessary.

DACI or RFC

The exact format matters less than documenting the decision. My usage:

In a Venn diagram, RFCs are as a subset of DACIs.

Say you want to propose overhauling the company password policy (I did this years ago at my company). The fictional current policy forces uppercase, numbers, symbols, a haiku, a hieroglyph, must not be your username, must not match the current password, must differ from the last 25 passwords, and rotate every three weeks, and you want to propose a more sane rule that drop mandatory complexity rules and forced rotation in favour of length as the primary control, aligned with NIST guidance. Length > everything else. In this case, a DACI is enough.

For replacing a VPN with a Zero Trust solution (eg. Tailscale or Cloudflare), write a full RFC and consider an executive summary DACI for managers.

DACI Template

There are many examples online; below is the template I typically use. I adjust sections as needed, stay flexible as clarity and presentation matter more than the actual structure.

Title

Summary Table

Proposer Who raised this DACI
Status Open / Closed
Impact Low / Medium / High
Date Decision date
Outcome Decision taken
Informed People/groups to notify
Approvers People/groups who must approve
Notice Yes / No (need internal announcement?)
Tickets Relevant Jira/tickets

Table of Contents

Background / Problem

Briefly explain the issue and why a decision is needed (eg. why are we using two scanners).

Pre-Decision State

Describe the current setup in detail.

Relevant Data

An optional section i sometimes use to details useful information for who review the decision.

Options Considered

This is the core: a table comparing alternatives where you advocate for your recommended option. Rows are self‑explanatory. After the DACI is closed, I usually highlight the chosen option in green to make it clear.

Keep as-is Option 1 Option 2 Option N
Description
Rollout plan
Pros and cons
Notes
Risks
Estimated cost
Estimated effort

RFC Template

Same structure as above, with explicit Goals and Non-Goals sections and expanded Background, data, and technical details.

Tips, considerations, and red flags