For a while, I worked for a manager that wore a lot of different hats on our team, including that of “product manager.” Sadly, that meant he was often really busy and thus hard to pin down to get a product answer from. He knew that this was an issue, and wanted to get a full-time product manager for our team. At the time, I was thrilled about the idea. Fast forward a few months, and a little reorganization later, and our team now has a dedicated product manager, and I’m regretting my earlier enthusiasm. There seems to be a disconnect between product people and developers, so for any product managers reading this, here’s a few tips to help improve your interactions with developers.
It’s not an emergency. Seriously, just because you saw something or had a thought doesn’t mean it’s so vital that developers need to drop everything they’re working on and address it. There’s a ticketing system in place, consult it, and put your request in the appropriate place. If it really is time-sensitive or just a “couple of minutes” (by the developer’s estimate, not yours – see later on in this blog post) then ask us (more details on how to do that later) and we’ll get around to it as soon as we get a spare moment.
Interrupting developers is generally the worst possible option. Google “open office productivity” and the first page is full of results talking about how the open-office floor plan hurts productivity. Part of this is that it makes it more seemingly acceptable socially to just walk over and interrupt a developer’s concentration every time you have a question or want to talk about something. But being productive in development requires focus and concentration, and having someone walk over and start talking to you about something else is the least helpful thing possible. If you really need to talk to a developer that’s ostensibly working, try leaving a message on email or chat, where they can be aware that you want something but can get back to you when their brain’s ready for a context switch.
It’s not “just easier” to talk in person. Keeping with the “don’t interrupt the working developers” theme, please don’t take a conversation from email/chat to “in-person,” especially when it’s in the early stages. Remember, developers are trying to focus, and part of the advantage of those mediums of communication is that they’re asynchronous – once a developer gets “into the zone,” email and chat can be easily ignored while they ride that focus they currently have for all it’s worth. On the other hand, walking over and talking to developers forces them to drop everything they’re doing, wrap their brain around your issue temporarily, and then try to get back to where they were before you threw everything off. If you absolutely, positively need to talk to a developer in person to resolve it, ask them to come by when they’re free.
Don’t message developers on 1 channel to tell them you left them a message on another channel. Just because someone didn’t respond immediately doesn’t mean they’re never going to check for messages. Telling someone they have a message waiting via another communications medium is just going to make it take longer to get to your original message as they now have to stop and have a conversation about you starting a conversation somewhere else. Plus, it makes it look like you don’t understand how things like email/chat work, which is pretty embarrassing in this day and age. Do yourself a favor, assume developers are aware that they have emails and chats waiting for them and check their messages eventually.
Meetings don’t make anything better. I know you guys really like turn everything into a meeting, but all that does is waste people’s time and make it harder for them to get any real work done. Look, you’re the product person, ultimately, the decision rests with you, so just make one already. There’s no reason to make people stop what they’re doing to sit around and talk about something that can be settled by you just saying “here’s the way this thing is supposed to work.” That saves everyone time, aggravation, and removes yet another interruption that screws with progress.
Nobody thinks in ticket numbers. Asking about the status of PROJ-4782 isn’t going to get you an immediate answer. That’s because normal humans don’t think in ticket numbers. You’d be better served to ask a developer about the status of that ticket to update the database schema. From my experience, most people are only in the project management software long enough to figure out what they should be working on next, or to look up ticket numbers so they can answer product manager questions. They don’t have a ready association of code and number combinations to actual work. If you want a fast answer on how something is coming along, your best bet is to ask about the work itself.
“It’s what the customer wants” does not absolve us of providing adult supervision. We work on marketing software, which means our customers are marketers. This is a customer base that every time they start doing whatever they want, behaves so badly the United States Congress has to step in and outlaw it. Just because our customers want to do something doesn’t mean we don’t have a responsibility to evaluate whether that’s a good idea or not. Our entire product has a definitive opinion about how marketing should work, so at the very least we should be considering customer requests to make sure anything we do is consistent with our app’s philosophy.
If someone hasn’t given you an update, it’s because nothing’s changed (and no, there’s no new ETA either). If someone says that they’ll keep you updated on a situation, then they will – as that situation changes. If there’s nothing new to report, then there’s nothing for them to say and thus no need to pester them to see if something’s changed. By the way, if they didn’t have an ETA before, assume they don’t have one now. While we’re at it, if you really need updates that badly, odds are the person you’re asking is dealing with something that’s gone horribly, horribly, wrong, so let’s just assume status updates aren’t anywhere near the top of their priority list.
Unless you’re talking about something that we just released, let’s assume that the app in question generally works. Yes, you saw something that looks weird on your machine with you test setup, but here’s the thing: if there was a real bug, then there would reports from customers by now. So instead of freaking out that the app has a potential bug and sending your developers on a guilty-until-proven-innocent wild goose chase, first assume there’s something specific to your environment causing this. If you really want someone to follow up on it, try seeing if it exists on a real customer’s site before bugging developers about it.
The project management software is the least of anyone’s concerns. I get that you spend large portion of your day looking at our ticketing software and filling out all the fields on each ticket. The developers on your team don’t. They spend most of their day staring at code, and only checking the ticketing software to see what the next work they need to start on is and mark and tickets they finished as being done. Don’t freak out if they haven’t filled out all the possible fields, and don’t freak out if it says this sprint you have more work than you can do if you’re trusting the estimates. So long as the project management software has a prioritized list of work, it’ll be fine. Freaking out about it just forces developers to waste time they could have been spending knocking tickets out solving the problem of “too much work this sprint” for you.
The developer who works on the code question will be in charge of time and difficulty estimates. This one’s real simple. Unless you’re in charge of the code in question, you should not be suggesting estimates or making claims about how much work something will take. It doesn’t matter how obvious the answer seems – you don’t know what gotchas or technical debt is out there that the developer’s going to need to be work around. The developers live in this code, ask them for estimates and don’t try to argue with the answer you get. They know things you don’t.
It’s important to understand two things about dealing with developers – the first is that we need to be able to concentrate, and the second is that we’re very busy, and a lot of stuff isn’t as big a deal in the grand scheme of things as you’re making it out to be right this second. Just keep calm, trust that the developers on your team know what they’re doing, let them do their jobs, and you’ll all get along just fine.