Is your "bragging" hurting you?
If you need to brag, learn how to do that effectively, learn about staff role, managing your time and managing accross time
When 2024 was closing out, I set the following goals for myself.
In 2025 my goals are to:
keep the writing cadence of publishing a digest at least once a week,
publish some of my original content,
do at least one guest post on other newsletters and
grow my audience to 1K+ subscribers.
I thought it might be good to reflect on those. Here is the status so far.
Cadence at least once a week ✅ (had a two-week break but managed to get back on track; will make a break soon though)
Original content ✅ (published my first author post on ToT on AI impact on software development)
Guest post 🚧 (attempted, but did not manage to follow through, will attempt again)
Audience 🚧 (only 12% of the target, with almost half a year passed 😓)
People judge the average of your achievements, not the cumulative (3 min)
This is a great 3-minute advice on framing your achievements. It is counterintuitive, but listing more achievements can reduce their value as perceived by your audience. This is because people perceive the value as an average of the input you give them, not as an accumulation.
So next time you are bragging, try mentioning your top achievements only, instead of building a huge, comprehensive list. I feel this can be useful for performance reviews, who knows, even pros/cons analysis 🤔
Audience: All professionals
Value: Learn how to frame your achievements better.
ToT Rating: ⭐⭐
Staff archetypes are anti-patterns (10 min)
When an engineer operates within a single team, roles are quite simple to define. Engineers with lower skillsets and experience are juniors, then as you gain more of those, you become a medior, and finally a senior engineer. However, when it comes to staff+ roles, things start to become a bit fuzzy.
shared recently an introduction to the staff role. This created a clear picture of what should be the responsibilities of this role. Out there in the wild, however, there are many deviations from this, and there are roles called “staff” without real staff responsibilities in them. Alex shares how even some well-known archetypes alone are not enough to justify a well-rounded staff role.
Audience: Software Engineers / Staff Engineers / Engineering Managers
Value: Learn the pitfalls of the staff engineer role
ToT Rating: ⭐⭐
The time zones of Engineering Managers (6 min)
This article describes several mindsets that engineering managers (and people in general) can have concerning time. You might always be stuck in the past, overanalyzing past decisions. Or you live very much in the moment and are a great executor focused on what matters today. Or you are focused on the vision, the future, and what will be in the years to come.
Audience: Engineering Managers
Value: Learn which type of EM you are
ToT Rating: ⭐⭐
This engineer tracked his time for more than a year and this is what he learned (7 min)
In this article
shares how tracking every minute of his work time for the last two years in 15-minute labeled chunks helped him to be much more productive. This might get you inspired to better track and manage how you are spending your time, which is your most valuable asset. I personally never tried tracking my time, and I have a personal aversion to it (as Luca mentions, some people might).I like the technique of picking the top three most important things you can do every day and focusing your attention/energy on those. However, I might still try tracking/categorizing time.
Audience: Software Engineers
Value: Learn about time management
ToT Rating: ⭐
What helped me level up in Big Tech (that no one talks about) (5 min)
A very brief and clear overview of different engineering levels.
shares what each engineering level operates with and what are the main focus points for it. If you are somewhere between junior and staff engineer, these distinction will be useful for you.Audience: Software Engineers
Value: Learn about the software engineer level distinctions
ToT Rating: ⭐
Heroic culture is anti-engineering (2 min)
I often skip Luca’s Monday ideas as they are mostly brief notes and not fully developed articles. However, this one I really liked, as it plays with the survivorship bias and talks about how organizations often end up rewarding engineers that put out fires and do duct-taping as opposed to engineers that prevent problems in the first place. This happens mostly because fires are more visible than really good, boring engineering work.
Audience: Software Engineers / Engineering Managers
Value: Learn about firefighter anti-pattern
ToT Rating: ⭐
That’s all, everyone! 🙌
See you soon!
It’s good content, so don’t worry about your audience goal. I’m sure you’ll hit it