Communication is Key to Your Project Success

Having excellent communication can make or break your project. Cris and Andrew discuss best practices, helpful tools, and some pitfalls to look out for. Finally they cover what to keep in mind when working with international teams.

Full Transcript Below:

Cris:

Hey, everyone. Welcome to another episode of Bixly Tech Tuesday. Cris, here again with Andrew, our COO. And today we’re going to be talking about communication with your development team. So Andrew, what are some recommendations for like strong communication techniques with your development team?

Andrew:

Sure. So one basic one is that it’s important that you have daily communication with your developers. And so we refer to those as stand up calls where you’ll have a very brief call with your development team, and you will just ask them three basic questions. The first being, what have you done since we’ve last spoken? The second being, what are you working on now? And the third being, do you have any blockers or anything that you need from me that’s hindering your progress? So just doing those regular stand ups it just ensures that you know what’s going on and you have just a good feel for the situation. And also too, that your developers aren’t waiting on something for you and you just don’t know about it.

Andrew:

A second one would be too that it’s really important that you cast the vision for your project so that the development team understands: what does success look like? Where are they going? And what are your objectives? Because to them, success might look like I finished this thing and checked this box off my list in the time I said it would be done. And to you, it might really look like a completely different experience. So developers tend to think in very concrete terms, like timeframe and budget constraints, and you are more thinking in terms of business, your business, and what’s going to solve the problem for your user. So it’s really important that your developers understand how they are solving this problem for your users.

Cris:

And in this scenario, you talked about casting the vision. Is that you, the project manager? Is that the product owner? Like the client, like who’s kind of the you in the scenario that’s building the strong communication, having these regular meetings, that sort of thing?

Andrew:

Right. And that’s a great question. And you are the product owner in the scenario, you are the person that understands your business, you understand your customer’s needs, the requirements, what problem this is solving for them. And then that’s a really good point that a project manager is someone who’s actually going to work with the development team and to make sure that technically the tasks are broken apart and done on time and in the correct order. So having a project manager is very important because unless you speak tech and you’re a developer, then you need the project manager to help communicate these things to the developers. But then you, as a product owner, have the responsibility again, of casting that vision and regularly casting it and also hearing feedback from your users and adjusting that vision as necessary.

Cris:

Cool. I like it. So what are some examples, maybe, of like ways to miscommunicate, whether purposefully or not, because those are going to happen on a project? How can it just be so easy to fall into those miscommunication pitfalls?

Andrew:

Absolutely. So the most obvious one would be that your communication is too infrequent. So kind of this set it and forget it mentality. I’m too busy to really think about my project. I just want to tell you one time, you’re going to build it. And then three months later I’m going to get the product and it will be exactly how I envisioned. That’s just not realistic. People just being too busy to oversee their projects and be a proper product owner is a common mistake. And if you’re too busy to pay attention to it, you’re probably too busy to do the project right now.

Andrew:

Another one would be just not making it clear to your development team that you’re open to feedback and that you want feedback. Because the developers want to make you happy. They want to do a good job, they want to please you, but if they don’t feel safe talking to you, they might not push back when you say something, telling them to do this route and you could very well not be technical enough to know that what you’re asking for is five times more expensive or has all these pitfalls down the road and they’re going to see that. And so if you come across as unapproachable or that you just want a bunch of yes men, then in many times, that’s what they’ll do. And when it doesn’t work out, it’s like, well, you told us to build that. And so you have to make it really clear to them that you do want feedback. You are paying for their expertise, but you have to make it clear that you want to hear their opinions and that sort of thing.

Cris:

And that seems reasonable, and also I’m even thinking that depending on, so if you’re going to be doing maybe more of a fixed bid style project, or maybe something that’s more time and materials, what you’re referring to Andrew, I think is more of a kind of build along the way, regular feedback type model. But if you’re doing more of a black box or fixed bid model where it’s a lot of communication on the front side, and then maybe a little less throughout the project, it’s important that those front side expectations of communicating what the goal is, of what you want the project to be, timelines, budgets, communication with the client. Like, yeah, we’re talking through this, but if you ever bump into an issue, just go ahead and talk to me, all that stuff either needs to happen throughout the project or needs to be very well established on the front side, if you’re going with a fixed cost.

Andrew:

Yes.

Cris:

That makes sense.

Andrew:

