How do I tell someone to be more concise and message me less frequently?

Question

I'll try and keep this short and concise to avoid "venting", rather than explaining.

Long story short, I use skype to communicate with someone my company has contracted with. I am a programmer and he is a designer. He's designing using a system I'm constantly building as he uses it. It's less than ideal, but we do what we can with the time and money we have.

The issue is that he messages me with every little hiccup. Not just bugs, sometimes un-reproducable bugs, sometimes odd behavior, sometimes speculation about a bug, sometimes things he has the power himself to fix, but most of the time it's vague. I realize this is not necessarily an objective problem that most people face, but I want to be bothered less so I can focus. I know communication is good. This is 100% an issue I'm trying to solve to keep me in a good mood when stress levels are high. I fear I am nearing a breaking point and may say something hurtful. He is, as far as I know, unaware that he is bothering me, but I don't know how to tell him.

How can I tell him in a professional manner that I only want to be notified of a bug/issue if it's reproducible and if he can explain exactly what is happening?

As a caveat, I do need to be available whenever, because when he has bugs, his work stops. If I stop communication, he stops working, and the end to the project is nigh.

Answer 1

Give him a structured bug/suggestion reporting system and encourage him to use that. Even a wiki can be pressed into service for this, though structured sortable/searchable records are better. There are lots of off-the-shelf tools for this, but I'll describe the goals.

Cone up with a standard set of info to gather for bug reports (We call these "mustgather instructions"). Remind him that it's extremely difficult to fix a problem you can't see happen, so you need the log snapshot at a minimum and ideally you need a description of a sequence of operations that reliably provokes the problem, a snapshot/sample/detailed description of the erroneous/suboptimal output/behavior, and a sketch of what output the user expected/wants to see instead.

