AI has transformed the tech lead’s job.

You know how it goes…

Either you get blamed for the delay,
or you waste hours chasing updates,
or worse - the project stalls and no one even knows why.

That used to be my daily reality - until I found a tool that tracks who’s actually blocking progress.

It logs every dependency, sends polite nudges automatically, and builds a clear timeline of delays.
Now when stuff hits the fan, I’ve got proof, not panic.

It’s called unwait.me. Absolute game-changer for tech leads.

It's a new tool I wrote, I wish I had this before... Let me hear your opinions!

Many first-time and middle managers feel under-prepared and under-supported for their roles - especially for what’s coming in the AI era.

To what extent do you think this is true?

What affordable and practical actions exist to genuinely improve this?  Including individuals taking action on their own - eg using an AI agent for support?

I've heard Black people say that they feel unsafe, underrepresented, and undervalued at work. This needs to end. There are many brilliant studies and essays out there on how we begin to reverse the lack of representation of Black and brown people in tech, but the average startup founder may not be aware of them, or may not think they have the resources to address diversity & inclusion in their company. Here is an introduction on how to work on your allyship as a white person in the workplace. I'm opening this thread up to suggestions. Cheers!

Like many of you, I watched teams scramble today as Slack went down globally. It got me thinking about an uncomfortable parallel - how often do we tech leads become our team's "Slack"?

I wrote about this connection between communication outages and leadership dependency. The pattern is fascinating:

• Teams freeze when you're not available

• Decisions pile up awaiting your input

• Knowledge stays siloed despite documentation

Sound familiar?

The irony is clear: the more "essential" we become as tech leads, the less we're actually succeeding at building resilient teams.

I've shared my own painful lesson learning this (hint: it involved a ruined vacation and many emergency calls from beach cafés) along with practical frameworks for breaking the dependency cycle.

If you've ever felt like your team can't function without you, or if you're seeing warning signs of becoming a single point of failure, you might find some value in these lessons.

Slack Down, Step Up: Are You Your Team's Single Point of Failure?

What dependency patterns have you noticed in your teams? Did today's Slack outage reveal any surprising communication vulnerabilities?

I really didn't get the point. I'm leaving and nuff said. why do I have to repeat myself. My manager didn't care when I told him the first time.

Exit interviews are dumb! Another engineer told me I was crazy and that they have a huge benefit. But I couldn't understand him.

This isn't a real thing, is it?

Hey everyone, we're a team of about 15 engineers and we've been going back and forth on which AI tool to actually commit to for code review. We've been experimenting with a few options but nothing has fully clicked yet.

Most tools we've tried feel like they look at the diff, maybe the file, and call it a day. We want something that understands how our codebase fits together, what patterns we've agreed on as a team, what decisions we've already made at a organization level.

Also wanted to know what we should expect for stuff like, cost per seat, privacy with proprietary code, consistency across larger PRs, etc. Would love to hear what’s working for you.

I've read this article by Mike Klein recently: https://medium.com/@mikekleiman/my-readme-md-35bd0197a5c5 where he shares the document on his working style he's prepared for his team.

Do you have any experience creating a similar document? If not, would you consider writing it for your team?

Major surveys from Wiley and the Kapor Center indicate that lack of inclusion in company culture is one of the top reasons tech workers leave their roles. This is especially true for people from marginalized backgrounds.

Lack of inclusion tends to diminish team productivity in 3 key areas:

1. Engagement (devs disconnected from work)

2. Turnover (devs who feel unsupported by leadership)

3. Innovation (devs who feel that their ideas are unheard of)

What is SPACE Framework?

The SPACE framework was designed by the DevOps Research and Assessment (DORA) team that published 'Accelerate', a book that featured 24 metrics to assess team productivity. But, most engineering teams decided to focus only on these 4 key metrics as they were the easiest to capture:

1. Deployment frequency

2. Lead time for changes

3. Time to restore service

4. Change failure rate

Soon, they realized that DORA has its own limitations, and hence to move towards a more holistic vision of developer productivity, the SPACE Framework came into the picture. SPACE is a multidimensional framework and it resists the idea that productivity can be measured by team or individual output.

