Episode Twenty-Three

Sub tasks (fireside chat)

Dec 12, 2018
Also available on:

Show Notes

In this episode of Workflow, Brian and Tom talk about sub tasks, fireside chat style.

00:44   Intro (Recur 2018)
03:15    What is fireside chat?
4:08     The different types of sub tasks
08:31   How we think about sub tasks for Rindle
10:42  Use cases for sub tasks
17:36   Assigning a primary task versus a sub task
20:44  Planning with sub tasks

Useful Links

Recur 2018

Full Transcription

Brian: 00:00 This is Workflow Episode 23.

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:30 And I'm Tom.

Brian: 00:31 And we're the co-founders of Rindle and this is our podcast Workflow. Today were talking about sub tasks, fireside chat style.

Brian: 00:39 So before we roll into the main topic, Tom, what's going on with you?

Tom: 00:44 Yeah. So, you know, just getting through the Thanksgiving holidays. Everything's kind of flying by pretty quick. Next week we are heading up to Boston for Recur Boston which is a little conference up there. I think, what's it on, the 6th is the actual conference?

Brian: 01:05 I think it's the 5th through the 7th, technically. They've got some workshops on the 5th.

Tom: 01:10 Yeah. And we're just going mainly for the conference and to hang out and chat with some people.

Brian: 01:16 Yeah. It's put on by ProfitWell and it used to be called SaaSFest. So it's mostly about SaaS companies and things like that, but they renamed it to Recur as in recurring revenue, I'm assuming, as of this year.

Tom: 01:32 Cool. And you've gone the past, what, three years now? Two years?

Brian: 01:37 Yeah. The first time I went, I went by myself. Last year you and I went together because I thought it would be cool for you to go. I always found value in the talks and it's obviously specifically around our business window. So it's always good to hear outside perspective, what other companies are doing and how they're doing them, and the networking's pretty good. The first year was great. Second year wasn't so great for different reasons. But I'm giving it another chance and hopefully it will be amazing this year.

Tom: 02:07 Yeah. It looks like they've definitely shifted a couple things around. Looks like it should be good.

Brian: 02:14 There'll be some good talks. I think there'll be tons of information. It's kind of packed into one day of talks so you have a little bit of mental overload, but they send out the recording and stuff like that. So I think it's gonna be well worth it.

Tom: 02:29 Yeah. I was gonna actually say that. It is definitely an exhausting day. It starts early like 8:00 and goes straight through to like 6:00 or so, and it's packed. Should be good though.

Tom: 02:44 Before we get started, if you have any questions, topics, or team scenarios that you want us to go over, tear down, talk about, go ahead and feel free to give us a call. Our voicemail number is 860-577-2293, or you can email us at workflow@rindle.com.

Brian: 03:02 And if you like what you're hearing, certainly, tell your friends about it. Maybe even leave us a review on Apple podcasts and we'd really appreciate that. It will kind of let more people know about what we're doing here.

Tom: 03:15 Cool. So on to the main topic fireside chat style.

Brian: 03:21 Yes. We're trying something new here. Instead of I usually put together an outline, share it with you ahead of time, we chat a little bit about it. But this one I think we're just gonna do fireside chat style, meaning no outline, no pre-discussion. We're just gonna talk and see where the conversation goes. And this one is about subtasks.

Brian: 03:44 Just to set the table a little bit. Rindle has subtasks in our system. Some PM systems have them, some don't. Some have different opinions about them as far as how they should be used. And I think people in general who deal with task management and project management have opinions. So I thought it would be cool to just talk about them and see where the conversation goes.

Tom: 04:08 Awesome. Yeah. So I think the first thing that we should really outline is kind of like the types of subtasks that there are so in Rindle we actually have full on, they're full on tasks as subtasks. So you can have all properties of a task as a subtask and you can easily and quickly make it a primary task if you want or make a primary task a subtask of another task very easily and quickly. Other software, their subtasks are more just like lists that you know typical to do lists that you just check things off.

Brian: 04:47 Yeah. In some platforms. It depends on the platform really. But some of them are just like plain text, right, where it's not really a full blown task.

Tom: 04:57 Sure.

Brian: 04:58 As our system as we always say, "A task is a task is a task."

