What is more important, your productivity or your "perceived" productivity?
Learn how you are adding value to your company and make sure that that value is visible across the board (or at least that it is not invisible)
I realize the time of the year when everyone is writing feedback (now) is not the most optimal time to ask people for feedback. However, I will still try 🙂 I have narrowed down the feedback form to a single question - “How can Top of the Tech digest be more useful for you?“. Feel free to drop the feedback either as a comment or submit it in the form below. Any feedback will be valuable for making Top of the Tech better.
This week’s reading made me think about visibility. I knew many engineers and managers who were doing super impactful work, but their work was not super visible. On the other hand, there were also the ones whose real impact was low, but they invested a lot in visibility, thus increasing (sometimes unrealistically) their real impact. Both are edge cases you want to avoid. The below article does not talk exclusively about this topic, but it does touch on it very clearly.
So, if you or your team are doing amazing work for your company, park a bit and take time to think about how to surface this impact and make it visible.
Read on! 👓
Your business value (12 min)
uses a simple productivity/time chart to explain how you bring value to your company (or not). He gives you a clear explanation of why the perception of your productivity is what shapes the idea of your productivity in other people’s minds. So all you Ninja 🥷🧑💻 engineers shipping tons of value with only a few people noticing - stop for a moment. Read Alex’s advice and make your work visible.
I am curious your thoughts on the “real” vs “perceived” productivity in your org, let me know your thoughts in the comments 💬.
Audience: All professionals
Value: Learn about the value you bring to your company
ToT Rating: ⭐⭐🌟
How LinkedIn Scaled User Restriction System to 5 Million Queries Per Second (10 min)
This is LinkedIn’s storage and caching story. It shows the evolution of LinkedIn’s system for abuse detection. They started with a simple Oracle database, then cached it multiple times, switched to No-SQL storage, and further optimized it.
The article talks about the CAP theorem, and one sentence threw me off - “LinkedIn prioritized consistency (C) and availability (A) over partition tolerance (P).” 🤔. CAP theorem states that when there is a network partition, one has to choose between availability and consistency. CAP analysis is of not much use unless there is a network partition. I can only assume they chose a single-node storage. However, the graph contains multiple Espresso tables. There is also a follow-up sentence, “Integration with Kafka ensured that restriction records were synchronized across servers in real-time…” which, if those “servers” are storage servers, indicates a network partition.
Anyhow, a bit confused by the CAP mention there, but it's still a nice storage evolution story. Drop a comment if you spot how I misunderstood this 💬.
Audience: Software Engineers
Value: Learn about the evolution of one of LinkedIn’s storage systems
ToT Rating: ⭐⭐
No, I don't want to hop on a call (8 min)
Have you ever had a situation where you asked something on Slack and got dragged into a call where the person assembled the answer to your question with you as the rubber duck and realized they could have simply done that thinking themselves and written that damn answer on Slack? Or you were the guy that asked for the call 😬.
Audience: Engineering Managers
Value: Learn how to collaborate better
ToT Rating: ⭐⭐
The Evolution of SRE at Google (17 min)
Tim Falzone, Ben Treynor Sloss
The SRE movement that originated at Google has brought us many techniques that help us build and run reliable systems. SLOs, error budgets, postmortems, rolling deployments, and other techniques are a normal part of our day-to-day operations today. These techniques allow us to guarantee certain levels of service to our customers. While we are doing our on-call duty and waking up at night to respond to incidents, guys at Google are going one step beyond - they are looking for ways to enable operating under zero error budget (meaning no outages at all 🤯). They are applying learnings from systems theory and control theory to bring more reliability to their systems.
Audience: Software Engineers / SREs
Value: Learn about the (potential) future of SRE
ToT Rating: ⭐
Waterfalls, sunk costs, and talent density (5 min)
‘s shares ‘s view on the Waterfall vs Agile debate. Kent sees this as a power debate - Waterfall gives power to top-down decision-makers while Agile gives power to the builders. This idea got lost somewhere between all those Scrum guides and LeSS frameworks, and we ended up with an “Agilefall” 😔 (fall of Agile? 🤔). Then Luca segways into the “sunk cost fallacy” bias, which you need to be aware of if you want to be agile. Finally, he shares one example where top builders, their talents, and high performance are valued - Netflix.
Do you feel you are operating in a Waterfall despite working in sprints? Let me know in the comments 💬.
Audience: Software Engineers
Value: Learn how Waterfall is sneaking up on us
ToT Rating: ⭐
6 secrets for never being blocked again (8 min)
If your organization has a problem with engineers being stuck often on waiting for DevOps/SRE this article is for you.
shares 6 tips for improving how you work with your Ops partners.Audience: Software Engineers
Value: Learn tricks to not be blocked by DevOps/SRE engineers
ToT Rating: ⭐
Observability: the present and future, with Charity Majors (9 min read, 1h 14 min podcast)
In this podcast episode
dives into everything you want to know about observability. She covers what is observability (“three pillars” model), hardships and mistakes with observability, what is observability 2.0, OTEL and many other topics.Audience: Software Engineers / SREs
Value: Learn about the state of Observability
ToT Rating: ⭐
That’s it! ✅
Now start doing those demos, mentoring, skip 1-on-1s and the rest! 😎