How to structure your team's work

In this episode of Workflow, Brian and Tom talk about how to structure your team's work from projects, to workflows, to personal tasks.

00:38  What's happening at Rindle (Medium has a member tier)
07:51   What types of boards or projects should I have for my team?
08:33  Department/team board
11:44   Projects (start and end)
14:32   Workflows (ongoing)
17:41:  Multi-board workflows
23:20  Personal tasks
25:07  Direct assignments in Rindle
28:15  The importance of using one system
33:39  Tips for taking action!

Brian: 00:00 This is Workflow, episode eight ...

Brian: 00:14 Workflow is the podcast that helps teams figure out the best way to work, collaborate, and get stuff done. Brought to you by Rindle.

Brian: 00:28 Hey everyone, I'm Brian.

Tom: 00:29 And I'm Tom.

Brian: 00:30 We're the co-founders of Rindle, and this is our podcast, Workflow. Today, we're talking about how to structure team's work.

Brian: 00:38 All right, Tom, so what's going on on your side?

Tom: 00:42 This past weekend, we launched “V3” of Rindle, which is a long time in the making. The launch went off pretty much without a hitch. Took a little bit longer than we thought to get all the data migrated over, but it's done now, so that is awesome.

Brian: 01:04 Woohoo. You've been talking about it even on this podcast a couple different times that we're still working on V3 and getting ready to deploy, so pretty exciting that that's out and into production.

Tom: 01:16 Yeah, and we had a couple hiccups since launch, but not too bad, I don't think. I think both of us have been pretty happy with how few actual bugs we've deployed with.

Brian: 01:29 Yeah, no, very excited about that. Pretty smooth really, so onward and upward.

Tom: 01:37 Absolutely. Cool. Yeah, and this upcoming week I'm going on vacation. I'm super excited about that. I could definitely use a little break after this mad rush to get this out the door and getting everything fixed up.

Brian: 01:50 Where are you headed?

Tom: 01:52 Just down to Delaware with family. We've gone to Cape May the past couple years. You actually joined us one of the years for a couple of days-

Brian: 02:02 The visit not to be spoken of again.

Tom: 02:04 Yes. Yup, and you're no longer invited, actually, since that-

Brian: 02:09 We've been banned-

Tom: 02:09 I'm just kidding. No, you're always invited, but since it's almost identical situation as the last, I'm glad that you will not be joining.

Brian: 02:19 Yeah just to clue everybody in, that was when two years ago, we brought our newborn daughter to Tom's family's vacation home for the week and spent the weekend, and it was completely miserable, so I don't know how old Stella was at that time. Probably only I think-

Tom: 02:36 Three weeks?

Brian: 02:38 No, was it?

Tom: 02:39 It was like really, really young.

Brian: 02:40 Yeah. We shouldn't've done that, but we did.

Tom: 02:43 Yeah.

Brian: 02:43 So ... we won't do that again.

Tom: 02:45 Yeah, but yeah, so we're ... we've gone to Cape May in the past, but now we're going just across the waterway to Rehoboth, Delaware. We got a house down there, so it should be exciting. My wife's from Delaware. I've been done there a lot, but my family actually has not been down there too much, so it should be fun.

Brian: 03:04 Cool. Yeah, so for me, I am excited about V3 as well and certainly excited to move on to some new things. I think we have some exciting features on the road map, so excited to kinda start tackling those challenges.

Brian: 03:22 But on a personal note, we did have a baby scare this week, so I do have number three on the way and had some complications. Ended up in the hospital with my wife for three days, three solid days, I guess three and a half days, so that was ... everybody is happy and healthy, which is great, everybody's home, haven't had the baby yet, so get to keep the bun in the oven, if you will, for a little longer, which is always the best case scenario, but it definitely did open my eyes to the fact that we were not ready at all for number three.

Brian: 03:55 And actually, it all happened on Sunday, and then, I was in the middle of getting furniture together and all this stuff. We were moving my daughter into a different room so the baby has a room, all these things are happening, and literally this thing happened where we had to go to the hospital, and I just, the house was a complete disaster. We're thinking we're gonna have another child on our hands in a day or two, and that brought a lot of anxiety on, so I was panicking and trying to run back and get all that stuff organized, and at least get some sanity as far as just bringing another child back home and all this stuff, and in the end, ended up being where we didn't have the baby, but I guess it was a false alarm that had some good results as we got a lot of stuff done in a short period of time. [crosstalk 00:04:40]