Encourage him to rate the severity of the problem, from "nice to have" through "cosmetic", "annoying but I have a workaround for it", "broken but I don't really need it yet", "broken and I need it fixed soon", "broken and I can't use or ship it like this" up to "broken and I can't even develop other parts of the system until it's fixed" and "my God, if management saw this they'd fire both of us." Or similar terms. Some companies separate severity (how badly thus impacts the users) from priority (developer's decision of what has to be worked on first, not always the same ordering).

This captures the user feedback -- which is hugely valuable even if sometimes annoying -- without interrupting you for anything but major disasters, and stores it in a form you can use directly rather than having to re-transcribe into a database yourself. It also captures discussion and files needed to work through the problems.

This doesn't scale directly; for large companies and large products you can't count on customers writing decent problem reports and need to have people who can interview/guide them to provide the right info before it can be entered into the database. But your direct-support situation, with a customer who is eager to help perfect the tool, send an ideal opportunity to "dis-intermediate" this while making the experience better for both the developer and the user.

I'm a developer, and I'm very much this sort of customer. The more I like something, the more I'll try to help make it even better. All that noise coming in is backhanded applause; it means the customer thinks you have something worth improving!

Answer 2

A bigger group would use a bug intake process that gave some degree of abstraction. I agree that the most useful answer is to get to some sort of aggregation/separation of bugs - but you are going to have to teach this person the basics of bug reporting as he's basically your QA team. Teaching folks who haven't worked in a development role can be tricky, since you have to figure out how to frame what you need in a way they can grasp.

This would be my approach:

1. State your needs in a non-accusatory way - you need a chance to focus on your work without interruptions, and to have as clear a description of the problem as possible when you are working through bugs. If you are interrupted every few minutes or every hour, your work suffers - you make more mistakes, it takes longer, and loosing a chance to focus on the work makes you frustrated. It's important to separate the cause of the problem (his action of interrupting you) with the human causing it.

2. Propose a solution that may still meet his needs - he needs (1) a way to tell you what's wrong so you can fix it in a timely manner, (2) a way to get immediate help when the problem is an absolute blocker to getting anything done. Solutions are likely to include:

   • a primitive bug tracking system - it could just be a google doc or a github issue - as long as the bug is discrete, written down clearly, and trackable, you've got the basics. Ideally you have a format of info you need from him to solve the problem and he has a clear indication from you on where your progress is in fixing it. There's lots of great systems and templates out there for this
   • a criteria for what constitutes an interrupt-worthy emergency - yes, he needs a way to interrupt you - if your latest build simply does not work, it's not fair for him to have to wait for a blocking issue. But you two need to agree on what that is - usually things like "app won't start", "app won't respond in any way to user actions", "can't start or complete critical workflow under any circumstance". Usually anything where the user can find a workaround is non-critical.

3. Ask for his feedback/concerns - Don't dictate, ask questions - how frequently may you two want to meet on the bugs he finds? What way of collecting the bugs is most useful for him? What is a blocker/emergency in his world and how often does that come up? Does he agree with this process? Does he have a better idea?

4. Review bugs and ask questions/give feedback as you go. Generally with a non-developer/non-QA stakeholder there will be a learning curve on how to write a good bug report. I won't say "non technical" - there are very technical people who are bad bug reporters, because they never had to fix/find a bug in a formal dev enviroment. Along the way of teaching, you can repeat the steps above - tell the guy why you need the information, give him a format to give it in, and show him the conditions under which you need the information.

Where you are a 2 man team, be open to the idea that words aren't the only way to write a bug report - for example, our QA (who are real QA people) have been doing excellent videos for us here - they use screen capture, record what they are doing and what they are seeing - we can see every piece of data, every button click and exactly how the system responded (like measurable load time!) that way. Different folks are good at communicating different ways, and you may have to adapt to each other and work with each other's limitations.

Periodically, set up some time to brainstorm improvements to the process - what do you both need, how shall you make it happen? You can even propose a time box - "let's try this for 4 weeks and then check in with each other and see if it helped".

Answer 3

I do agree with Prusswan's comments. Replying to every chat gives him a hint that you are open to such conversations, and it just makes the situation worse.

So, reply to only the relevant conversations and do not reply for the ones which are irrelevant.

However, not replying at all makes you look unprofessional as you have rightly said here. So, do stock replying. Reply to a bunch of minor bugs at a time, after 5-6 get accumulated. It would save your time, as well as helps you retain the trust he has on you.

This would give him a hint that you are taking valuable time out once or twice in a day for getting back to him on the minor issues, and he will respect your time and would try to lessen the number from next time, and it wouldn't portray you as unprofessional.

Answer 4

I had much the same issue with multiple people bugging me all day with inconsequentials they could figure out themselves if they tried. I solved it the easiest way I could think of.

I stopped using Skype and I've never started again. Anyone with an issue or bug or whatever has to email me, when they do this they actually have to type, so they tend to think things through better, itemise the issue properly and all sorts of other good things.

Best of all I can reply whenever I want. And I tend to be terse and professional in my replies, it cuts out the chit chat. Time is valuable. So I look at their issue, fire off the relevant questions and wait for the answers. Rather than a conversation wandering all over the place talking and re-iterating etc,. It allows me to focus much better and gives me a solid paper trail for reference anytime I want it.

Answer 5

Answer Skype at set times in the day - first thing in the morning, immediately after lunch (or at another schedule that makes sense to you). For the rest of the time, turn it off. Otherwise you'll never be effective at your job.

To notify the contractor, send an email with him as a bcc (so he won't see everyone else it's sent to) saying that for productivity reasons, you're only looking at skype and email twice a day for the next two weeks.

Answer 6

Insist that the two of you use a bug-tracking software like Bugzilla. This will cut down on the "noise" because he probably feels he has no reasonable outlet to share his concerns other than to Skype you all day long. That's nerve-wracking.

A bug tracking system will force him to choose his words carefully to empower you to do your job, without all the fluff.

Answer 7

Been there, done that.

Thing is, are you your own manager? If not, then you should bring him in, asking for a way to improve your performance as a team. Now, managers (been there too) do not like issues coming without a solution, you as developer can write in a couple of hours (yes, you can) a bug tracking tool if money to acquire one is an issue or you have no time to pull something out of the shelf and learn it.

Your manager will be glad to assist you to set rules and ask politely to the designer, to play by them, it is not you call here, you've done so far all that you can.

Now, things won't change that much right after but then you can improve this. From all the bugs you have, you could meet by the end of the day/week and grade those, you need to understand his concept of a stopper and you can even give useful feedback in return, after that, hopefully you have a way to weigh issues and figure out things that can be fixed later and separate those from what really breaks things. Still you get the chance to tell this guy that for fixing the bad ones you need time to focus and that you would like not to be disturbed during that time, really, being direct never hurts, as long as you don't abuse the DND status you'll be fine.

TL;DR: Ask your manager to intervene and bring a proposal when doing so.