Processes for the Process-Averse

Hi everyone, thank you so much for joining me today. My name is Tara Manicksuk and I'm here to talk to you about process for the process of verse. In our industry, there are a lot of us out there, I used to be one, but now I have learned so many benefits of process and convinced many process of verse teams that I want to share that information with you in hopes of helping. So I want to go about this in kind of a different way today instead of, you know, kind of showing you what my processes are and, you know, how to convince the process of verse about them. This is the way that I talk to the team about process. So first we talk about the foundation, you know, why does this work? Get a good understanding, have the team really, you know, conceptualize and understand why we're going about this to build that foundation to then scaffold or form the process on top of that. So once they have the understanding, then I can show them the formation of how it works, like the actual logistics and what they're doing. And then finally, iteration, because spoiler alert, your process will not work the first time. I mean, it might, but it won't. But let's jump into each of these because in this way, we're not talking about specific processes because all of our processes are going to be the same from one another. But there's the keystone elements of how we deliver them, what benefits we show and like why these benefits are important, which is where we'll be spending most of our time is, you know, talking about how to build that trust by showing them how this will benefit them, the team and the company. Then we'll have little tidbits on like actual process, kind of tips and what I've learned and then how to go about iteration. So let's jump in. First foundation, explain why it works and probably the number one question in all process implementation and for good reason is why are we doing this? So you know, in our industry, most of us are, you know, developers, designers, engineers, we're problem solvers, which means we need a problem. So we will find a problem to solve, which is great in our work. And sometimes, you know, that's just how our brains work. So the answer to that is to, you know, give the researcher expected results or the reasons for why these processes will work and do great things for us and work for us. And you know, do this at the start. So it's not like they immediately jump into a project dragging their feet saying, oh, I have to fill in this information because they told me so. Instead, you know, maybe motivate and inspire them to do these processes because of how beneficial they will be. So like an example of a process, roadmap, timeline, task list, and the benefit that will benefit the individual, the team, the company is saving time. So these next few ones, we'll talk about saving time in general. And so how can a roadmap, a timeline, task list, you know, it's like they take, it takes an effort to make these, but like spend money to make money, spend time to save time. So having those things, all your ducks in a row, you know what to work on next. So as soon as you get done with one thing, one task, one project, you're able to understand instead of having to reassess the whole project, you understand what to do next and you can just keep that momentum going, which is extremely important in processes is to be able to keep that momentum and that energy going. Keep people out of your DMs. This is one of the biggest time sinks that I have seen on teams. And it's an invisible one where you think, you know, what, what's going on? Why, why hasn't there been progress on this? Oh, well, so-and-so DM me. They wanted me to explain what this thing was and blah, blah, blah. One of the biggest things I like to do is, is, you know, redirect all those DMs straight to me. But in lieu of that, you know, having a roadmap timeline task list that is basically saying, you're asking me what I'm working on now. It's listed there on the task list. You're asking me, you know, when will this be released? It's on the timeline. You're asking me if we're working on this certain feature. It's on the roadmap. All of these things, if anything, quick links in DM. And then these people know, okay, I don't need to go straight into Illinois' DMs. I know that that information is here. Saving time and saving you the stress of leadership, DMing you. Removing blockers ASAP. This one is huge. If you understand that you're going to do a GitHub action in two weeks that requires a token, you know that you can get a hold of it in the infrastructure team now. Give them, you know, that week or more to work on getting that token to you. And then when you're ready for that task, you have the information. Now that blocker just doesn't exist. Saving time. Blockers is a huge thing. Another way to clear up your roadmap is to just say no. I'm just kidding. Unless it's part of your process. Anyway, so project templates and life cycles. This is basically having some kind of, you know, a notion doc that's a template. I know every time that I have to list the lead of the project, the timeline, the phases, who should be informed. Having that in a template is a great process. A life cycle, knowing that the process for, say, a feature is that we're going to have to go through testing, we're going to have to do UI, we're going to have to then take it to staging, and then it goes to prod, and then there's a release. You know the life cycles, which gives you a predictable timeline. And then from that predictable timeline, you're able to create a cadence. So now I know that, you know, we've got this cadence, we've got this energy going, that we're aware that each member of the team can do one feature every two weeks, and this is our cadence, which then eases up external pressure, especially from leadership. If they know, oh hey, I see them releasing every two weeks, I see something come off, they can go off of my radar. I don't need to go into their DMs. I don't need to ping them all the time. You're saving time not only just by making these predictable things that we know where the information is, what we're doing next, but also just, you're also releasing that kind of pressure from your team to empower them to focus in on their work, not worry about who's saying what they're doing and how they're getting at you. Meetings. I know, probably hard to sell, right, for a process, but yes, meetings, especially in how we are remote right now. This will save time in a lot of ways. One thing we do is a weekly sync with all the different projects going on for our team. We're able to save time by avoiding double work. If Leanne has code that is cleaning up the Shopify data coming in, and it turns out Sue needs that as well, now that they know that, because they were in that weekly sync together and they can avoid that double work. Less communication. Again, trying to debug something in Slack or discuss how a flow of something should go visually in a GitHub issue, much more miscommunication can happen, but we can avoid that by having a recorded call so that that miscommunication can be avoided and we can focus on, look at the screen, see here, right here, that's what's not working, thank you, move on. And then lowering the possibility of repeating mistakes. We do this especially with retros. So in our processes, we have, as soon as the release happens in that week, we find time on the calendar for a retro meeting. We talk about what didn't work, what could possibly happen next time, and what worked well. So now we know not to do that same UI implementation the next time around. So although we're having a meeting that's taking up time, we're saving our future selves time by avoiding repeating those mistakes. So another thing that can benefit the individual, the team, and the company is exposure. So internal demos. We do this at Netlify where the whole company can come and then everybody can take turns showing off their work, whoever has something to show off. So what's great about this is you're exposing and showing your contribution to how you're making your product better. So it's giving props to your team and showing the work that is actually being done. We have these change logs and we have newsletters and updates and things about these things going out. But this way it's like to the point, you can see it working, you can see it from the creator. Which brings to the next point, which I think is extremely important, is now it is exposing that team member. So you know, they know this is Helen. This is Helen's name. This is Helen's face. This is the work that they are doing. I can see that the infrastructure change that Helen made has saved us $100,000 this week. But that's really important, especially again in this remote environment for things like promotions and raises when one of your team member's names comes to the table and they go Helen, oh yeah, I know Helen from that demo they did with that infrastructure change. Millions of dollars. Because you know, remotely we can't pass each other in the hall. We can't see Helen juggling in the break room. So this is a great way for there to be exposure. So this is another selling point for the process of something like internal demos. And another huge hurdle in remote work is we're able to showcase our work to different teams and foster cross-team collaboration. Documentation, another hot sell, but more exposure. So you're showing your work and your reasoning. People get to see that. Community opportunity. You're writing this documentation. Could it be a blog post to help people in the community? A forum post to help people who are using your product? And team player vibes again. You're showing you're invested enough in the product to write this documentation out so that if you find out there's a roller coaster testing job and you leave work the next day and never come back, you have your work here. It lives on and it helps the other team members and the company, throughout the company. So some boos. So bad reasons for creating a process. Do not create a process to keep tabs on people and give people guilt trips or comparing workloads. I love bullet points, but not in this point. When we would have stand-ups and check-in, I would just get the most anxiety comparing bills to bullet points to TED's 75. We're not here to compare. We're a team. We want to work together. And especially no process for process sake. Just because a process exists and you take over a team and the process is there, reevaluate it. Don't just say, well, this is the process that's here, so we're doing it. No one wants to hear that. And then how do we communicate these things? Be concise and topical. It's hard to listen to a very long, drowned out, hour-long meeting on why we're doing this process. So be concise. Talk about each topic of what the process is. Keep it short and sweet, but know your audience. Could this just be a bulleted Slack list explaining the process? Or is this something that you want to bring small groups of people individually to talk about? Know your audience. And then ask what questions they have. And leave a lot of venues open. DMs, notes on Notion docs, comments in GitHub. Make sure they know that there are a lot of places to ask questions, and that's good. And document, but don't over-document. I have been to project pages where there are links for seven other projects, or seven other pages describing that project, and guess what? I didn't read all of them. So again, knowing your audience, will they read the 18th Notion doc? So then once we have that foundation, show them how it works. This may be walking them through it, or basically having a meeting where you talk about what it is. But show them what it is and how it works before they have to do it. Tell them, how are we doing this, basically? So everyone is probably going to be doing about the same things, so highlight what's important, and what's optional, or things like that. So again, everyone's process will be different, but I have some yays and nays. So individualizing, not just for a process for the project, it's good to individualize that, but for the person. One team member may like having a whole roadmap and board in GitHub, and then another one may love documenting in Slack. So find ways that your process doesn't focus just on that. Because I have the project information and then a resource list where you can have that GitHub board, where you can have that Slack message pasted into a Notion doc. Think about how the individuals will work best for this. Because the main motivation for your process should be thinking about finding and removing roadblocks, as well as communication, but finding and removing roadblocks for your team. And that's where things like automation come in real handy. So Slack has great automations for putting in a shortcut that then populates a Notion doc, or integrating with GitHub. And then there's templates. I love templates. If you know every single project that you want to do, we'll always have the informed list, we'll always have the project name, make a template for it. Save keystrokes. Weekly all-team check-ins, I think are extremely important to cover everything that everybody's working on, but then make it quick and broad, then have small focused meetings when needed. The most important thing I can not emphasize more is get feedback. Feedback is so important. And people are always thinking it, so they may as well think it out loud to you, where a difference can be made. So ask for feedback. Feel free to give feedback. Just make sure feedback is happening, especially with the formation of processes. So some nays. Try your darndest not to mess with their flow, not to slow down their progress. That's what will make the process averse be process haters. If you can find ways, if they just want to flow through all the issues on GitHub, then you track what issues are on and have that highlighted. Don't get the team stuck. So if they find there's a part of your process that they just are so begrudging about and they don't want to do it, find a different way. Just don't get your team stuck if you can. And not communicating delays. So if you see that something is stuck, tell the team and tell the company, put it out there somewhere. Coming down to the line and having it come up somewhere else, it's just best to communicate it. The biggest thing is with your process, don't use it for blaming. Don't say, well, if you would have put that thing in the process, we would have not been here. Again, from process averse to process haters. So nay, nay. So some examples, just very two quick examples. So I have project life cycles for our integrations. I know that every integration is going to go through experimentation, then proposal. If it gets approved in proposal, we'll take it to Netlify Labs. And if it does well in Netlify Labs, we'll take it to GA. But I have a description of what that is to convey it, and I have the template to then do the next steps to help people, guide them through that. And then we have, for each project, we have the template. Because I know every time somebody wants to look at that project and know, what's the current status? What are they working on? When is this going to be launched? So that's right up top. And then other information we need there, like the phases, what it is, what the goals are, things like that. And who to contact, big deal. So finally, iteration, when it doesn't work. So it's like, what the heck did we do? And I know that we have to do iteration, because I've been through this many times where I think this process is really great, and it's not. And it's really hard when you put yourself and you make something that you think, oh, this is definitely going to work, this is going to do what it needs to do. And they're like, this doesn't work. And you go, I know. So just here's some tips of, revisit. Look at your documentation. So for your process, when you made the template, what parts weren't needed? What document never got looked at? What took up the most time from your team, from you? And what killed the vibe of the team? What made people say, oh, I don't want to start this new project with this template? Revisit the comms. So could that meeting have been a document? Could that meeting have been a Slack message? Think about where things fumbled. And what was lost in Slack? How many times have you done a project and then gone through and looked for the information in Slack multiple times? Should that have been a doc? Should we revisit and reiterate on this process to make sure that those get documented somewhere stable? And then who didn't need to know? This is probably a sensitive one, but maybe we didn't need to make that document public for everyone to see where we're starting with this integration, because a lot of people had a lot of things to say. Tends to happen sometimes. Along with being problem solvers, we also are opinionated people. So who didn't need to know? Maybe we could revisit that. And when you reiterate, avoid sweeping changes. You don't have to tear down the whole house to fix the hole in the wall, right? So make sure that you are really zoning, honing in on what's wrong and what can be changed. And just bit by bit, make those changes. There's no perfect time to iterate. If you see something that's bad, get rid of it right then. Maybe it's down at the end of the line when you're like, oh, we didn't need that. Okay, take it out then. Maybe it's a month down the line. No perfect time. And then communicate it. Make sure that when you make those changes, you're telling your team or you're having a meeting or you're posting it somewhere. And then communicate it again, because guess what? We don't absorb everything immediately the first time. So I really hope that some of these tips kind of will give you some ways to convince the process averse why these processes can be super beneficial to them, to their team, and their company. Thank you for your time. And I'm excited for your questions. Again, my name is Tara Manicksic. Hi! Thanks for having me. Thanks so much. Well, our pleasure. And thanks so much for taking time with the third one already arriving. I did mention before that it's coming. And in the meanwhile, it did arrive. Thanks so much for making time for joining us. Let's see the results for the question that you set up for us in Slido. And I found it really tricky, because when I first read it, I was like in my mind thinking that you can't have one without the other. But it's good to see that people do have favorites. So team got 64%. Processes, 29%. And manager, which it's us, the engineer manager there, 7%. I'm not upset, not sad at all. Expect it. And it's good to see that they valued the team. Was this percent or this ratio what you expected? Or it's surprising? I think that's spot on. I mean, it's almost like if you see it as a pie chart, it's just like, yeah, it needs all of you to make this work. And it's like the team is doing all of that work. And yeah, it's important to have processes in place to make it most effective and to make teams be as productive as possible. And then the managers to help implement that and remove roadblockers. And everybody definitely, like you said, like, yeah, you can't have one without the other. Yeah. So it's like basically all of these things need to be in place for us to just be the most productive and the best team we can be. So yeah, I agree. Yeah. Yeah. I think even explaining this to sometimes to the team, because, you know, you get you also mention document stuff, but don't over document. And oh, my gosh, yeah. A battle, how much you do that. And I had in my team a person who literally switched from no documentation at all, embraced the other side with full documentation on. And I was like, another battle in between. Yeah, yes. A balance between them all. Oh, my. Let's also go to the questions that the audience had. And I do remind everyone that we are on Discord to add questions there. And someone mentioned that in their company, it was implemented a ton of processes and a lot of them it is redundant. And the team, it is easy to pull the plug or iterate. But when it's coming from outside the team, how do you try and grind and bury it and make those kind of processes work with you? I definitely, especially when they're redundant, like the thing, the process, or I guess I should say, like how I've dealt with that before in the past is I would lump them together. And I would say, you know, in as nice a way as possible, like, oh, I see that you wanted these three things listed in GitHub. Here's the board that brings those all. Sorry, brings those all together. She was just sleeping right before this. But, you know, kind of in as nice way as possible, just say like, oh, I saw that these things all, you know, coincide with each other. And they all can be, you know, done in this certain area right here. And it's sometimes, you know, there's so much miscommunication that can happen when it trickles down where it's just like, we've had many products before where too many cooks, you know, too many people in leadership saying we need this, this, and this. And they're either similar, but not the same or completely different. And the more communication and boundaries that you can have, the better because if you're able to communicate and not just as easy as it is to, you know, in private channels be like, oh, I have to do this again. But like, and especially, you know, communicate it up to a manager, to your manager and up and up that's like, here's a way and like offer a solution. So don't only offer like up the problem and what's in the way. But if you have a solution, like that just helps them even more and lets them know that you're being a team player, and you want to work together. And this is one of your suggestions to make everybody's life easier. Yeah, yeah, I was literally thinking of that because if, if the processes overlap, overlap are redundant, it means that somewhere the communication from the team up on the work that they do was not enough, or it was just not met on the other side, maybe the team did this part, but it was just not. So that's also one thing to look up. And from a volunteer role that I had as a volunteer, I was constantly there. But the employee size keep changing. And each time the new employee was coming, they was bringing new idea. And at some point, I was just having a list of documents we already implemented. It's like, we don't need to reinvent the wheel. We already have this habit. Because it was like, almost all the same processes, just little nuances done. And I said, I would prefer to work on that document and make it more transparent, more useful for what your need is then to create everything from scratch, because working in communities would have been hard to go and bring the input from their side all the time. Oh, yeah. Oh, yeah. Communication is good. What's, yeah, we do have like a continuation on the documentation side of topic. What's your approach to documenting the process? I think it's like, how much of your process gets documented as a process? What I so like, I like to go as minimal as possible. So I like from my experience, knowing that they want to know what task you're on, when it's going to be delivered, and who's the person to contact. So I'll like start like, you know, kind of above the fold, like they say with newspapers, like, so anything above this line is just like need to know basis kind of things. So keep it as minimal as possible. So because then I like it to use it as I always say this, like to point to, like when I was one a doctor point to when any whenever anybody comes, and so with questions, and so then below the fold, I will do things like a here's a list of like, here, you can find all of our consolidated meeting notes. Here you can find what the timeline is and our complete task list that's being updated. But above the fold, just like very straight to the point minimal. And then if five people keep asking me, okay, but where's the repo? Okay, that gets added above the fold. So I just like keep it. Yes, keep it super simple and add as I see necessary. She's wide awake now that everybody's here. Of course, you want to participate too. Yes. And another question we got is it feels that sometimes automation in the processes can make people in the team detach from each other and low, lower the ownership, lose the ownership specifically during your work. And that is better to use personal communication to expand. For example, personally notify a person to do a PR review and instead of automated notification. So on the process of documenting your personal way of dealing in communication, what would you add on that? I would say read me file because it's something like that about your personal way of doing stuff. Okay, see? Yeah, I think like, the automation is extremely handy. But I definitely get the point of kind of losing that personal effect to everything that you're doing and losing. It's very hard to feel a part of a team when you're just getting GitHub notifications and emails about doing something. But there's the flip side to that too, where we are humans and it's easy to air and be like I asked you about doing this thing. No, you didn't. Oh, yeah, I didn't. And then something sits there for a while. Or the fact that sometimes it can become a burden if you have to ping somebody and it can become contentious too, even if you're just like, man, they keep being me to like, you know, check this and check this. And I know it's there. And it's really, really hard remotely to gauge, you know, attitudes and you know, how people are feeling about things. So I would almost say that those things can be separate. So you can have the automation for things like reviewing GitHub issues, or, you know, requesting a blog post review or something like that. And then, you know, it's up then to the manager to have more ways to be more social. So for instance, like we were going to automate in Slack, we kind of give updates as things progress with certain integrations or projects. So we were just going to keep that in that social channel, our like social team channel where we chat, but also have a thing on Slack that would automate it being added to a Notion doc. So it still shows up in the team channel, and we all get to see it and read it and comment on it. But it also gets automatically added to documentation. So we don't lose it. Because I can't tell you how many times I've gone back into Slack and been like, wait, what did they say? Where are we with, you know, planet scale? And so you can you can double down because that automation, you're hopefully doing it like once. And that's just being done. And then you can kind of implement the more social aspects. Oh, that's insightful. And I agree. I agree. And especially in those cases, I hope automation goes without going and redoing all the time. Thanks so much for the insights. Thank you very much. It was a great conversation. Thank you so much.