And another really common one that we’ve seen too, is people not communicating their timeframe and their budget. It could be because they’re trying to keep it hidden or it could be that they just have not planned well enough, that they haven’t budgeted for it. And that’s really just a recipe for disaster because you could have the perfect plan to build the most miraculous product in the world, but if you don’t have the budget to finish it, or you need it done in two months and the developers are thinking they have two years, giving an extreme example, it’s just destined to fail. And you’re going to end up in this last minute scramble. So it’s really important that you give proper thought to what is the timeframe for this first phase of the project? You don’t have to plan out what two years is going to look like. Just, what is, say, the first three months going to look like? And also what is your budget for that?

Andrew:

Because that way we can have very realistic conversations with you about it is what you’re asking for even feasible. I’ve seen projects before where the clients gave very grandiose ideas. The developers started building, and then two months into the project there, the client’s like, well, why isn’t it done? And the developers were like, well, yeah, it’s getting close. We only have another three months left and it just was destined to fail because there wasn’t that clear communication. So communication is the underlying important thing that needs to be there in order for your project to really be successful.

Cris:

That makes sense. And so obviously we’re dealing with co located teams generally because you’re doing some sort of outsourcing, that sort of a situation. So what are kind of some methods of actually communicating with your team? Obviously we could all pick up a phone and talk, but in 2021 or whatever year you happen to be watching this video, like what kind of communication tools do we have at our disposal?

Andrew:

Sure. Well, I think everybody knows about zoom at this point. So I don’t really need to go into detail on that. But video conferencing is obviously a thing. Some kind of tool where you can screen share is really useful because it can just help reduce miscommunications. So if you can just invite screen share, I literally mean you can just show your screen and say this blue button up here, I want it to have a green button next to it that says open or whatever it might be. So that’s super useful.

Andrew:

Another one that we use internally a lot is Slack, and that’s really great for teams to contrast like video conferencing with Slack. They both support video conferencing, but Slack provides an audit trail. You can see all the communication back and forth. At least all of the written communication, which is really useful if your developers are posting daily notes about what they’re doing and their challenges and things like that.

Andrew:

If you’re posting your requirements or maybe changing requirements, it allows the developers to go back and say, okay, that thing that you said two weeks ago, what was it they wanted? Oh, it was this. And then they can ask clarifying questions about that. So I really like Slack for remote teams and it does have a video conferencing aspect to it. So those are both great ones.

Andrew:

The phone, it does work, but I’ve seen meetings go an hour and a half that, honestly, if we would either been physically both looking at a whiteboard or sharing a screen together probably could have been 15 or 20 minutes just because there was so much okay, “What do you mean by this? What do you mean by that?” Kind of thing.

Cris:

Yeah. So part of the communication within your team actually is about keeping not only cohesion throughout the project, but also like obviously staying on task with stuff. And that involves not having long conversations, being concise and to the point, but knowing when based off of client expectations or expectations with your team, to let that communication kind of breathe a little bit more. And it seems like it can be easy. The voice is convenient to sometimes kind of believe a little bit. So that makes sense. I would say one note that I would add to kind of circle back on miscommunication things I’ve noticed over the years is making sure that you’re setting very clear expectations between the development team and the actual client on what’s the best method of communication for them. And kind of, what’s a good method of communication for you. Because I do know clients that are very concise over the phone, and they’ll give you some of the best information that way. And they’re extremely uncomfortable doing it over text.

Cris:

Or developers, for instance, that are really good over the phone, but maybe not as strong in the written word or vice versa. And so part of strong communication, I think, is setting expectations of how are we going to talk to each other? How are we going to effectively talk to each other? And then trying to lean into those. Even if it doesn’t feel like the strongest method for us as a company, it might be very strong for the customer. And obviously the customer is always right and you want them to be happy at the end of the day. So we’re always open if you’re looking to work with us, if you have existing kinds of tools in place, we love to jump into existing communication suites and kind of work in a method that’s comfortable with you. But obviously as Andrew’s alluded to, we’re always going to make sure that the project is effective and on time and as efficient as possible.

Andrew:

And along the lines of communication too, another tool that we use a lot are project management boards, we call them. So the idea is if you think of it like a cork board with a series of note cards on it, we use that a lot to assign different tasks to these cards and allow you to see, this is in the backlog. This is being worked on, this is in test. This is blocked. This is deployed. All those different things. So that’s a really useful tool also. And so we’ll use tools like [Jira 00:10:47] or Trello, things like that that allow you to very easily at a glance, see the state of the project and also post comments on the notes and say, oh, this thing, I ran into a bug here, that kind of stuff. So that’s also a very useful, a little more high tech obviously than just screen sharing, but basically this something that we set up for our clients, and it just gives them a lot of visibility on the state of the project and ultimately just provides better communication.

Cris:

