DevEx & Dev Tools; Quiet Devs; Quitting Big Tech; Deployment Strategies
DevEx & Dev Tools; Quiet Devs; Quitting Big Tech; Deployment Strategies
Issue #26 Bytes
🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
🎙️Ex-Director of Engineering at Walmart- Vilas on Dev tools & DevEx
What makes or breaks DevEx in your team? -It’s not just about Dev tools. It’s about partnerships and influence!
Check out the latest episode of the groCTO podcast as we talk with Vilas Veeraraghavan, a Startup Advisor with a wealth of tech leadership experience at companies like Walmart, Netflix, and Bill.com. Learn how early collaboration with key influencers can unlock rapid innovation and inspire cross-team adoption for better DevEx. Here is a quick trailer of the podcast for you👇
What strategies have worked for you? -Let us know!
Article of the Week ⭐
"If you take shortcuts, it will become worse long-term."
Why Are My Devs Always So Quiet?
Adrian Stanek shares his decades-long perspective of leading tech teams. He presents a case of using silence in meetings and collaborations as a lagging indicator of lack of engagement.
Engagement that was subsumed by fear of judgment due to micromanagement, absolutist crisis resolutions and not gathering feedback when met with unreasonable expectations.
Adrian files all of these dysfunctions into the bucket of failure by leadership to create the proper environment with psychological safety where risk-taking and bringing relevant issues to the table are rewarded instead of punished.
Developers are quiet not because they don’t have opinions, but because they operate in environments that discourage dialogue. A major driver is fear of impossible deadlines and the perception that their feedback will not—or must not— change business decisions.
Wake-Up Call
The turning point for his teams was the realisation that pressures applied by leadership and stakeholders that resulted in a drop of quality created counter-productive behaviors and drop of morale that lingered for years to come.
As he started having conversations with his team members regarding what’s possible and their preference rather than meetings with strict expectations the team started to reciprocate in a series of smaller moments where feedback to the leaders from the team finally reached its way to source.
Dev Team Engagement Checklist
Create a Safe Environment for Honest Conversations
Bridge the Gap Between Business and Tech
Advocate for Your Team
Shift from Managing to Leading
Encourage Ownership Through Trust
Don’t wait for someone to breach the silence. Be a proactive leader.
Other highlights 👇
Why Techies Leave Big Tech?
In a generous free deep dive, Gergely from The Pragmatic Engineer shares his insights on late-2024 trends emerging from the Big Tech companies in the US and Europe.
He summarised his findings into seven distinct categories—and as you know, we love lists and data.
Big Tech less stable than it was. Software giants were one of the biggest sources of layoffs for the past years post-COVID. Coupled with a bearish trend in the market, many larger IPOd corporations lost their extravagant compensation packages.
Professional growth in a startup environment. Engineers are curious and growth-oriented by nature. CV-driven development exists for a reason. Fashion-trends are strong in our industry and it’s hard to try on something new in a corporation that’s crunching during layoffs.
Closed career paths at Big Tech. Startup CTOs and equivalent are becoming the new norm strategic engineers, along with the new market for Staff engineers in scaleups.
Forced out. Some of the techies Gergely interviewed shared their experiences of political rivalry in large corporations that resulted in less than ideal career shifts.
Scale-ups get too Big Tech. The “move fast and
breakship things” mentality carried over from startups is a prime motivator at scale ups that diminish over time as the company reaches maturity, possibly eyeing an exit or IPO.Steep compensation drops. IPO’d big tech firms live on stocks as part of their compensation package, which makes it difficult to retain talent during a market crash as the vesting periods create a mix of pressure and low reward.
Raw feedback. The upper tiers of the tech market are becoming riskier, which removes plenty of the golden handcuffs from the big tech firms and creates equal opportunity to compensate fairly for smaller organizations.
Common Deployment Strategies
Architecture depends very closely on your business strategy. Among them the nuances and intricacies of your release pipeline. Maciej brings his experience as an architect on how different deployment strategies combine different trade offs for different purposes in product engineering.
Big Bang Deployment
The good ol’ turn it off and on again. Comes with downtime but it is by far the simplest and most primitive form of deployment. Best for non-critical applications and freshly formed teams that need immediate feedback.
Blue-Green Deployment
The colors don’t matter per se. Blue-Green is a toggled environment where multiple (usually two) stable versions exist side by side on production. You roll traffic to the one that presents the lowest risk and fix or make improvements the other one.
Hugh uptick on stability and uptime compared to Big Bang, but also comes with a hefty chunk of complexity.
Canary Deployment
Difficult to setup but one of the hallmark variations for continuous delivery. Canary is the pragmatic mix of Big Bang and Blue-Green. Rather than turn off production to deploy or having a full second replica, you simply setup a new node for the affected systems and give it a small trickle of traffic.
The purpose of the traffic is to validate whether it represents risk in deploying to the main node. If the initial canary test looks good, increase the traffic it handles until you can turn off the old node.
The benefit compared to blue-green is that you can run this per application slice or microservice without needing a replica of the entire production network, though it does require more finesse and control on your ingres and load balancers.
Rolling Deployment
The best of both worlds between Canary and Blue-Green. Rather than controlling amount of traffic, all services that require strict uptime are handled via round-robin splits in traffic, creating equally pressured nodes. A canary node is added during deployment and if it is successful, the older nodes are gradually updated one by one.
This creates a seamless, smooth experience in regards to transitioning to production and managing risk, but it does slow down the rollout time. The production environments spend much more time running two or even more versions on live data, creating challenges in communication and schemas.
This approach gives the most fine-grained control on deployment resource spend.
Mix and match for your teams as needed. This was from article #30 from his newsletter accompanying his newest book. Check out his blog for more.
Find Yourself 🌻
That’s it for Today!
Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week(end), Ciao 👋
Credits 🙏
Curators - Diligently curated by our community members Denis & Kovid
Featured Authors -
, , Maciej Jedrzejewski “”Sponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.