Processes for the Process-Averse

Hi everyone. Thank you so much for joining me today. My name is Tara Manicksik, 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 a different way today, instead of showing you what my processes are and 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. Why does this work? Get a good understanding. Have the team really 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. Spoiler alert. Your process will not work the first time. 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 why these benefits are important, which is where we'll be spending most of our time, is 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 actual process, tips in what I've learned, and then how to go about iteration. 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? In our industry, most of us are developers, designers, engineers. We're problem solvers, which means we need a problem. We will find a problem to solve, which is great in our work, and sometimes, that's just how our brains work. The answer to that is to 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, 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 road map 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'd 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 for working on this certain feature, it's on the roadmap. All of these things, if anything, quick links in the DM, and then these people know, okay, I don't need to go straight into Illinois's 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 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. 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 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, 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 LeeAnne 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're 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 miscommunication is, you know, 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 the 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, you 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 cells' 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, you know, 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, you know, props to your team and showing the work that is actually being done. You know, 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's 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, you know, again, in this remote environment, for things like promotions and raises, when one of your team members' 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, you know, 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 your like, showing your 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 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 standoffs and check-in, I would get the most anxiety comparing Bill's two 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 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 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 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 you know, basically like 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, you know, is probably going to be doing about the same things so highlight what's important and, you know, 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 like a process for the project like it's good to individualize that but for the person, you know, one team member may like having, you know, a whole road map and like board in GitHub and then, you know, another one may love documenting in Slack, so find ways that your process doesn't focus just on that. You know, does it have the project information and then a resource list where you can have that GitHub board where you can have, you know, that Slack message, you know, 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 road blocks as well as communication but finding and removing road blocks for your team.

And that's where things like automation come in real handy. So Slack has great automations for, you know, 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 that every single project you want to do will always have the informed list, will always have the project name, make a template for it. You know, save keystrokes. Weekly all team check-ins, I think are extremely important to cover everything that everybody's working on. But then, you know, make it quick and broad. Then have small focused meetings when needed.

The most important thing I cannot 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, you know. 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, you know, just want to flow through all the issues on GitHub, then you track what issue they're 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, you know, tell the team and tell the company, put it out there somewhere. You know, coming down the line and having it come up somewhere else, it's just best to communicate it. And the biggest thing is, like, with your process, don't use it for blaming. Don't say, well, if you would have put that thing in the process, 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, like, project life cycles for our integrations. I know that every integration is gonna 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, like, for each project we have the template, because I know every time somebody wants to look at that project and know, like, 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 I need 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, like 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, you know, fumbled. And what was lost in Slack, how many times have you done a project and then gone through and, like, 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, you know, 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, you know, tear down the whole house to fix the hole in the wall, right? So make sure that you are really zoning, like honing in on what's wrong and what can be changed. And you know, 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, I didn't need that. Okay, take it out then. Maybe it's a month down the line. There's 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 Maniksic. 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. It's good to see that people do have favorites. So team got 64%. Processes 29%. And manager, which is us, the engineer manager there, 7%. I'm not upset, not sad at all, expected and it's good to see that they valued the team. Was this percent or this ratio what you expected or is it 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, you know, processes in place to make it most effective and to make teams be as, you know, productive as possible. And then the managers to help implement that and remove blockers and, you know, everybody definitely like you said, like, yeah, you can't have one without the other. 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, I think even explaining this to sometimes the team because you know, you get you also mention document stuff, but don't over document and struggle, battle how much you do that. And I had in my team a person who literally switched from no documentation at all, embrace the other side with full documentation on and I was like another battle. And in between. Yeah. 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 in 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 kinds 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 a nice way as possible like, oh, I see that you wanted these three things listed in GitHub, here's the board that 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 strings 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. 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 your manager and up and up. That's like, here's a way and like offer a solution. So not 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 are redundant, it means that somewhere the communication from the team up or on the work that they do was not enough or 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 ideas. 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 because he was like almost all the same process is just a little nuances that I would prefer to work on that document and making 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 their input from their side all the time. Oh, yeah. Oh, yeah.

Oh, yeah. Communication is good. 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, cause then I like it to use it as I always say this, like to point to like when I was, when a doctor point to any, whenever anybody comes and so with questions. And so then below the fold I will do things like, 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 then add as I see necessary. She's wide awake now that everybody's here. Of course you want to participate too! Cool.

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 remote 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 do a readme 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 oops, sorry, when you're just getting GitHub notifications and emails about doing something. But there's the flip side to that too, where you know, we are humans, and it's easy to error and be like, I asked you about, you know, doing this thing, like, no, you didn't. Oh, yeah, I didn't. And something sits there for a while, or put or the fact that, you know, sometimes it can become a burden, if you have to ping somebody, and it can become contentious to 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 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 it have a thing on, on Slack that would automate it being added to a notion doc.

So it still shows up in the team channel, we all get to see it and read 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 where are we with, you know, planet scale. And so you can you can double down because the 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 into redoing the thing all the time.

Thanks so much for the insights. Thank you for having me here. It was a great conversation.