Tom: 04:40 Yeah, babies'll do that to you.

Brian: 04:41 Yeah, whenever think you're prepared, you're really not, so it definitely opened my eyes, and this weekend I'll be cranking out a lot of the extra little things I need to get done, and I just want to be kind of super prepared for when the baby does come, so-

Tom: 04:57 Yeah, I mean, that's basically been every childbirth that me and my wife had, so where it's just rush, rush, rush because both of our children were premature, and you know, there's no planning when these things are gonna happen.

Brian: 05:12 Yeah, I think I took it for granted because both of our previous children were full term, and we just kind of assumed that, “Hey! We're gonna probably carry this one full term; won't have any issues,” and of course, when you start relaxing and thinking that way, the opposite happens, so-

Tom: 05:27 Absolutely.

Brian: 05:27 But, who knows. Might still carry full term, but yeah, you never ... no matter how prepared you think you are, especially for children, you're never really ready, you just kind of wing it.

Tom: 05:36 Absolutely. Yeah. That's the one thing you learn.

Brian: 05:39 Yeah. The other thing that I want to just point out for anybody listening and can chime in and maybe confirm this, but I am using a new mic as of episode seven.

Brian: 05:49 It was actually the original mic that I wanted to use or thought that I would use from some recommendations from others and some other podcast folks, so I tried that and then Tom was using his own headset, and we got some good feedback that his voice sounded really good, so I ended up getting his mic and trying that one, but then, when I was playing back these episodes, I noticed, “Hey, my voice actually sounded better with my original headset,” which I only recorded episode two with, and then recorded all the other ones with the new mic.

Brian: 06:20 As of episode seven, I've been using this new mic, you know my original mic, so I think, even with editing and all that stuff, hearing the playback and stuff, it sounds better, it sounds like I'm less far away, so lookin’ for some confirmation, if that's the case.

Tom: 06:35 So maybe it's not actually the mic, maybe it's actually just my voice.

Brian: 06:38 Your voice might just be that stellar for podcasting.

Tom: 06:42 There you go.

Brian: 06:42 Maybe you missed your calling. Maybe you should've been a radio host or something.

Tom: 06:46 Yeah, maybe that's it.

Brian: 06:49 Anyway. Cool. Before we get started, just again, if you have questions, topics, or team scenarios you want us to tear down, you can call our voicemail number. It's 860-577- 2293, or email us at workflow@rindle.com.

Tom: 07:06 Also, if you want, please leave us a review. It really keeps us motivated, and helps to reach more people. However the algorithm works, if you get more comments, you seem to then show up on more people's feeds in order to potentially have them listen to you.

Brian: 07:24 Awesome. Cool, so let's get into the main topic.

Brian: 07:28 So we get this question a lot, like when we talk to our customers, and potential customers, and things like that. What types of boards, in Rindle we call them boards, they're basically projects or a structural entity, however you might organize yourself. Some systems have actually called them projects, we call them boards, so we're gonna reference them as boards throughout, and I think we've even done this in previous episodes.

Brian: 07:51 We get this question a lot: What types of boards or projects should I have for my team? I think, Tom and I even in previously discussing this we've kind of like well, “Oh that's kind of straightforward,” but actually it's not. ‘Cause when you're looking at a blank canvas, especially when you're starting to use a new PM system or something like that, it's a little intimidating, and you might not know where to start, or exactly what to set up, or things like that.

Brian: 08:15 I think it was a great topic to kinda dive into a little bit and go over the different kind of boards or structure that you can have for your team and why. It would hopefully give a great outline to wrap your head around, “Okay, well yeah, that's a good idea, we do actually have these different scenarios going on, and maybe we should do x, y, and z.”

Tom: 08:33 I think we have basically broken this down into different categories of different types of projects/boards, so the first one is really the department/team board?

Brian: 08:46 Yeah. I think this one gets overlooked quite a bit, actually, and a lot of people who have projects going on don't think to necessarily think to have a board or project for their team, and these are more for internal projects and things like that, that you actually can manage that ... especially if you have client work going on, like when you have client deliverables, like, Tom, you and I had in the agency world, the department stuff seems to be kind of second rate or not as important, so you don't think to really keep yourself organized that much because the client work is top priority for everybody.