Tom: 05:02 Absolutely. Yeah. And I mean, we may be partial. I think having the subtasks as a full task is the better method because it really gives you a lot more flexibility and things that you can actually do with subtasks.

Brian: 05:17 Yeah. I think that's good to kind of understand different types of subtasks especially when it relates to PM systems. And I think generally speaking if you look at a lot of the PM systems that are out there and other task management tools, whatever it is, there's a organizational hierarchy of some sort. And I think subtasks naturally fall into that in the way that usually there's a project or like Rindle calls them, boards, then there's some kind of list structure, right? Then there's a task itself. And then usually there's something beyond that, right, whether it's saying plain text subtasks or full tasks like we have as subtasks. Or some other kind of sub-level where you can start to kind of group things beyond just the primary task.

Brian: 06:03 And I think of it mostly as another layer of organizational structure where even our subtasks allow you to go a couple levels deep if you want to even through we wouldn't recommend that. For various reasons we built our system that way. Some systems only allow you to have one level of subtasks, right. And some allow you to have subtasks within subtasks which we do. And again, when people ask us about it, we don't recommend doing that necessarily because there's a point where it gets a little crazy where it's very hard to track actually what's going on.

Brian: 06:37 But for various reasons because a task is a task in Rindle, for example, you can move those interchangeably and you can move it from one task to the other and make it primary, make it secondary, drag it into another subtask if you wanted to. So it's very flexible and for that reason we kind of had to make the levels more flexible.

Tom: 06:53 Sure. And actually as much as we probably don't recommend it for like a single project to have multiple layers, I don't know if we don't recommend it completely, I think there's benefit of going even down maybe one additional level like obviously the further you go down the more buried tasks get so it's harder to find them. But I think that because of some of the other features that we have in Rindle, you can actually have multiple levels of subtasks unintentionally and they can be very beneficial.

Brian: 07:31 Yeah. And I should clarify to because when I say, "Don't recommend it." Really my rule of thumb that I follow is three. When you get to three levels, that's when you start to be, am I doing something crazy here, right, because this actually has to happen. I think beyond two, you need to take a hard look, okay, is this temporary or is this happening because whatever reason you understand that, that's great. But if you're work flow contains more than two levels deep you're getting to three, four levels deep of subtasks, there's probably gonna be some issues, challenges.

Tom: 08:02 Yeah. And we actually talk to customers all the time for Rindle and we know people who actually do go three, four levels deep pretty often. And they just find it awesome, I guess, because if they didn't find it awesome they probably wouldn't do it. Mind you, we have gotten feedback that they would at least in Rindle they would like some more information like at the higher levels to know that there are subtasks down there.

Brian: 08:31 Well I think it's interesting just to take a step back just from the Rindle perspective because I think the reason why I think this topic is interesting is because we've talked about it so much internally but it's really driven by our own opinions but also what we learn from our customer base. I've always used subtasks in one way or another. I don't know if you have or not in your past. But at one point we're having discussions that maybe we just don't have subtasks. Maybe we just make everything a primary task because then things get buried right and blah, blah, blah. We ended up doing it anyway because we felt like, hey, we should have at least a level of subtasks. And then we started to see how people are actually using the system and I think the more customers we looked at and understood their workflow, they're actually using subtasks like crazy. And hence the feedback of saying, "Hey, actually we'd like you to do more with subtasks. We'd like more information on the subtasks base. We want blah, blah, blah." And they're using them almost like automatic. I haven't seen a single person yet that I've talked to who said that we don't use them at all in some way shape or form.

Tom: 09:40 Definitely, they probably even use them more than we do. They definitely use them more than we do. I can say that. Actually because talking to some customers who I've started to use them more at least in planning phases of projects. I'm actually using them right now two levels deep on a current task that I'm working on.

Brian: 10:01 I noticed that, actually. I was gonna ask you about that.

Tom: 10:03 Yeah. Just because it just made sense and I needed somewhere to organize my thoughts around this and it just made sense to put it underneath this primary task. They were fairly quick things like all the tasks that are gonna be done within a day or so. So yeah, I just jotted down a list of tasks. I think, and this is my opinion, but I think the further down you get, the more that they're more just like a checklist of things to do. They're just more like a reminder as opposed to higher level tasks which typically sit for longer on the board.

