Alfonso Graziano

Speak Up in Standups and meetings Write It Down: The Power of Good Documentation & Updates Show and Tell: Demos, Internal Talks, and Sharing Wins Being a Multiplier: Helping Others Helps You How to earn your manager’s trust (and keep it)

Speak Up in Standups and meetings

most of us have sat through standups like they were dentist appointments. Quick, routine, and something you just want to survive without saying much (even worse when you woke up and you need a coffee, when your brain is still buffering). But if you're trying to grow your influence at work, those 15-minute check-ins and Zoom calls are golden opportunities. Seriously.

You might think, “I’m doing great work — people will notice.”

Spoiler: they won’t. Everyone’s busy. Even your manager is probably juggling 37 things at once, and half their brain is still stuck in the last meeting. If you don’t speak up, your work risks becoming invisible.

Being visible doesn’t mean bragging. It means letting your team know what you’re working on, what’s blocked (and what you’re doing about it), what you’re learning and how it connects to the bigger picture.

When people know what you're doing and why it matters, they’re more likely to trust you, include you, and trust you for important work. That’s how influence starts.

You don’t need to become a TED speaker overnight. Be clear, consistent, and a little bit human. Try something like:

“Yesterday I worked on the payment bug that was causing issues for customer X. I figured out it was a race condition in the API call, and I’m testing the fix today. If anyone’s curious, happy to walk you through it later.”

Boom — short, helpful, and opens a door for collaboration. No need for drama.

What if you're shy or not a native speaker?

Welcome to the club! I remember my first meetings as an employee in an international company, my English was terrible (I even cried from desperation after my first day, but this is another story).

Here’s the trick: prepare 1–2 sentences before the meeting. Write them down with bullet points. It removes the pressure of improvising, especially if English isn’t your first language.

You could also mention impact:

“This should help reduce support tickets related to payment failures, which are about 20% of our incoming requests.”

That’s the kind of thing that gets remembered.

Meetings aren’t just for updates, they’re chances to build trust and show leadership. Ask thoughtful questions. Offer to help. Reflect on trade-offs. These things make you stand out more than a fancy title ever could.

For example:

“Hey, I noticed we’re choosing X over Y. Are we doing that because of time constraints or something else?”

Curious, calm, and collaborative. That’s leadership material right there.

What about other meetings?

Standups are just one piece of the puzzle. Let’s talk about other common meeting types and how to make your presence felt without becoming “that person” who always talks but never says anything useful.

Planning meetings are a great chance to show that you care about more than just code — you care about the why. Ask about goals. Raise concerns early. Offer ideas.

“I think this solution works, but it might create some tech debt. Should we timebox this or revisit it in a retro?”

Even a simple “is this aligned with our quarterly goals?” can make you sound like a strategic genius (even if you just skimmed the goals doc that morning).

Retros aren’t therapy, but they are a place to raise issues in a calm, respectful way. Skip the blame, focus on improvements.

Good:

“I felt a bit rushed during the last sprint, especially with the late changes. Could we plan some buffer time next round?”

Less good:

“Everything was terrible and I hated it.”

Also: don’t just point out problems — suggest fixes.

1:1 with your manager shouldn’t be a status update. Use them to:

Share what you’re proud of

Ask for feedback

Mention what you want to learn or improve

Check in on how your work is being perceived

Example:

“I’ve been focusing on reliability lately. Is that coming through in how the team sees my work?”

Managers love this. It shows you care and that you're thinking like a grown-up.

Meetings are shared spaces. The goal isn’t to fill airtime — it’s to move things forward. Keep your points clear. Don’t ramble. Avoid solving problems live unless asked. And always be the person who listens and contributes.

People remember clarity. People trust consistency. And the more visible and helpful you are in meetings, the more likely they’ll think of you when opportunities come up.

Write It Down: The Power of Good Documentation & Updates

You know what’s better than being the loudest voice in the meeting? Being the person who writes things down so no one has to guess what happened later. Funny enough: now you can use AI to do that - which works actually well. But taking notes “by hand” sometimes is super helpful.

Writing is one of the most underrated ways to build trust and influence at work. It’s quiet, it’s thoughtful, and — best of all — it sticks.

Documentation isn’t just for future-you who forgot how that script works. It’s also for teammates who join next week, for managers who want clarity without pinging you, and for people in other departments trying to understand what’s going on.

Good written communication shows you’re organized, thoughtful, and reliable. Those are grown-up traits. People notice.

