What else are they supposed to be doing? If requirements are fleshed out then all you can do is get started. The bigger the change, the more you'll have to be concerned about architecture and implementation details. I think sitting down and thinking about the problem before you code is necessary for any dev, but I'm here to write the solution at the end of the day.
>If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special.
My company right now is about 15 people, 5 of which are engineering (including myself). When your team is that small, you don't have room for too many specialists. We're all capable individuals that can do the work without waiting for anyone. I'll get a ticket asking for a new web page, a new backend endpoint, DB updates, Et Cetera and it's the expectation that I do this all by myself. If there's something out of my wheelhouse, I can lean on my team but this is the exception and not the rule (and can still be done async). I don't know what special looks like for you but I can list the contributions I've made and the impact it has for our bottom line. In two months I reduced AWS spend by $5k/month, added payment enforcement logic netting us tens of thousands within the first week of its release, and seamlessly added a Huggingface NLP model into our AWS infra (our DevOps guy doesn't even know ML, he just treats the Sagemaker instance like any other resource). That's pretty impressive to me.
The problem with posting any comment on here, is I have to always preface everything with "Generally speaking" I assume it's implied, but yes - you will always have cases where something isn't true. Tiny companies is one for sure, but tiny companies with 5 engineers, well collaboration isn't as much of an issue.
Most of us work at bigger companies than that (I would argue even on HN). I too have lived in the world where I was DBA, front end designer, API designer, infrastructure, and even contract negotiation, and that's a whole other ball of wax. It's also not what the original post is really talking about in my opinion. Companies like yours are not the ones trying to do in office work remotely, and those are the types of companies I am talking about.
On a side note your job sounds either fun or stressful as hell to me. I can't decide. I hope you're enjoying it and being paid well :)
As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.
That sounds more like a manager or architect than an engineer. Engineers should take a proactive role in discovery and talking with business to figure out the best place to create value (that's a once a month meeting for us), but at the end of the day it's up to the PO to translate business needs into product development. Either way, I doubt you need 4+ hours a day to flesh out the technical requirements. When I worked at bigger companies, I'd spend only roughly 4 hours coding a day too. It's not because the problems were harder, but because there were blockers at every corner due to siloing and overly complicated business processes. I'd spend days in meetings and escalation emails just to get a networking rule exception.
>As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.
Then you're a sucker. Engineers are supposed to write code. Even at the bigger companies, all senior engineers (and I mean 15+ experience) wrote code most of the time and did everything in their power to avoid meetings and other disruptions. That's how I learned about the "Law of Two Feet". Business expects you to coordinate between stakeholders and the rest of the engineering team. What's next? Should you manage the team's budget as well? Make long-term product roadmaps? Get yourself a promotion!
We have people who do JIRA tickets specified and prioritized for them ahead of time by others. They are called Engineer I and Engineer II. They don't get paid nearly as much or have the autonomy and recognition that senior engineers do. Most of them are biding their time waiting for managers to finally find projects they can drive instead of help with, so that they can finally demonstrate senior competencies and get the title themselves.
Developers add value in so many more ways that heads down concentrating on code. A senior engineer should spend the least amount of time coding compared to everything else they do during the day. If they don't, do you really need a senior engineer? How much of a 4 hour coding session is something you needed specific expertise in and how much is mindlessly typing the syntax with a big of logic peppered in?
If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special. Having worked for many years in both office 9-5s and global async teams, async teams are incredibly frustrating to organize if the work requires any collaboration. In a perfect world sure your 4pm is my 8am and we can work there, but factor in real life, people leaving early, coming in late, and it becomes incredibly annoying to deal with in practice. It takes much more management overhead, and you truly have to ask if the benefit you get from having engineers async is really worth that extra overhead. I would argue in most markets it just isn't. I would take a 20% worse engineering staff all working together than the alternative of a better staff split into different time zones. This is coming from someone who lives in Iceland and has had to work async for the bulk of my projects in the last few years. I found the lack of human contact and collaboration so boring that I took a big paycut to work with people again every day.