Brian: 10:42 Yeah. And I think actually, because I was trying to just wrap my head around like well how do people use subtasks, and I think that's also why they're a little confusing is because, and we can go over some of the ways we use them like you're starting to talk about now. And that's why I think they're represented differently

Brian: 11:00 -and different softwares because they might be meeting one need or the other. But punch lists, like you said like a simple check list, like, "Hey, these are, I gotta remember to do these four things." Right? They're not really full on tasks, they're not being assigned out to anybody else. They're really just sub-items of this task that I'm working on and I need to remember to do them. It's more like a personal check list or a check list for when we're working a task, right? Simple. And then I was thinking, "Well, beyond that," which is why we made our tasks the way we made them. Sometimes it's breaking down the work and delegating, right? So you might want to take a larger item and then create a few sub tasks and actually have different people work on those sub tasks towards a larger item, right? Hence assignments, right? Which is why we wanted, hey, we want to be able to assign sub tasks. And we want to be able to give sub task due dates. We don't want them just to be just punch lists or whatever, 'cause depending on how somebody might use them it actually helps you organize and then delegate and assign out that work, and everybody's kind of working on different things towards the same goal which is that parent task, essentially.

Tom: 12:06 Sure, which, like, I hate to just cut in there, that's actually interesting you should mention that because people have also, with creating rental, people have also asked, like, "Oh, can each person have the ability to check off like a primary task, right?" Like, we allow multiple, again, set the stage here, we allow multiple people to be assigned to tasks, is another ... some systems allow that some systems don't. But, each task can only be completed one time. So, each person doesn't have their own state when it comes to completing a task. And we've asked, we've been asked this question before, and the answer's typically, "No, you can't do that but we suggest creating a sub task." In that scenario. Creating a sub task for each person that needs to complete the item, that when they're done with it they check off that sub task. And then when everyone's sub task's complete someone can check off the primary task or you can have an automation that actually automatically does that within Rindle. But it's super flexible and it's not adding this extra layer of confusion.

Brian: 13:17 Yeah, I think there's some thoughts out there as far as, well, some systems only allow you to assign one person because they feel like, "Oh, only one person can ever do one task at a time." Through my experience which is why, partly, obviously the team's opinion, but my opinion is that I've had situations where I've actually had multiple people working on the same exact task. Not each having the same task to do, but all people, say it's two or three people, working on the same task together. Right? And maybe it didn't need to be broken down further, and it's just those three people are responsible and in the end one thing gets checked off in the end from three people kind of collaborating on it and getting it done.

Brian: 14:02 So hence the multi-assign. But, and to your point, this question gets asked a lot about sub tasks, but we actually had it today. Literally today somebody asked about this. You know, about, "Hey, I can multi-assign people," like you're saying, "but I actually want them each to check it off, right, not just one check off." So the sub tasks come in handy there.

Brian: 14:20 And I think that's really how we kind of think about it, and why we built the system the way we did 'cause I think you have both scenarios sometimes. And sometimes it's confusing. Like, "Whoa, should I assign everybody to the one task or should I actually break out sub tasks for each person?" But, the way I think about it is, if each person has to take that action then they should be sub tasks, or multiple primary tasks, right? If you want to group them under one umbrella make them sub tasks so everybody can see who's working on what and who's done it and who hasn't. So there's a lot of ways you can do it. But I think that's kind of how we approached it is that, yeah, if you're doing all the one task you can multi-assign to the same primary task, or, break them out as sub tasks, assign them out to wherever you need to.

Tom: 15:00 Awesome, yeah.

Brian: 15:01 So the other kind of use-case, I was just thinking in my head, I was like, "Well, how are people using sub task?" So, the punch list I mentioned, the breaking down work and delegating it, obviously, is really popular. Then also approvals. People actually, and I know people use in our system, I know, I've read about people using these in other systems and their work flows, but, using them for approvals. So, you have one task for, you know, design draft one review. Within that design draft one review you have to have the copy editor review it, the creative director review it, and the project manager, right? So, the project manager might ultimately be responsible for getting that process done, right? To say, "Hey, make sure everybody does what they need to do." But there's actually four steps to completing that task.