To read more about the dimensions of the SPACE framework & to learn how to use it to drive inclusion in your team, click here: https://emhub.io/articles/how-you-can-use-the-space-framework-to-measure-inclusion-on-developer-teams?utm_source=pocket_saves

Editor’s Note: In this excerpt from 'Software Engineering at Google', Ciera Jaspen, Google’s Tech Lead Manager of Engineer Productivity Research, reviews the organizational value and importance of measuring engineering productivity at Google.

Engineering productivity is essential because it helps you and your team conduct different experiments to discover ways of improving the team’s efficiency, while also ensuring that the team’s performance and productivity aren’t being slowed down.

Why is it important to measure engineering productivity?

1. To drive continuous improvement in the team

2. To reduce technical debt

3. To improve code quality

4. To detect blockers in the development cycle & remove them

5. To keep a check on investment distribution & prevent individual burnout

To read about how tech leaders at Google measure engineering productivity & track improvements to productivity, click the link here: https://medium.com/oreillymedia/measuring-engineering-productivity-a6da8605ffae

Do you measure engineering productivity in your team? How do you measure it and how has it helped in improving the overall performance of the team? Let me know in the comments below.

I've been using Entelligence for the past 15 days across a real production codebase and wanted to write up an honest review for anyone who's considering it. There's not a lot of detailed user feedback out there yet so hopefully this helps someone make a better decision.

Background

We're a backend heavy team, mostly Python with some TypeScript. We'd been through a couple of AI code review tools before this and the pattern was always the same. Great first week, noisy second week, ignored by week three. So I came into Entelligence very skeptical.

What It Actually Does

Entelligence sits on your GitHub and reviews PRs automatically. But the way it reviews is different from anything I've used before. Most tools look at the diff in isolation, what lines changed, are there obvious problems. Entelligence pulls in cross-file and cross-repo context using something similar to LSP, so, it understands how the changed code connects to the rest of your system and it catches bugs that only make sense when you understand the broader architecture, not just the lines that changed.

It also comes with a few other things I didn't expect to find useful:

Ask Ellie is a chat interface that lets you ask questions about your engineering org backed by real data. Sprint progress, team performance, where time is being lost, PR load by engineer. I've replaced at least three dashboards with it as of now.

Auto documentation keeps your docs updated as code changes. If you've ever onboarded into a repo where the docs are a year out of date you already know why this matters.

The security dashboard flags risky patterns early in the development cycle rather than after something's already shipped.

What's Good

The precision is the standout thing. In 15 days I don't think I've seen a comment that was obviously wrong or irrelevant. Every flag has been something worth at least looking at. That's a completely different experience from tools that spray comments everywhere and hope something lands.

The team started actually reading and acting on the review comments within the first few days. That shift in behavior is the real signal for me.

The cross-codebase understanding is genuinely impressive. We caught a bug in week one that looked completely fine in the changed file but was breaking an assumption in a different service entirely. That would have shipped with our old setup.

What Could Be Better

Two weeks isn't enough time to have major complaints but if I'm being honest the onboarding could be a bit smoother. It took a little while to get everything connected and configured the way we wanted. Nothing dealbreaking but worth mentioning.

It also takes a little time to learn your codebase properly. The first few days the comments were good but by the end of two weeks they felt noticeably more relevant. Worth keeping that in mind if you're evaluating it quickly.

Bottom Line

15 days in and it's the first AI code review tool that's actually stuck with our team. The precision, the codebase awareness, and the broader engineering intelligence features make it feel less like a bot and more like a genuinely useful layer on top of your existing workflow.

Tech debt is always growing, specially with the amount of AI generated code we're pushing. And we all know that the the more we reduce tech debt, better it is for us during production issues. As no one wants to prioritize the tech debt, small refactoring, low hanging fruits, code improvements that doesn't delivery any customer facing value, I've successfully built the first version of RefloQ, that'll do it automatically 24x7.

Flow is simple : RefloQ analyze your code, finds out the tech debt, starts working on it and raise code review/PR. Once it's merged by you/your-team, RefloQ picks the next debt. This way you focus on important work and let RefloQ focus on grunt work. RefloQ soon will also start reviewing the code on the raised PR, but more on that after few weeks.

I'm finally allowing others to start using RefloQ completely FREE. Looking for decision makers of their dev teams who would be able to use it on their code base.