Brian: 09:22 But yeah, any internal projects, or things that are going on amongst your team can be tracked in its own dedicated folder.

Tom: 09:30 Sure. So that's for both teams and also department heads and basically any group within your organization, is that right?

Brian: 09:41 Yeah. Absolutely, and I think it will ... it's a great place not only just to track project work, so you might have multiple projects going on internally, or maybe even you as a manager you're delegating tasks out to your team, it's just a place to keep all of the team-based things organized. And again, we'll get into this as we talk, but sometimes bigger projects might be broken out into its own board and all those things, but generally, you can keep your internal projects managed with a task and a couple sub-tasks and have kind of a big view of all the projects that are going on internally for your department in one place. Who's working on ‘em and things like that, and give your team a place to collaborate around those things that's kind of separate from all the other things you have going on and all the other deliverables that are happening.

Tom: 10:28 Sure. Yeah, and I think very often, we have a couple boards like this, and very often we will end up having created a whole bunch of tasks that are related and then another board basically naturally forms from that board because we have a whole bunch of tasks that are similar, so then you can easily transition those into its own board.

Brian: 10:55 Yeah. Absolutely. I always had trouble finding a home for things. We'd have a meeting every week with our team, and I would give out tasks. I'd be given tasks. We're talking about lots of different things during that meeting, and because we were so focused on a client work that client work always had a home, right? But we struggled to sometimes find a home to track the other work.

Brian: 11:16 So delegation, I think, and tracking the internal teamwork is actually something that usually falls by the wayside. It's kind of like, “Oh, I'll remember to do that,” or, “Yeah, yeah, shoot me an email,” but we don't think to actually but it in a home, so whether it naturally happens, like you're saying, and kind of just falls into its own board, or you purposely implement it just so you have that place, even if it's not active all the time, but when you need it, it's there, and the tasks have a home.

Tom: 11:44 The next type of board that we create is our project boards, and those are typically projects that have start and end dates, fixed period projects, if you will, so in the ... back again when we worked at an agency a lot of these would be client projects and one off projects not ongoing, long-term projects.

Brian: 12:13 Yeah, so even compared to the department board we just talked about, the department board is gonna be there forever, right. Your department will ... even if you leave that company or some of your teammates leave that company, that team board will probably be there always. You'll be tracking internal projects and things like that through tasks on that one board.

Tom: 12:29 Mm-hmm (affirmative).

Brian: 12:30 It doesn't really have a start and end date where a project has a dedicated start and end date, it's structured, it will cycle through. I think the best example of that are client projects or any kind of client deliverable you're doing, like some software companies have onboarding projects where they have ... it's a six-week-process and they onboard the customer onto the platform, or whatever they're doing, or it's an agency where they're doing a creative project and they're designing a logo. That has a beginning and an end, and if we're do more work for that customer, usually there'll be another project, right? It could be six months from now. It could be three-

Brian: 13:00 Usually, there'll be another project, right. Could be six months from now, could be three months from now, could be a year. So, I think that's a real good way to define kind of another use case for a board of those kind of one-off projects, or things that will have a start and end and will cycle through.

Tom: 13:14 It is also pretty important to try to keep boards smaller and more contained to specific things so they are more or less done at some point.

Brian: 13:26 Yeah. What you're trying to say is that if you kind of keep one board living and breathing, kind of adding on multiple projects in one area, potentially, and kind of having that last forever, or last longer than it should, depending on the volume and the size of the projects, it might make sent to ... If you get another project with that customer, it's a new board, right. You're not tacking that new project into the same board and now you have two projects running in the same board, right. Therefore, when you're done with the first project, that will kind of go away and you're still working on the second project and you're kind of kept in a nice, neat entity that can have an end, as opposed to it just bleeding on and on and on, and nobody kind of knows where anything is.

Tom: 14:07 Yeah, and back when we worked at the agency, we really, basically, would wrap up the major project, if you will, and then we would typically create a maintenance type project if we had additional maintenance type work to do on that. So, that way, the project itself was wrapped up, but you had this other project that you could then attest to that needed to be done.

Brian: 14:32 So, the next type of board would really be use in a workflow type scenario. These could be single boards, I think, which we've even already touched on with that maintenance board you just talked about, Tom. Or, it could be a multi board workflow. So, single board workflows could be ... We brought this up in previous podcast episodes too, but even our own blog board that we used to track the workflow of managing blog post creation, that board is not a project, it doesn't have a start and end date, but it does have a workflow that will kind of be a production workflow for all blog posts.