Brian: 15:48 Each person's got to approve it, sign off on it, whatever it might be, and people use a lot of the time sub tasks to mark those things off. Saying "Yep! Check. I approved it, I reviewed it." Or, "No, I have an issue and I haven't completed it yet." Right? So it's an easy way to kind of informally track approvals.

Brian: 16:06 No comment?

Tom: 16:07 No ... yeah-

Brian: 16:10 Right.

Tom: 16:10 It's just-

Brian: 16:10 I love that.

Tom: 16:12 I don't really have much to add. It's true, it is easy to check approvals in that capacity. I mean it's very flexible to track approvals, track basically anything and you can assign ... It's just smart. Because say you do have multiple people assigned to a task, and then they can feel free to add sub tasks right within that task to keep it organized of the actual delegated work between them, right?

Tom: 16:43 It just kind of makes sense, it makes organization sense, if you will. And I think that we're both of the mindset that tasks shouldn't be super super large things that are like, span for like weeks. I mean, sometimes they are. But for the most part they aren't and they're manageable and that's why I think both of us feel that, you know, sub tasks should really be only one maybe two levels deep and the further down that you get, down the rabbit hole of sub tasks, that the quick those sub tasks should be checked off. Or an approval should be checked off. Because I think that's what they're meant for, they're only meant to be viewed, really, when that item's open.

Brian: 17:36 Yeah, I mean, just actually getting back to assigning a primary tasks versus assigning a sub task, and you were saying, "Well, you know, the deeper maybe they're more punch lists or check lists." Right? But I actually I think, thinking about it within the example I just gave, you know, if you think of who's responsible, right, so if there's primary task, let's say it's a few days long task. Somebody's responsible, but, there are other people who are gonna get involved in getting some of those things done, which is common, right? That's usually the one, one single person is not the only person who's gonna get that done. Sometimes it is, but there's sometimes other players, right? Oh, I'll do that piece, yeah, you do this piece. But ultimately somebody's responsible. Whether it's a project manager, whether it's the lead, or whether it's whoever's been assigned that task, you know, it responsible.

Brian: 18:21 So I think about if I were to kind of structure it for somebody. I would say, "Well, think about the primary task as being the task owner. Who is responsible. Whether there's multiple parties working on it or not. And then if you're delegating out work beyond that, and using sub tasks, then each one of those sub tasks would be delved out, right? And assigned to whoever's working on it. Even if it's that primary owner. They might have some of the sub tasks, right, along with other people."

Brian: 18:44 But in the end, you know, that one person at the primary is ultimately responsible to make sure that all those sub tasks get done, right? And say, "Yes, this is complete."

Brian: 18:53 So I think that's a really great way to think about it, just rehashing that in my head a little bit.

Tom: 18:58 Cool, yeah. And actually, and again, we're gonna bring up Rindle a lot because we live and breath Rindle, but Rindle makes a lot of that sort of stuff. Like, when sub tasks are used in the capacity like that. Like, easier for an individual to track what work they have to do because our tasks view actually allows you to see sub tasks and it also does tell you what task they're part of, right? Very easily, very quickly.

Brian: 19:30 Yeah I think that's partly because, like, I think that's a lot of criticism that sub tasks get is that people complain all the time, "Well it gets buried. I can't really see what's going on. I forget to look in the, all the stuff that happens." So, yeah, I mean our task view, I think, specifically, and I know you fought hard for this which I think in the end was smart, was pulling the sub tasks out to top level, right? So, when we do a search result in the task view and say, "Hey I'm looking for all tasks that are assigned to me across all the boards." That's gonna pull the sub tasks no matter how many levels deep out to the top level of those results. And then we strategically, like you said, allow you to find that parent really easily. But it kind of pulls it out from being buried two or three levels deep out to the, you know, the top level so you can actually manage it and work with it.

Tom: 20:17 Yeah, and that doesn't matter what level it's at. Right. It can be three or four levels deep, if it's assigned, or even not. Even if it's just in the results you'll see it, and it'll appear there. I think just for speed purposed we only go five levels deep for search results but if people have a need I guess we can go further than that.

Brian: 20:42 Hasn't come up yet.

Tom: 20:43 No.