At some point your manager will come up with “hey, how is going feature X?” or “can you send me an updated architecture diagram? I got a client meeting in 30mins and he wants so see some”. Trust me, documentation can make you look great (if you do your homework).

Also, written words scale. You say something in a meeting? Ten people hear it.

You write a solid update or doc? It can help a hundred — even months later.

You don’t need to produce a thesis (even because people will not read long content). Aim for short, clear, and useful. Some examples:

Daily or weekly status updates in your team Slack channel

Clear pull request descriptions

Project updates in Notion, Confluence, or whatever flavor of wiki your team uses

Short guides for “how this works” or “how to run this locally”

Retrospective notes or action items

Tech decision records (aka “Why the heck did we choose this approach?”)

It doesn’t need to be pretty. It needs to help others (and future-you).

A good update is like a good standup: short, informative, and goes to the point.

Try a format like:

What’s done

Finished integration with payments

Fixed edge case causing duplicate invoices

What’s next

Writing tests for new billing flow

Coordinating with ops to roll out safely

Any risks or help needed?

Need feedback on error handling logic — tagged folks in PR

Boom. Clear, no guessing, no detective work needed.

Bonus: these updates make you look on top of things, because you are.

If your team opens a file, sees your name, and thinks “Nice, I know this will be well explained” — you’re winning. You’re building trust without even being in the room.

And when decisions come up? People naturally loop you in because they trust you to document, clarify, and not drop the ball.

Nice documentation and written communication takes some time, but the ROI (Return on Investment) in terms of trust, clarity, and long-term time saved is massive. People stop asking the same questions. Onboarding gets easier. Decisions have context. And when things break (as they always do), your past self becomes the team’s unexpected hero.

In my experience as an occasional writer, I learned a few important lessons I quickly want to share with you:

Use templates: If you find yourself writing similar updates or docs, create a simple template. A “What, Why, and Next Steps” structure works for most things.

Write for the right audience: If it’s for engineers, include technical details. If it’s for managers, focus on impact. Adjust your depth accordingly. There is nothing worse than a great presentation done to the wrong audience.

Keep it skimmable: Bullet points, bold key phrases, and short paragraphs help people absorb info faster. No one wants a wall of text.

Don’t overthink it: Start with a rough outline and refine as needed. Something written and slightly imperfect is still 10x better than nothing. Bonus point: You can use LLMs to review (as I’m doing now) the content to make it more readable and even spot things that can be clarified better

Use the right tool for the job: Long-term documentation? Wiki or Notion. Quick status updates? Slack. Tech decisions? A shared doc or repo. Choosing the right medium keeps things from getting lost.

Make it a habit: Add a 5-minute “write it down” slot to your daily routine. Consistency makes it second nature. Here is my favorite setup: a cup of tea, lofi music, disabled all the notifications an 10 minutes of pure focus to write everything down.

Show and Tell: Demos, Internal Talks, and Sharing Wins

Doing great work is important. But making sure people see it? That’s how you build influence.

This chapter is all about making your work visible through demos, internal talks, and sharing wins in ways that feel natural, without sounding like you're trying to impress anyone. Think of it like show-and-tell from school, but instead of a weird rock or your pet hamster, you're showing off thoughtful work that solves real problems.

You could be shipping bug-free features, saving the company money, or building elegant systems—but if no one sees it, it quietly fades into the background. I’ve seen many brilliant engineers quietly do amazing work, but they stay in the shadows. In this case, being like Batman is not a superpower, it’s a missed opportunity.

Sharing your work builds credibility. It helps others learn from your process. And it signals, "I'm someone who contributes, and I care.”

It also invites feedback, encourages collaboration, and helps newer or quieter teammates learn by example. A little transparency goes a long way.

You don’t need to wait for a big launch to talk about your work. Some ideas:

A small feature you just shipped

A performance improvement you implemented

An internal tool or script you created to save time

A tough bug you fixed (and what you learned from it)

A decision you made and the trade-offs you considered

These might seem small, but they help paint a picture of what you're contributing and how you think.

Just to give you a small example, on a project I managed to build an end-to-end type-safety by auto-generating a JSONSchema used for API validation, the Swagger Docs and a type-safe client by hacking together a few libraries. It wasn’t that complex, but it was useful for our project over multiple teams, so I just shown them what I did in a 10 minutes Zoom call. Nothing fancy, but this (like other micro show-and-tell) helped our team to proceed faster.

