How do you get an engineering team to be heard?

Short answer

Visibility is a system, not a talent. Pick a small group who have something to say, give each of them one real deadline — a submitted CFP or a published piece — and make the work public by default. Most engineering organizations are invisible because nobody owns the function, not because nobody has anything worth saying.

Why "we should do more content" always fails

Every engineering org has had this conversation. Someone senior notes that the team does remarkable work nobody hears about. Everyone agrees. A Slack channel is created. Two people post. Nothing happens, and the conclusion drawn is that engineers don't like writing.

That conclusion is wrong. The reason it fails is that visibility was made everyone's job, which means it was nobody's, and it was framed as an extra rather than as work. Nobody has a deadline, nobody is accountable, and it competes with shipping.

Run it as a cohort, with real deadlines

The version that works looks like a program, not an initiative. A small group — six to ten people — who each commit to producing one specific artefact by a specific date.

Not "write more". A submitted conference CFP, with a real deadline set by someone other than you. One published piece. A talk given internally before it is given externally. The external deadline is the mechanism: it converts a good intention into a commitment that has a date attached.

The second thing that matters is making the work public by default rather than by exception. Design docs, incident reviews and architecture decisions are already written. Most of the cost of publishing has already been paid; what is missing is a decision about the default.

What is actually worth publishing

The instinct is to publish successes. Successes are the least interesting thing an engineering org produces, because every company's success story sounds the same.

What travels is the decision you got wrong and corrected, the constraint nobody outside your company would guess at, and the number. Specificity is the whole game. "We improved reliability" reaches nobody. "We cut incidents 40% in three months by changing how we organise testing and monitoring" gets forwarded.

How to tell whether it is working

Not by impressions. The signals that matter to an engineering organization are: are candidates arriving warm and already knowing what you work on, are senior people staying because they have a platform, and are partners approaching you rather than the reverse.

Those are slow signals, and they compound. The leading indicator that predicts them is much simpler: how many people on the team have something submitted or published this quarter.

Where this comes from

As Site Lead at Stripe Romania I am accountable for the growth, culture and brand of the site. The cultural infrastructure includes engineering guilds, a mentoring program and public speaking cohorts, and it produced 50+ community events reaching more than 20,000 people. Earlier, at Adobe, I built a company Branding Program and ran a mentoring program reaching roughly 180 pairs.

Questions people ask

Isn't this just marketing?

No, and treating it as marketing is why it usually fails. Marketing owns the company's message. This is about individual engineers building their own signal, which is why it has to be run by someone engineers respect technically. The employer-brand benefit is a consequence, not the framing.

What if our engineers genuinely do not want to speak publicly?

Some won't, and that is fine — this works with a self-selected group, not a mandate. In practice the constraint is rarely willingness. It is that nobody has ever told them their work is interesting to anyone outside the building, or shown them the mechanics of a CFP.

How long before it shows up in recruiting?

Two to three quarters before it affects candidate quality in a way you can feel, longer before it shows in cost per hire. The internal effects — people articulating their own impact better — arrive within weeks and are worth it on their own.

Can we not just hire a developer relations person?

You can, and for some companies that is right. It solves a different problem: DevRel usually carries the company's message outward. It does not, by itself, make your existing senior engineers visible under their own names, which is the thing that affects retention.

Off Localhost

This is the program I run for engineering organizations

See how that works