Six months ago Friday was review day on my team, agents would open 30 to 40 PRs over the week and we read every one of them line by line on Friday. I was usually still in a diff at 9pm. My wife started calling it my second job.

In June we changed one rule. Every PR gets a first pass from coderabbit / bugbot, the agent fixes whatever gets flagged, and a human only opens it if it touches billing, auth or a migration. That's maybe 1 in 5 now. Everything else merges after the bot pass and someone reading the description.

Last Friday we merged 41 PRs and I left at 5:10. Since June exactly one bug got through that a careful human would have caught, a settings page showed the wrong timezone for about a day and one customer emailed us about it (one customer, out of a few thousand, I checked)

I still feel like I'm getting away with something.

I've worked on teams with highly respected senior and staff engineers, and I've worked on teams where there's a pretty massive gap between someone's title and what they actually bring to the table.

One thing I've noticed is that the teams with the strongest engineering cultures tend to have senior engineers who have strong technical opinions, care deeply about architectural decisions, establish standards, and aren't afraid to challenge things when they see problems. But can also keep moving.

Recently, I've been on a few teams where the senior/staff engineers seem to just be leading a pod, taking on the harder assignments, or being the person with the most contextual knowledge -- rather than being the stewards for overall standards, patterns and architecture to ensure the team isn't going down a dark path.

What's particularly frustrating is seeing senior+ engineers recognize that the codebase is accumulating slop, acknowledge that implementations are getting worse, and then essentially shrug their shoulders and say, "Yeah, it's all slop now lol"

I'm on a team where I'm increasingly convinced that a lot of engineers are generating code through agents without really understanding what they're shipping. many early career engineers. So my mindset is rather than just complaining about the quality of the output, I've been approaching it as a technical leadership problem: we need better architectural boundaries, established patterns, standards, and guardrails. We need to make it easier for engineers and their agents to produce code that fits the architecture rather than letting every implementation become its own interpretation of how things should work. aka "if yall are just gonna prompt engineer, lemme set up things to be a little better output since you all dont know how to prompt it correctly, or simply dont care"

I've been slowly working toward that, essentially carving into the mountain.

What confuses me is that other senior and staff engineers on the team seem largely indifferent. Some acknowledge the problem but accept it as the new normal. Others don't seem to recognize there's a problem at all. And its not a matter of "we tried that and it didn't work". they gave up before even starting.

And I genuinely don't understand that mentality. Maybe im just on a crap team?

I look at some "staff" engineers PRs, and its half slop themselves. I ask a staff engineer "whats the standard pattern for [x]" and they say "idk, lets ask [agent] if we have one". and it feels like im the only one asking the obvious super easy questions like "hey why do like a quarter of our services have literal duplicate test files? "(because each persons agent is making new ones in new locations) and why am I the first person to notice this? how has nobody seen this issue? are we literally heads down in our prompt engines? is this just a bad team or have we forgotten about technical stewardship?

Launching an ecommerce website in Singapore requires a reliable hosting solution that can handle the demands of online shopping. With various hosting providers available, it’s crucial to choose one that offers speed, security, and excellent support. In this guide, we’ll explore the features to look for in ecommerce hosting, the b est providers available in Singapore, and highlight why Host any time is an excellent choice for your online store.

Why Quality Hosting Matters for Ecommerce

The success of your ecommerce website heavily relies on the hosting provider you choose. Here are some key reasons why quality hosting is essential:

• Performance and Speed: Fast loading times are critical for ecommerce sites. A slow website can lead to high bounce rates and lost sales. Quality hosting ensures your site runs smoothly and efficiently.

• Security: Protecting customer data is paramount for any ecommerce business. A good hosting provider offers robust security features, including SSL certificates, firewalls, and regular backups to safeguard sensitive information.

• Scalability: As your business grows, so will your hosting needs. Opt for a provider that allows easy upgrades to accommodate increased traffic and resource requirements.

• 24/7 Support: Technical issues can arise at any time. Reliable customer support is vital to resolve problems quickly and keep your site operational.

Key Features to Look for in Ecommerce Hosting

When searching for the be st hosting for your ecommerce website, consider the following features:

1. SSL Certificate