Demos are your best friend. You don’t need slides. You don’t need polish. You only need to show what you did, what problem it solved, and how it helps the team or users.

A good demo format looks like this:

Context: What was the problem?

Solution: What did you build or fix?

Impact: Why does this matter?

What’s next: Is this ready to ship? Need feedback? Anything left to improve?

Pro tip: keep it short and honest. It’s okay to say, "This part is still rough," or "This could be cleaner, but it works for now." That kind of realism makes your demo more relatable.

Internal talks are great for zooming out and sharing deeper learnings. These can be short (15–20 minutes) and work well in lunch-and-learn formats or engineering syncs.

You could talk about:

How you solved a tricky problem

Lessons from a recent project

A new tool or framework you explored

A decision you regret (yep, people love these)

Patterns you’ve spotted that others should know about

Don’t worry about being formal. Use plain language, a few visuals or code snippets, and speak like you're talking to a teammate—because you are.

Again, a personal example works better than 1000 words. I was working on setting up a new auth layer for my project. My team did an amazing job and we introduced a couple of cool custom feature. The feature were far from perfection (they still are), but were good enough to work in our context. Then we did a demo of the project to an internal community. No slides, no fancy presentations, just geeks talking to geeks.

Sometimes the best move is simply sharing a win. Maybe you closed a long-standing ticket. Maybe a client complimented your work. Maybe a test you added caught a nasty edge case. Share it!

Drop a message in Slack or your team’s async update channel:

"Shipped the new error handler today. Should reduce false alarms in our alerts by ~30%. Thanks to @Jo for pairing on the edge cases."

Or during a meeting:

"Quick shoutout to the team—the new deployment process shaved 8 minutes off every build. That adds up fast."

It’s not about stealing the spotlight. It’s about keeping the spotlight moving so people see what’s working.

There are some best practices that might help quite a bit while sharing wins:

Be specific. "Improved performance" is vague. "Reduced API response times from 800ms to 250ms" is clear.

Be honest. You don’t need perfection. Sharing the messy middle builds trust.

Give credit. If someone helped, mention them. Visibility is better when it’s shared. Just say “thanks” publicly. Giving credit is part of working in a context where you’re psychologically safe.

Keep it short. Nobody wants a TED Talk in the middle of standup.

Make it a habit. Add "Share one win" to your weekly checklist. It’ll get easier every time.

The more you show and tell, the more people associate you with impact. You become the person who solves things, shares learnings, and raises the bar.

It helps your career, sure. But it also builds a culture of openness, learning, and mutual respect.

And hey, if you do happen to bring your pet hamster to a Zoom demo… no one will forget it. (I sometimes bring a Yorkshire which is SO CUTE)

Being a Multiplier: Helping Others Helps You

If you want to be seen as a leader (even without the fancy title or extra calendar invites), start by making the people around you better. That’s what multipliers do. They don’t just focus on their own output—they create more output through others.

Being a multiplier doesn’t require a promotion, a manager badge, or some sacred Slack emoji. It just means being the kind of person who makes their team stronger, clearer, calmer, and occasionally funnier.

“Why bother helping? Isn’t that extra work?”

Sure, helping others takes effort. But it pays off in all the right ways: you build trust, you eran a reputation for being solid and reliable and, most importantly, people want to work with you.

It’s like compound interest for your career. A few helpful moments here and there? Suddenly you’re that person everyone turns to when something big needs to get done—or when something small turns into chaos.

Also, let’s be real: nobody remembers who wrote the most code. They remember who made their lives easier.

You don’t need to be someone’s manager to make a difference. You just need to show up in small, consistent ways that help the team move faster or feel more supported:

Answer a question in Slack that everyone else ignored (and yes, even the obvious ones)

Share a script or alias that saved you 10 minutes of pain

Pair with someone stuck in dependency hell

Review code kindly, and maybe even leave a compliment (!)

Say "great work" when someone quietly ships something important

These aren’t grand gestures. They’re the little acts that slowly shape how a team feels and functions.

Being a multiplier isn’t about correcting everyone or jumping in uninvited. It’s about spotting moments where your experience or energy can make things easier, faster, or clearer. When you try to be a multiplier, you might end up micromanaging people - and trust me, that is horrible. I know, sometimes its a subtle line, but you don’t want to cross that line.

Sometimes that means unblocking someone. Sometimes it means just listening. And yes, sometimes it means holding back so others can figure things out on their own. That’s leadership too.