Brian: 20:44 Yeah and then the last thing I just had in my head too, and you brought it up even, I think you touched on it. But planning. I think that was the first thing you said. You used that word planning. And I think that's a capacity that we use sub tasks today and we're experimenting ourselves with using it, which I'd love to hear more about what you think of it, but we are actually using them a little more in a robust fashion than normal because we are potentially planning features that we're building in Rindle on a roadmap board, and we're using sub tasks to break out those user stories and features and functionality and things we're gonna built for that feature, right?

Brian: 21:21 So we might end up having ten, fifteen, sub tasks, right? Which probably would be-

Tom: 21:26 Sure.

Brian: 21:26 -in a normal task you would say maybe that task is too big. But, yes, it is too big because it's a whole feature.

Brian: 21:32 But we're using sub tasks in a planning capacity to actually break out, these are more the individual tasks are living as sub tasks, right? That we're gonna actually have to execute to complete the entire feature which may take us four weeks to do.

Brian: 21:44 So I think that's also another use of it is that people like to have that hierarchy to be able to say, "Yeah, this is a task, but here's all the stuff I need to get done." And those sub tasks naturally fall, and no matter what level you're looking at it there's always that next level of stuff that's the granular

Brian: 22:00 ... level of hey, this is actually what has to get done, whether it's a punch list on a personal level or whether it's planning a whole feature like we're doing, and planning out all the things that have to get done to complete that feature. But that's another way that we actually use it in house is with the planning and stuff. That said, 'cause I wanted to ask you what you thought 'cause we are trying a couple different things.

Tom: 22:22 Sure.

Brian: 22:23 We have these things called mirrors, which in a lot of ways plays into sub task too, 'cause you can mirror a sub task or a primary task, but a sub task as well onto another board. That actually makes sub tasks also to the point of hey, sometimes sub tasks get buried, people are concerned with that, you can actually mirror it, which creates a reflection of that task, if you will, another instance of that same exact task, and you can pull it out of there and move it through a different Workflow or a Workflow on the same board even.

Brian: 22:53 It will still remain as a sub task. When it gets checked off, it gets checked off over there. Right now, the first time we started trying these, we did all the sub tasks in the planning stage for a feature, then we mirrored each sub task out to the development board and started working on them. Then I said, "Well, maybe it would be interesting to try to keep it grouped so everybody understands hey, this is the parent feature and here's all the sub tasks." What that would look like. We mirrored out lately ... the last couple of things we've been working on ... We mirrored out the whole task. I was gonna ask what you thought of that so far.

Tom: 23:25 My personal opinion on this is ultimately I think I would like to see the individual sub tasks mirrored out. Unfortunately, until we build in an additional piece of functionality in order to make this easy to do in bulk, I don't think that that is viable. I think we're using a stopgap right now, and I think it's fine. But ultimately I think that I personally would like to see those sub tasks just on ... We have two boards. We have a roadmap board where we create the high level task and then sub tasks, and then I would like to see those sub tasks then mirrored onto the Backlog of development. So then those could be pulled over and worked on.

Brian: 24:16 The one thing ... I like that because I think that's kind of what we first tried but yeah, the bulk

Tom: 24:20 I think the main reason ... We didn't think it was a bad idea. It was getting difficult to maintain. Difficult to do.

Brian: 24:28 Yes. But I think the one thing it lacked was the idea of, and we use tags for this ... So we ended up tagging all the sub tasks that ended up mirroring onto the development board with the feature name so everybody understood that this set of tasks were for this feature. But I think what it lacked was the rolling up. So yes, it rille up on the roadmap, which is great. But it doesn't roll up on the development boards so I was thinking it could also work where we have a list that said, hey features in development right now, that had the parent task there. So you could then look at any kind of artifacts that we create. We talked about documentation just recently. Are there any Word documents or any Excel sheets or any kind of documentation for this feature as a whole?

Brian: 25:14 If you break all the sub tasks out and mirror them, there's nowhere for that central stuff to live. You'd have to go somewhere else to go find that. I was thinking it could be interesting to have that exist on the development board but still mirror them out like you're saying and have the Workflow. I think it's worth an experimentation when we get there. I was curious to see what you thought of how it was all embedded in one.