Brian: 15:10 It will be living and breathing over a long period of time. The podcast board that we've talked about as well is another example of that, where that's a living and breathing board. We're managing the workflow of the process of getting those podcasts produced, and even a maintenance board that you talked about that, when you kind of were done with the client project, you'd have this kind of workflow of managing bug tracking or issues, right, or whatever that might be that's kind of an ongoing living, breathing, maybe spanning multiple projects that have been completed, but it's for the customer, and you're kind of having that living, breathing board there to manage that workflow for tracking issues and other things that need to be taken care of.

Tom: 15:49 I think that people probably are going to question, well, why would a board be a workflow versus just a one-off board? I think what it really comes down to is whether or not the tasks are all the same, more or less. So, for the blog board, all of the tasks are very similar in structure. They were writing a blog post about this, and it goes through the workflow that we have set up. Same thing for the podcast board, right. These boards don't have one-off tasks that are not really related to that workflow.

Brian: 16:26 Yeah. Yeah, I think a lot of people, even myself, would think well, okay, you just talked about department boards, and marketing would be a good example of a department board. Wouldn't the blogs and the podcasts all just go on the marketing board? I think that's where you start to see what you're starting to talk about. You see similarities in certain types of work and you see a volume of certain types of work. So, a good rule of thumb I use, once I get over 10 sub tasks, I start to consider, well, should this be its own board? So, for example, if we had a marketing board ... Which we do. We have a marketing board that covers general marketing projects and things to do. Then we have separated out the blog post board, as we mentioned.

Brian: 17:08 But if I didn't have that blog post board, I would probably have a task, maybe, possibly, on the marketing board that had ... That covered blog posts. And there would be a bunch of sub tasks for all the blog posts we're going to do. That would definitely, in our scenario, go well over 10. So, at that point, it's kind of like, well, that's why we broke it out to be its own board, so now we can actually manage all the blog posts through its own unique workflow and have a certain volume that's manageable on a board, as opposed to trying to cram it all into the marketing board, which will eventually get overwhelming and confusing.

Tom: 17:41 That's when you end up turning it into a multi board workflow, when it potentially can get overwhelming and confusing. I think a good example that we have for that within the Rindle structure is actually our feedback loop, if you will. So, we get feedback from customers, it goes on to the road map if we decide that we have had enough feedback about a similar feature, which then, potentially, moves on to the development board when we're ready to start working on it, and then after that's done, there's a bugs board for that particular feature.

Brian: 18:22 So, whole product management side of the business, and I think to your point, imagine having all of that stuff on one giant board. I think a lot of times, when you notice that there's a problem is when you start having lists for things that are not steps for workflow, right. Imagine if we had all these things on one board. Feedback would probably be its own list. So, we'd have a list on this product board called Rindle or something, and the first list would be feedback, and then the next list ... Well, here's all the things for our roadmap, and then next list would be here's all the stuff we're working on right now. There's nothing working through a workflow. It's all sitting stagnant, just being organized into containers, and when that happens, typically, you can break those containers out into their own boards, which we did. So, we have a feedback board, and then within that board, you actually have a workflow of how we actually flow that feedback through that process so we can see the status of different pieces of feedback, where they're at, before it gets to the next step, which is roadmap, which has its own workflow. So, it really becomes a multi board, multi step workflow, and then there's processes within each step of that big workflow.

Tom: 19:35 I also just think it's important to note that in certain scenarios, it is literally a task that's moving ... One single task that's moving through these multiple boards in their distinct workflows, but at certain points ... Say it hits the development board, you might break that one task down into multiple, more granular tasks. So, there's kind of a mix of both single tasks, and a single task then becoming multiple tasks at a certain point in that workflow.

Brian: 20:10 Yeah. I think a really good example of what you just said is our feedback board, actually, because on the feedback board, we actually track feedback from customers who cancel trials, for example. So, they cancel the trial, we collect feedback as to why, so we can say is it missing a feature? Are they not just happy with the experience? Whatever that scenario might be, that may never become an actual task. It may not ever become something we develop or anything like that, but we are tracking that because it is feedback. So, that belongs on the feedback board. We are also tracking, on that same board, feedback for feature requests from our customers. We get feature requests all the time via our chat widget and email and all these things, and we track them. We're really diligent about this.

