To me, engineers receive specs from management and implement solutions that meet those specs. And that's it.
I suppose my personal experience must not be how things work elsewhere! Kind of fascinating, and it makes me wonder if people enjoy all this extra responsibility and how things go when engineers disagree with management.
You get the picture. Yes lead developers exist, but they only have so much time to do little battles and they're busy making sure the big things are arguing correctly. Senior engineers should be able to talk to design about a redesign necessary because iOS just isn't capable of this it turns out or the cool effect you saw is only available on a version we don't use and can't update to right because complex reason.
If you're just taking your requirements and working without having to negotiate with another person, you're probably not doing senior work.
Some of it I the site I don't think is senior work really unless you're a tiny shop, but they're not weird since these are all skills a for senior adjacent roles that any senior might be called on to take randomly. It's not uncommon in many shops for leads to be a spontaneous and temporary role for some project that disappears on major release.
My experience has been an issue is raised - usually by management or "the business", but sometimes by engineering. "Our website is too slow!". Now someone has to step up and clarify things. Like: * what does "fast" even mean for our website? It would be great to have an objective metric. * Is there such a thing as "fast enough"? * How much time / effort / money is a given improvement worth? * How do we prioritize this vs. everything else we could be working on?
A project spec comes out of those discussions, but the discussions themselves have significant technical and business inputs.
I don't view taking part in these discussions as "extra" responsibility, I view it as a core part of the job. I've also seen what happens when specs are written without technical input: it makes implementing them a lot less pleasant.
Then managers should learn whatever it takes to be able to make these types of decisions. There seems to be a double standard where engineers have to do all of these non-engineering tasks, meanwhile non-engineers never have to learn the systems in depth.
I think programming is a hard enough job that warrants 90% of focus, at least to be able to reap the benefits of computer science. At the dawn of generative AI, we can clearly see software has no limits, yet limits are implicitly imposed by re-prioritizing an engineer's time with "soft skill" tasks and having them spend a huge amount of time thinking about things that have little to do with computer science.
If a business needs that specific intersection of skillset, perhaps it should be a new role, instead of stretching the role of engineering and missing the opportunity to innovate at the software level, which in the end would help the business anyway.
My first internship, a long time ago, was making HTML websites manually. At the time JS was still young and was not widespread, but I still wrote a custom content management system that would write HTML for me... when I presented this to the people in charge, there was no interest. They didn't care I could do the work faster. They had clients, which payed them by job and not by time. This is just one example of many I experienced of how businesses are blind to how much programmers could add value to their company by simply optimizing their expertise of software engineering. Software engineers are boxed into roles where they are unable to focus on engineering only, and as a result they never achieve the technical level that will allow for domain specific innovations.
So no, engineers don't really have a limit on productivity (granted there is a cost), given that you can write code to write code. There really is no limit, we just have to look at AI.