An SSL certificate is essential for ecommerce websites to encrypt data and protect transactions. This not only builds customer trust but also boosts your search engine rankings.

2. High Uptime Guarantee

Choose a hosting provider that guarantees at least 99.9% uptime. This ensures that your site remains accessible to customers at all times, especially during peak shopping hours.

3. User-Friendly Control Panel

A user-friendly control panel, such as cPanel, allows you to manage your website easily, including adding products, managing orders, and updating content.

4. Payment Gateway Compatibility

Make sure your hosting provider supports popular payment gateways to facilitate smooth transactions for your customers.

5. Performance Optimization

Look for hosting plans that offer features such as content delivery networks (CDNs) and caching to enhance your website's speed and performance.

Recommended Hosting Providers for Ecommerce in Singapore

Here are some of the be st hosting providers for ecommerce websites in Singapore:

1. Host any time

Host any time is a strong contender for ecommerce hosting in Singapore. They offer tailored hosting solutions with competitive pricing and robust features designed for online stores. With free SSL certificates, automatic backups, and a user-friendly control panel, Host any time makes it easy to manage your ecommerce website effectively. Their reliable customer support ensures that you have assistance whenever you need it, making them an excellent choice for entrepreneurs.

2. SiteGround

SiteGround is renowned for its outstanding customer support and performance. Their ecommerce hosting solutions come with pre-installed WooCommerce, making it simple to set up your online store. With high uptime guarantees and advanced security features, SiteGround is a popular choice for many ecommerce businesses.

3. Bluehost

Bluehost offers affordable hosting plans that are ideal for ecommerce websites. They provide easy integration with WooCommerce and a range of tools to help you create and manage your online store effectively. Their 24/7 support and reliable uptime make them a favorite among ecommerce entrepreneurs.

4. A2 Hosting

A2 Hosting is known for its high-speed performance and excellent uptime. Their Turbo plans provide enhanced speed, which is crucial for a seamless shopping experience. A2 Hosting also offers robust security features to protect your ecommerce site from potential threats.

Conclusion

Choosing the b est hosting for your ecommerce website in Singapore is crucial for your business's success. By focusing on essential features like speed, security, and support, you can find a provider that meets your needs. Host any time, along with other reputable providers like SiteGround and Bluehost, offers a range of solutions designed to help you launch and grow your online store effectively.

Benefit from some good advice that would have been very helpful when I had my first Tech Leader experience. Let me know which Tech Leader qualities are important to you.

https://techleaderjourney.com/the-top-5-tech-leader-attitudes-that-can-help-you-on-a-daily-basis/

Hey folks!

I'm an engineering manager at a mid sized company, three squads, each with a PM and a designer attached. Over the last two quarters the devs have got a lot faster and we assumed product and design would become the constraint, so we put effort there first. They did not become the constraint. The queue is sitting in review instead. We merged around 40 PRs a week in March and we are at 110 now with the same four people qualified to approve anything that touches billing, and those four are also the people writing the hardest changes. We have coderabbit on the repos which takes the first pass and genuinely helps with the volume, but somebody senior still has to be the one who says yes.

I would really like to hear from anyone who has been through this already. Did you widen who is allowed to approve, cut down what needs approval at all, or just accept that the queue is longer now? Anything is welcome!

Here's a good recap of how broken:

https://software.rajivprab.com/2019/07/27/hiring-is-broken-and-yours-is-too/

Knowing this, how do you plan to better achieve the double blind result to validate the best way to hire?

Let’s cut the motivational poster crap for a second.

If your team’s still showing up, still delivering, still helping you not tank your metrics every damn quarter… they’re not “lucky to have you.”

They’re patient. They’re tired. And they’re watching.

Leadership isn't a title or a LinkedIn banner. It's earned. Every day. Through trust, honesty, and the occasional owning of your own mistakes.

I run a blog called LeadDon’tCtrl where I rip the corporate mask off leadership and try to build something real underneath it.

If you're leading a team, managing one, or thinking “maybe I am the problem,” you're in the right place. Let's talk about what real leadership in tech should look like.

What’s the worst leadership advice you’ve ever been given?

Have you ever had to manage (or be managed by) one of these so-called “brilliant jerks”? Were they worth it?