Keep an eye out for these signals:

New teammate looking lost? Send them a short message like, "Hey, let me know if you want a quick walkthrough of how we do things. No pressure."

Messy part of the codebase? Write a comment, drop a note, or just say, "Heads up: this file bites. Happy to pair if needed."

Someone stuck in meetings all day? Offer to pick up something small for them.

See a quiet win? Shout it out in Slack or in the retro. Amplify others.

You don’t need permission to be useful. You just need empathy and a bit of initiative.

Also, if you see a teammate struggling, even a simple private message like “Hey, can I support you somehow with XYZ? If there is something I can do let me know, happy to chat” might unstuck a colleague and create an opportunity for you to help.

Helping doesn’t mean becoming the team therapist or the human rubber duck. If you say yes to everything, your own work, and your energy, will suffer.

Pick your moments. If you’re tight on time, help by pointing people to a resource, tagging someone else, or just letting them know you’ll follow up later. That still counts.

Remember: sustainable help is better than heroic help.

Something weird happens when you help people: they start helping back. Not just you—others too. One generous teammate can change the vibe of a whole group.

That doesn’t mean creating a "good vibes only" team of high-fives and motivational posters. It just means making things a little more human. A little more supportive. A little more "we got this."

Also, it makes work… kind of nicer? Imagine that.

How to earn your manager’s trust (and keep it)

Let’s clear the air: this isn’t about sucking up. No one likes the person who agrees with everything, laughs too hard at every joke, and magically loves every idea their manager has.

Building trust with your manager is about creating a healthy working relationship. One where they know you’ve got things under control, they can rely on you, and you’re not just waiting for them to assign every little task.

It’s not about politics. It’s about clarity, consistency, and communication.

Your manager is juggling a lot. They’re responsible for team delivery, people’s growth, cross-team alignment, surprise fires, meetings about meetings... you get the idea.

If you’re someone they don’t have to worry about? That’s huge.

When your manager trusts you, a few things happen:

You get more autonomy

You’re more likely to be considered for growth opportunities

You get clearer feedback

Your work gets more visibility

Basically, it makes your job easier and more impactful.

Trust isn’t magic. It comes from repeatable, visible behaviors. Here are some that work:

Do what you say you’ll do (and let them know when you can’t and why)

Communicate early and clearly, especially when things go off-track

Give context in updates, not just "done/not done"

Take ownership of tasks and follow through

Ask for feedback and act on it

You don’t need to be perfect. You just need to show that you care, that you’re aware, and that you’re actively trying to get better.

One of the best things you can do is help your manager do their job.

That means:

Keeping them informed without making them dig

Sharing risks before they become surprises

Being proactive in solving problems

Supporting your teammates

If they spend less time checking on you and more time focusing on the big stuff, that’s a win. You become someone who brings clarity, not confusion.

"Managing up" isn’t manipulation. It just means you understand how your manager works, and you tailor your communication accordingly.

Do they like short bullet points? Give them bullet points. Do they care about impact? Lead with business value. Do they love slides? Okay, that one’s harder, but hey—one slide never killed anyone.

The book The Manager’s Path has a great section on this called "How to be managed". Highly recommended. It’ll help you understand what your manager needs from you—and also what you should expect from them. Think of it like getting a cheat sheet for a better working relationship.

Your manager shouldn’t have to wonder what you’re working on, whether you’re blocked, or if everything’s on fire and you’re just too quiet to say it.

Be open. Be proactive. Share progress, concerns, and wins.

If you make their life easier and help them look good to their boss? Trust me, they’ll remember that.

Share also when you do a mistake. I know, this is hard. It makes you vulnerable. It makes you look bad and on the spot. On the long run, sharing your mistakes will help to build a sense of trust with your manager. They will never think that you’re hiding informations. You always need to be transparent. Again, it’s hard, but it’s worth it.

Trust isn’t built overnight, but it compounds quickly.

If your manager knows you’re reliable, communicative, and thoughtful—you’ll stand out. Not because you’re loud, but because you’re solid.

And no, you don’t have to laugh at their jokes. But if they are funny? Well, a little laugh doesn’t hurt.

Being Visible, Valued, and Trusted at Work

Speak Up in Standups and meetings

Write It Down: The Power of Good Documentation & Updates

Show and Tell: Demos, Internal Talks, and Sharing Wins

Being a Multiplier: Helping Others Helps You

How to earn your manager’s trust (and keep it)