Brian: 20:52 We track them, and we tag them and organize them. Those, certainly may, one day ... We say, "Oh yep, we are going to do this feature. This has been requested by 10 different customers. This is great. We're going to move this forward." That task will actually be moved, essentially, to roadmap and be planned to actually be developed. So, that's a good scenario of a task moving from feedback to roadmap, eventually to development, blah, blah, blah, where the feedback from the trial cancellation will probably never move up that board, which is fine, and it's still being organized as feedback. So, you might have different scenarios, depending on the different type of tasks and things you're managing.

Tom: 21:31 Yeah, I think, really, it comes down to that we're just trying to turn a whole bunch of data that we have into something more manageable, right, throughout our process, which, that's ultimately what everyone who's attempting to get more organized is trying to do, turn a bunch of various ... A bunch of noise, if you will, into something manageable.

Brian: 21:56 Yeah, I think that's a mistake a lot of people make, is they try to fit everything into one place. So, our department is a really good example like that, if you have a marketing department. Okay, let's just put all of our marketing stuff on that board or project. I think that's where it gets overwhelming really quickly, and then people get frustrated and they start not using the software tools or whatever you're using to manage that instead of creating an environment that's really easy to manage. It's back to your point about how many tasks does it really make sense to manage in one place.

Brian: 22:27 When you get to hundreds of tasks in one area, at some point, it becomes unmanageable and ... You can't process the amount of data that's on that board, at some point. It's different if you're storing it and you're just going to reference it periodically and prioritize. But if you're really working on a board, it's really tough to manage a large amount of data in one place. So, breaking it out into functional areas like we did in this example, it just keeps everybody's sanity. So, when we're working on development stuff that we're actually coding and developing for the product, we're not clouding our vision with feedback and roadmap items and bugs and all this craziness, because right now, we're focusing on building a feature. So, it just clears everything up, clears the air, lets everybody focus on kind of the task at hand and not have to sift through a bunch of data every time they go to do some work.

Tom: 23:20 I think the last type of boards or singular board, if you will, are the personal task boards.

Brian: 23:29 Yeah, I'm pretty passionate about this. I think this is something that gets forgotten in a lot of ways, especially when you're talking about managing teamwork as a whole. Obviously, managing client projects are really important, and managing your team's projects and all these things are usually top of the list, but personal tasks really don't get covered that much, and when we say personal tasks, just to further define it, it's a personal task related to work. So, we're not talking about stuff at home, or grocery list items, or stuff you're going to do on the weekend. This has to do with your personal task list related to work.

Brian: 24:03 So, there are always a set of work or tasks that you have to do that fall outside of the project work, the workflows that you're working on. Whatever it is you're doing at work that only you care about, are only assigned to you, and you're not really collaborating with anybody else on those. I think a lot of times, people typically manage these in all different ways. Everybody has their own unique way, some people use a note pad, some people will use their email, some people will use a piece of software, a random piece of software, even one that's not even used at the business.

Brian: 24:36 So, you have this automatic separation that happens. I think it's a big issue, only because as a team, or as a company, we're striving to have data in the same place and understanding work loads and what people are doing, and each employee and team member to understand what's on their plate. I think it's really hard to do that when you're always looking at just a subset of the work that's on your plate, because usually, the personal tasks end up outside of that realm.

Tom: 25:07 That actually is why we did create something called direct assignments within Rindle, because sometimes, I know that there's tasks that you have to do, Brian, and I can just create it on wherever. It doesn't really matter where I create it. It actually just directly assigned you. I don't have to worry about you being on the board that I created it on. You can get that task, and then I can be like oh, hey, Brian, finish that task that I had assigned him when you ultimately do finish it.

Brian: 25:39 Yeah, I think it's a great deterrent from a typical scenario, which is hey, I need time to do this. It really doesn't fit into a project. We don't really have a place that's organizing all this stuff, because it's kind of a one-off. So, right now, I think a lot of people defer to email and slack, stuff like that.

Tom: 25:55 Or slack, yeah.

Brian: 25:57 Really, this allows to actually assign a task, like you're saying, directly, not having to create a project or board, and ...

Brian: 26:00 ... Like you're saying directly, not having that creative project or board and share it, and all these steps. That's kind of a one-off thing that nobody wants to do, and it allows you as a delegator to track it as well. Right? Hey, did they complete it? Did they not? Do you even need to collaborate on that one signal one-off task? It gives you that context as well and place to organize it.