Tom: 25:38 Personally, since now we can easily see where the mirrors are, and we're working on a mechanism to also see if it is a sub task, if the parent is mirrored, you can easily see the multiple parents that it has, this task has. It's easier then to jump around so if I really am curious about that, I can just jump over to the roadmap. I think that's the ultimate, the goal there. I don't need to have just on the development board the high level view and all those artifacts 'cause if I could easily get to it, and I usually only need it once every ... once in a while, and if I can easily get to it, that's fine in my opinion.

Brian: 26:28 You're right. I think if we, within the sub tasks themselves, identify the parent, similar to how we do with mirrors today, we'll show hey this task is actually mirrored in three different places. Do you wanna go jump to that place? If we do that within the task, you're right 'cause then each sub task would actually have a reference to the parent feature and they could literally click it and jump over and go look at whatever they wanted to look at. That is interesting to think about. We'll probably add that to the list of stuff that needs to get done.

Tom: 26:56 Sure. There's a lot of stuff ... This is very appropriate for this conversation 'cause this all relates to this hierarchy of sub tasks that we have and especially with regards to mirrors, which in my opinion makes sub tasks even more powerful. The fact that you can have this organizational structure that is at different levels of the hierarchy on different boards or in different projects.

Brian: 27:21 I think it makes sub tasks way more useful and appealing actually 'cause the use case that ... I think one that we use even in developing the concept of a mirror, a task that lives in multiple places was hey, we have this meeting and we have these marketing meetings and Asia would capture these tasks and she'd create a task with all the sub tasks, all the things to do, and then they kinda got lost.

Brian: 27:47 They didn't go through the board Workflow. We're like, oh it'd be cool if that task, that sub task could live there, but also live through the Workflow so we could actually see what people are working on and where it is in the status. But we don't wanna lose the reference that it's actually a sub task from this meeting date, from this parent task. I think that in itself makes sub tasks way more appealing 'cause now it's not just always gonna be potentially underneath that primary. You can actually have it live somewhere else, have it go through another Workflow if you want it to, and it still stays there and will update and everybody's in a loop. It's auto synced. It really makes, in my opinion, sub tasks even more usable than normal.

Tom: 28:28 Sure. It's really funny because basically all the work we've been doing for the past year or so has been to get to this point. The whole theory behind it is that we want Rindle to have this roll up functionality where you can plan stuff on a board and roll it out to your team but as those tasks are completed, they basically notify where the boards which it was created on that oh, work is getting done and this is how far along we are on these various projects.

Tom: 29:06 You and I have had this conversation about this for a long time, and it really stems from the thought of why do we have to plan out a project and then recreate all the tasks multiple times? Basically as you're planning it. We're trying to avoid doing that. I really feel strongly that we're getting somewhere. It took a really long time to get somewhere with this because it's not really super straightforward and has some complexities to it. I think we're finally get there and these bells and whistles that we're adding are just to make the ease of use ... easier to use basically.

Brian: 29:52 I think two things basically happen. It's like preventing people from copying tasks. I think historically and even today when you need something to appear in two different places, you create a copy. And then they're disconnected, but you need it over there so you do that or you create a new one and they're disconnected. So that prevents that.

Brian: 30:11 And also even from a planning perspective, it's like going through the manual planning process where it's like, I gotta create all these layers and manually manage it and make sure everything's where it's supposed to be and it's a whole task in itself to keep all those thing updated and everything. With mirrors and other things that we're building in Rindle, can we do that more passively and make things just roll up automatically? It's less about having complicated structures of things, things just naturally roll up. You can just mirror things, have them live in two different places and that kinda work's automatically done for you. So that's kind of the dream. But yeah, it's a little bit of a tangent, a little off sub task but it all relates back 'cause mirroring in the same way makes sub tasks that much more useful.

Tom: 30:57 I think that about wraps us up for the day. If you have a question for us, you can call into our voicemail number at 860-577-2293 or you can email it to us at workflow@rindle.com. Our theme music is an excerpt from Thunder Rock by MagikStudio. Use under creative comments. Subscribe to us on iTunes by searching for Workflow and visit Rindle.com/workflow-podcast for a full transcript of each episode. Thanks for listening, and we'll see you next time.