Sure. And it’s convenient because it’s always available regardless of the day, time, even physical location, again dealing with the co-location teams. And that’s, I think a really strong pivot into when you’re dealing with international teams, because it may be that you’re working with someone local, but also there’s a lot of projects. As I know that, you know, are looking at overseas teams. So you may be looking at an overseas team and it’s kind of, how do I best communicate with them? And I think having a very strong written format, whether it be like you said, a Jira board or Trello or something of that sort, that you can have those notes and the teams can look at it at any time in the day, their time. And we can glance at it anytime of the day, our time is obviously very helpful. And it has, like you alluded to earlier, a very clear kind of roadmap of what happened, all that sort of stuff.

Cris:

But one thing that I’ve seen with international teams is maybe the way that we will use certain phrases, words, things of that sort, colloquialisms, they might be a little bit different when you’re dealing with international teams. So do you have any insight as to how to kind of maybe overcome those hurdles or other just feedback on working with international teams?

Andrew:

Sure. I think international teams, they’ll work in some scenarios. A big thing is if you have more time than money, that’s one. So let’s say that you have a very small budget. It’s fine if the project goes over a long period of time, you’re okay with, you’re going to do something. They’re going to see it 12 hours later, you’re going to get their feedback 12 hours later and that sort of delay in there. Or perhaps you’re just very comfortable communicating with certain people in a certain country. And so to you, there’s not a communication barrier over there. So those are a couple things to be aware of with international teams, but the communication becomes even more important when working with international teams because you’ve got that delay.

Cris:

Got it.

Andrew:

And so it’s one thing to lose an hour or two. It’s another thing to lose a day at a time for each miscommunication. So all these things that we’ve been talking about, about updates and Trello boards and video conferencing, those things become magnified tenfold.

Cris:

Interesting. Well, cool. Obviously I hope you got some insight into better ways to communicate with the team, whether it’s internationally or a team maybe even in house. But just those strong ideas of keeping your project on task and moving forward in the right direction. So any other closing thoughts as we kind of wrap up communication with teams?

Andrew:

One thing that can be helpful is to actually get to know your developers’ temperaments, because of course we’re all people, we’re all different. And so it can be really beneficial to know that this particular person, perhaps they’re a perfectionist. And so when you’re asking them to do something, they’re saying, it’s not going to work, or it’s going to take four weeks to do that. Well, if you know that they have a tendency to be a perfectionist, then it gives you the ability to kind of delve into that more deeply. Or perhaps there’s someone who they’re just very much a people pleaser, and they just want you to be happy, which sounds like a good thing on the surface, but they may just kind of tell you what it is you want to hear. Or, oh yeah, that sounds good. They agree with everything you say. And because you know, that that is their temperament, it allows you to kind of pull more information out of them.

Andrew:

And of course there’s many, there’s stereotypes for developers, being quiet and different things. But of course there’s many different temperaments for developers. And the more you get to know them, the more you understand them and kind of help understand what makes them tick, the better you’re going to be able to work together. And also as you get to know them, they’re going to get to know you. And it just helps form that cohesion to the best possible, even though you’re working remotely, you feel like you know each other and you’re on the same team.

Cris:

Yeah. That makes sense. And as you get to know them, you get to know how they communicate well and the ways that they don’t communicate as well. So again, maybe really well in person talking, maybe not as well over written word, or maybe extremely well on their daily notes, in those stand up meetings. But you get them on a phone call and you’re asking them questions kind of on the fly. It’s not that they’re not intelligent, but maybe they’re more analytical and their communication style is take it, process it, go back and tell you 20 minutes later. That can come across as very indecisive to a client if they don’t know that about the team. And if you don’t know that you’ll be sitting in a meeting, like, hey, answer their question. It can be kind of fun.

Andrew:

And some developers, you might just learn that when you give them your idea, you might just have to ask them, okay. So what do you see that’s going to go wrong here? What are the holes in my idea? Other people may be very quick to tell you what’s wrong with your idea and you don’t need to ask those questions to them, but you only know that by getting to know them as people.

Cris:

Cool. That makes complete sense. Well, I hope you were able to get some good kind of pieces of information out of this. I hope that you feel how you can potentially communicate better with your team. And as always, we would love to work with you. So if you have a project that you’re kind of working through right now, you’re looking for a development team, please go check us out at bixly.com. You can book a free consultation with us. You can go head up to that contact tab and just kind of get some more information about us in general. And then one thing that’s really important is we have a free software development brochure that is actually linked in the description of this video. So we would love for you to go and download it. It’s completely free. And hopefully you’ll be able to get not only the information that you got from this video, but some useful information from that brochure. So here at Bixly, Cris, Andrew, thanks again for taking the time with us and we’ll see you on the next Tech Tuesday.