Brian: 26:18 But, I think just getting back to the personal task list to, it's important I think from a team perspective to make sure generally people are managing their personal tasks. One, are they actually keeping track of them. A lot of people just keep track of them in their head. To promote using a personal task list. I know I like having my personal ... I have a personal My Task Board that I use to manage my one-offs that nobody really cares about.

Brian: 26:43 Tom, I don't know what you do for your personal list.

Tom: 26:48 I have to admit that I do write things down on paper a lot, mainly because I am staring at a computer monitor a lot, and this actually allows me to put my eye down at a piece of paper for a period of time. I just prefer that.

Tom: 27:05 I do put things in Rindle that are longer term things that usually the things that I'll write down on a piece of paper are the things that I know that I'll be getting done within the next couple of hours, within that day, but if it's something that's a longer term thing, I will put it down in Rindle on a My Tasks Board.

Brian: 27:23 Yeah. I do the same thing actually. I have a notepad that I have a punch list for the day, because if I'm going to do it like you said in the next hour or two hours, it's really not worth the effort to get it into the system and take the time to do that. If it is longer term, I do the same thing. I get it into Rindle, because that's when I drop the task generally.

Brian: 27:44 I do follow the two-minute rule, which is from "Getting Things Done", and I think it's probably in other productivity methodologies out there, but if I get an email or something and I could do it in two minutes or somebody asked me to do something and I could do it in two minutes, I do it. I don't even write it down. I don't put it in Rindle. I don't even scratch down. I just literally do it, and never write it down or document it just because I can get it done so quickly, and it avoids having to track a bunch of stuff that is really just minimal effort.

Brian: 28:12 So that's kind of what I do.

Tom: 28:14 Make sense.

Brian: 28:15 I think this is interesting to talk about with your team, too. Like how are people tracking their work. I think it comes down to general statement of the importance of using one system across your entire team/ company. I think that's just a general thing that, I think, is coming back around. It's really interesting what software development, too, like back in the day there was huge systems that kind of built everything that you needed into one platform, and it was a big, huge, bloated platform, but it had everything.

Brian: 28:45 We used something at our agency, Tom, that had project management, accounting, you name it, it had it in that platform. It was just crazy, but, unfortunately, it wasn't really great at everything.

Tom: 28:59 No. It was not simple to use by any means.

Brian: 29:04 Yeah, and then a trend happened where software started coming out that web-based that were really good at one thing.

Tom: 29:11 Micro-services if you will.

Brian: 29:12 Yeah. Then people were like, "That's really easy to use. I really liked that for this, so let's use this, and then we'll use this tool for that, and then ..." Right? So now we have this situation where we're seeing lots of people using different tool sets, but, I think, as far as task management/project management, the importance of using one system across your team is important whether it be from personal tasks to department boards and projects to client projects and various workflows you have going on, to keep all data in one place.

Brian: 29:42 Therefore, fully understanding workloads and what's actually going on. When data is not in the same place, it really doesn't give you the full picture, and I think that's what a lot of people struggle with, in general. "I'm having a really hard time understanding what my team is working on." Well, probably because you have three different systems floating around, some you might not even know about, and all the information actually isn't in one place. In my opinion it helps keeps things generally more organized, easier accessed to what's actually on everybody's plate from a management perspective and an individual perspective and provides ability to share and collaborate a lot easier. If you're all in the same platform, it makes sharing and all of those things much easier, especially with remote teams in all of those things.

Tom: 30:25 Sure. I'm just jumping back to what you had said previously about trying to avoid putting those one-off tasks or sending those one-off tasks that people have to do through email or through slack, it's not also, though, we don't use those things. We actually do. We'll talk about "Oh, did you happen to do this? Yes, no, whatever," in Slack, and then you'll be like, "Oh, I'll create a task for that." That really, really works. We still do use those instinct communication platforms all the time, but when there's an actual task that needs to be done, we put it in Rindle.

Brian: 31:02 Yeah, absolutely. I think to that point, too, I've seen where, especially as your company gets larger or businesses get larger and you have multiple departments and all of those things, you have different departments using different tools. Even sometimes within the same department, you have multiple teams using different tools. As you know it's not a perfect world where people will switch teams, and move from team to another, or have to work on a different project or something with somebody else.

