New to leadership - is it common to have your C suite continuously pressuring for more work?

Smallish company, promoted from IC to leadership. I built a small team to improve our throughput. The daily reports from our team have lead the c suite to believe that we were being very productive, but one of them began watching over my team's shoulder, scrutinizing what they do every minute of the day. They've been making heavy use of AI, and I'm getting negative feedback from the team having downtime. I don't think this would've ever been an issue without AI, as they can fire away with minimal work on their end.

They're each tackling 1-2 somewhat moderately scoped tickets a day, and we're starting to drown from code review. Some of these tickets are taking like, 3-5 iterations to get right, and I'm concerned that handing them more complexity will result in total code review hell.

Is it normal to be scrutinized in this way? Other departments (such as support, QA, etc) would be happy to see their tickets turning over. It almost feels like they expect the engineers to be typing 24/7 and are missing the forest for the trees.

Maybe this is normal and the c suite pressuring engineering to be faster, cheaper and more productive is a tale as old as time?

Should I be keeping metrics to defend my team?

reddit.com
u/BringBackManaPots — 1 day ago

When you look at code, what's the real difference between mid and senior level code?

I've started having Claude evaluate various files for code quality, and it got me thinking. What would an actual experienced human say? How do you actually tell the difference between solid mid level code, and senior level code?

Our roles where I work are generally more about scope, responsibility, and trust - but that being said, I don't think I could reliably tell the difference between a mid and senior level engineer in a blind code review.

reddit.com
u/BringBackManaPots — 1 month ago