| > Support brains and developer brains are actually not that different. I see on HN way too often that developers need space and time to think, but other types of people don't. This is myth that needs to be dispelled and everyone should contribute to uphold boundaries that work for everyone. I disagree completely. When I am working on a complex problem (just yesterday I was writing a code for non trivial distributed program involving web sockets and multiple channels of communication between several parties), I really need let's say an hour (but it could be more) to "load" the current work in progress implementation into an in-memory model in my head so I can reason about it and continue development. When I have to break this process and deal with something else it completely wastes my time and I have to start from scratch. This might not apply if I am currently working on some CRUD or other stuff which doesn't require much mental capacity, during those days I can switch in between different tasks easily. But on those other days when I am doing an actual development work involving algorithms and networking I really don't want to be disturbed because I will lose the plot and waste a lot of time. > Trust that absolutely I want you to have 'flow' time - it's important that you both be and feel productive. Good code from you is good code for me and for the user.
What breaks flow is context switching, which is literally baked into the job description for your average support role. Agents often need to answer questions about multiple/complex products, and who knows if they have access to high quality documentation or internal tools. In most companies there is actually a separation between development and support. I think it's rare (perhaps in startups) to have support people just be able to come and start chatting to developers or engineers. The usual process is you have to go through the development manager and he/she decides how to further delegate the work. Developers are probably in a sprint already working on features and don't have time for some ad hoc unrelated work. For that there would be a separate "on call" team which would rotate couple of developers in for 2-4 week stints or so and these would not work on any new development but would be available for fixing urgent bugs. > It's totally OK that a support person's time is variable like this, but it's dangerous when the pairing developers time is untouchable. Pro tip: make ground rules for what developers might be "on-call" or have office hours, have rotating schedules for which developers need to help support teams, have dedicated places where agents can escalate engineering tasks without physically bothering someone. I agree with this. But I would be careful with too much of rotating as if you just keep moving around engineers from projects they are working on to do different work, projects will get super delayed. Usually if I own a project and work on something, there is only 3-4 people who are familiar enough with the domain to be able to work on this. New developers will need couple of weeks of on boarding time. If you start rotating developers around you will waste huge amount of time as new devs need to be brought up on speed to projects and then they will leave in 2 months so you have to do it again. |