Brian: 31:29 There's all these tools floating around. The disconnection of data is absolutely crazy, not only between Slack, which is really has its own purpose, compared to Rindle, which has its purpose. Right? But now we're talking multiple PM platforms within the same department. Right?

Tom: 31:45 Sure.

Brian: 31:45 When you go move from this team to X team for two weeks, because they need help with something, you're literally uprooting from one system and tracking in another system. There's just a huge disconnect that happens. Just food for thought in general, but moving to the same platform for one purpose is definitely key.

Tom: 32:05 I actually think it gets even worse when you take into account not just project management software, but also task management software, because people are always like, "Hey, I use To Do Lists or OneList for my task management," and the line between what's a task management software and a project management software is really a thin line, if you will. I personally don't think that you should basically allow people to use task management softwares if you are using a project management software at a company. Right? Ultimately, it serves the same purpose. If it's an easy-to-use platform, they should easily be able to manage tasks within it.

Brian: 32:47 Yeah, agreed. If you're going to use To Do List or OneList or things like that, really that's a personal ... I use certain things, like I use Apple Notes actually at home now, like for my grocery lists and stuff. That's not related to Rindle stuff.

Tom: 33:00 Sure.

Brian: 33:01 Obviously, to each their own at home, but, yeah, I agree. I think that it causes problems in the long run. Honestly, people shouldn't be putting work information into personal accounts of random softwares regardless. It's just not great practice. That's when disconnects happen, and you have multiple ... It's just app fatigue. You're now ... each person has to manage different things. It just doesn't make much sense.

Brian: 33:25 If it were me, I would actually push my team to be like, "Everything should be in here." If you have one-offs, you should figure out to track them in whatever system you're using and get everything into one system so you have a complete view of things.

Tom: 33:39 All right, so let's get to the tips for taking action.

Brian: 33:42 The first tip is do an internal audit of where all your work for your team is being tracked today. I think it will be eye opening. You probably don't realize that there potentially are different tools being used, sometimes for the same function, but even for that personal use case we were talking about where people are using other tools to track their one-offs and personal tasks, but do an audit and figure out all the tools people are actually using today, and see if that makes sense. Can you consolidate it? Can you have one platform cover a couple of bases for everybody? I think it will streamline communication in general, and keep things .. A lot of time is wasted just jumping in between apps and tracking things down, so I think it would just generally streamline communication for your team.

Tom: 34:25 I think that would be pretty eye opening. Cool. Another tip for taking action is don't be afraid to create a lot of different types of boards and try out a lot of different things. I would start off with fewer boards just to start or fewer projects, if you will, to start, and expand, grow naturally.

Tom: 34:49 Again, the whole reason why we basically are talking about this is because we get asked a lot, "What types of projects or what structure should I make for my team?" I don't think you should be worried about messing it up, picking the wrong structure, because if the software is designed well, you should be able to fairly easily change that structure. Right? As you more clearly understand how to use the software and how your workflow is working.

Brian: 35:20 These are great guidelines that we gave you today, just examples of "Hey, these are the different types of boards/projects that you can have, and the reasons why." Really you should apply them and experiment to see what's the best fit for you.

Tom: 35:34 I agree. Don't be afraid to some things out, and, hey, maybe this should be its own board. "Great! Let's try it, and if not, maybe we should consolidate these two and make it one." Right? And we do that all the time.

Brian: 35:45 All the time.

Brian: 35:46 It's absolutely acceptable. I think you have to be able to iterate. I think that's ... we're big fans of that. Everything we do we want to be able to iterate workflows within boards, board structures themselves. How should we process this information? What's best for the team? Sometimes we make a decision and start doing it one way, then we change and say no, let's try it this way. You're right, Tom, it should be fairly easy to do that. It shouldn't take days or weeks or anything like that. It should take minutes. Right? Be like, "Okay, let's ship this stuff over, and let's try this for a couple of weeks and see how it flows."

Tom: 36:17 Well, I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 860-577-2293 or you can email it to us at workflow@rindle.com

Tom: 36:29 Our theme music is an excerpt from "Thunder Rock" by Magic Studio used under creative comments.

Tom: 36:34 Subscribe to us on iTunes by searching for "workflow" and visit Rindle.com/workflow-podcast for a full transcript of each episode.

Tom: 36:42 Thanks for listening, and we'll see you next time.