Dee and Chris chat about our latest take on Project Management (PM), a somewhat tricky topic for us with such a small team where literally everyone is an individual contributor (IC) with a lot on their shoulders aside from PM.

We’re attempting a project of large scale, so part of what has helped us so far is scoping the project into phases releases. That way work that we know is in a later release can be put off until we’re literally working on that release. Without at least that prioritization, things would take much longer. The releases are also chunked into sub-projects with a no-too-little and not-too-big quality, and within those projects is where the kan-baning happens. If we can keep the whole team on one project (or at least a group of 2-3), it limits the context switching which also helps speed and productivity.

We use Notion for most of this work, and it’s been nice to keep literally all of it (all the way up through all the phases) in one big database, then we scope the views down to phases and projects and cards. Each card we make sure has a very actionable tone to it and includes everything one might need to finish the task, including decisions, previous conversations, relevant other tickets, etc. Each card has things you might expect like who is working on it, the current status, whether it’s blocked or not, and several other useful bits of metadata. It also contains time estimates, so we can, at a glance, see how far we’ve come and what’s left on any given project. We know things like time estimates can change quite a bit, but everyone is well aware of that and isn’t beholden to the numbers. It just gives us some idea of what is going on other than feeling like we’re entirely driving blind. Each week we take a look at the progress together as a team.

Time Jumps

Sponsor: Split

This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.

Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.

Transcript

[Radio channel adjustment]

Announcer: Today, on CodePen Radio.

Chris Coyier: Hey, everybody. CodePen Radio. I've got a special guest back after just a week or two of absence from the podcast. It's Dee. How ya doin', Dee?

Dee Vazquez: Hey, Chris. Doing good. Thanks for having me.

Chris: Yeah. We talked about the API last time you were on. We're just stretching our arms, taking a little break from that. Although, I just saw in the Slack last night that we're - what is it - 70%-ish done, or something like that, from fields.

Dee: Yeah.

Chris: Pretty good.

Dee: Rachel was posting some stats. It's like, wow. And she was also like, "How do we have 1,100 fields in our ... Rails API.

Chris: [Laughter] CodePen is complicated, people.

Dee: No one knows, but it's complicated.

Chris: Then Alex is like, "I bet a big chunk of that left is settings," and that's one of the things that's on our radar right now.

Dee: He's 100% right.

Chris: Yeah. Settings are easy, so that's going to be fine. Well, nothing is easy. Right?

Dee: Yeah. Remember when we did that settings project, like the rewrite of settings, and it took us months? We thought it was going to take us weeks.

Chris: [Laughter]

Dee: That's like settings in a nutshell.

00:01:19

Chris: I saw a great tweet that somebody turned into a bronze plaque that was like the programmer's credo. It says, "We don't do these things because they are easy. We do these things because we thought they were easy."

[Laughter]

Dee: I love that. That's so good.

Chris: That's classic for us. We're like, "This will be easy. Let's just do it." Then we're like, seven months later.

Dee: No, I think we're doing it the opposite way, and we should get a bronze thing for each of our offices where, like, "This should be easy, but we're going to make it hard. That's why we're doing it."

Chris: Yeah.

Dee: That's our credo. But I like yours.

Chris: [Laughter] Right on. We talked about the API the last time you were on. Then we talked about -- I mean the time before that, it was finance. You have and still do, obviously, those things big time. Now we're going to talk about a third totally different thing that you also, in a way, head up at CodePen.

Dee: Yeah.

Chris: Which is PM. PM meaning project management. I don't know how many times we'll say that, but we might slip out PM. Not trying to hit you with weird acronyms here. That's just the normal acronym for that thing.

The reason we're talking about it is because it's not 1,000 miles different than what we've done in the past because we've talked about the app Notion many times on this show, and we are still using Notion.

Dee: We will talk about it throughout this episode every other minute.

Chris: That's the software, and kind of leaning into its features. You even read a deep dive into the Notion documentation and watched videos and stuff to make sure that you understood the feature set that we were working with.

My attitude a lot of times is just to be like, "I don't know. Just press buttons. Wing it, baby." You're like, "Maybe I'll learn."

00:03:09

Dee: Yeah. No. Not to be an advertisement for Notion, but we're going to be a bit of an advertisement for Notion in that they do such a great job with their guides aiming them at specific kind of archetypes. These are the types of users who are going to use our product. For them, it's engineering, project management, just like managers in general. And so, within their documentation, they write guides specifically for those types of users and those groups of people. They specifically write, "This is how you can use Notion if you are a product manager and need to oversee this part of your team." That's where I got a lot of these ideas.

Like you were saying, in our Rails podcast or our API podcast, you mention (in passing) that it also involves a refresh of our PMing process. Anyone who has been listening to CodePen Radio for the last couple of episodes or the last - I don't know - 10 to 20, we have been teasing this massive project we're working on. Truly, it is the largest project of CodePen's 11-year history. We can't tell you what it is. It's coming soon. But we have some product management lessons to share with you all about the project, and that's kind of a continuation of what we were talking about in the API episode.

Chris: Yeah. Yeah. We always belabor that. It's like, "Oh, sorry." At some point, we'll tell you about it. It's an evolution of CodePen itself. We've said that much - all that.

But it's so big, and we're still deep in the throws of this project, that we knew that we better as hell have some organization about what we're setting out to do so that nobody feels too lost in the woods because there were people that did feel a little lost in the woods setting this thing out. Let's make sure that everybody is on the same page, that there's stuff to do, and you help set all that up.

Notion, project management, here we go. What did we do?

00:05:17

Dee: Yeah, and we're a small team of seven people, so you hear about product management at scale or project management at scale at much larger companies. What's interesting is we're probably one small team within a massive company. That's how we function, so we're a team of seven people.

I've heard this from Alex, but basically larger companies structure their engineering teams so that there's about that number of people per team. The number of people is the number of people that you can share a large pizza with - or what have you. That's what builds CodePen, a team of people who could share maybe like one or two large pizzas with. We're seven people.

Chris: I thought Alex said he's a one-man, two-pizza team.

Dee: How does that work? I don't even know.

Chris: [Laughter] I don't know. Just joking, but yeah, that's a good point. Yeah, we're basically - I don't know. We can break into two teams, maybe.

Dee: Maybe.

Chris: At that size, yeah.

Dee: That's not always worked very well for us, but it's such a small team that what every person does is super critical an imperative to actually moving the project forward. Each person has the ability to make a massive impact or not make a massive impact. So, we're really putting a lot of thought into what we're doing and how we're doing and making sure we're catching anything that's out of scope. We're going to elongate. Our release timeline is really important, and so we started this mega-project by putting a lot of thought into how we were going to manage it, and we started with a couple of phases.

We started with a proof of concept phase, then alpha, then beta, then public release. The idea being proof of concept. We're figuring out the known, unknowns, the known knowns, and the unknown unknowns. But the goal still is to get the product into users' hands as quickly as possible.

All throughout these phases, we've done user testing at every stage. We've written scripts and had existing CodePen users walk through our designs and give us feedback. So, as a whole, we've been really good about organizing this project and trying to keep it moving forward.

The hard part is it's such a big project that it's taken a while, like all development projects do, the massively ambitious projects do. And we've needed to kind of reassess our project PMing strategy as we've gone.

More recently, we've had to refocus on shipping what we're doing and organizing it into shippable chunks, as we were to say. That's where the API work we talked about in our previous episode came from.

00:08:26

Chris: Yeah. Well, that's a good point because, from a PM perspective, there are tasks -- a lot, a lot, a lot of tasks -- that need to be done. If you don't have any phases, it's a big, sloppy mess. You can't be like, "Well, I'm going to work on polishing the landing page right now."

Dee: Mm-hmm.

Chris: It's like, "No, you're not. We're seven people. We don't even have the thing done yet. You're going to do something that is proof of concept or alpha related because those other tasks are way down the line."

Dee: A really good point. Yeah.

Chris: That's the point of these phases is chunking up the work to be phase appropriate. Right now, we're trying to just absolutely finish the alpha so that we can get into a beta. The beta is what we've decided is when we're going to invite people to see this thing. Right?

Dee: Yep.

Chris: We're not ready for that because alpha isn't done yet. Yeah, we're working on Alpha cards at the moment.

Dee: Yeah. Alpha's goal is to get what we're building onto production, so we've been working on this thing for so long. We have an internal URL. We all work on it every day. But because it's not on production, you don't have that same onus of breaking stuff. Things do break constantly because we're trying to move quickly, and it should be okay to break things at this stage. But then we find out about it because someone will mention in Slack that saving isn't working for a Pen in the new project. Then we all have to kind of jump on it.

There isn't that standard that production brings, and so part of the alpha stage right now is getting our new technology deployed, onto staging, and then onto production so that even though it's only internally available, we have that standard of putting it through the paces of our CI process so that things don't break because tests catch things breaking. That's been huge for us just across the company.

Then once it's in production and people are using it, I think there'll be a bigger onus to not break things. Then once we get into the feature flagging beta stage where we can bring users in for specific pieces of functionality, then the onus will be even greater to not break things.

The first standard is to get it onto production. That's unveiled a bunch of problems.

Chris: Probably. Yeah.

Dee: Yeah. Then, eventually, get pieces of it ready so that we can feature flag them and get them into existing CodePen users' hands so that they can tell us how does this compare to the way you use CodePen now.

Chris: You don't put it in people's hands. I think we've decided this, but it's pretty standard is that beta also means that you don't wipe the DB or anything anymore.

Dee: Exactly. Exactly.

Chris: Beta means it's stable from a data perspective.

00:11:22

Dee: With beta, that's releasing it to a chunk of, or a bunch of, users. There's no reason we can't feature flag the piece of functionality we're working on now and have three or four users use it and then wipe that data. We're not at the beta stage yet. Alpha is just like we're testing chunks of the functionality we're building. But when we do get to beta where we're releasing it whole hog to a set of beta users, then we can't wipe data.

Chris: Mm-hmm. Mm-hmm. Okay. Well, tell me more about project management. We've got the phases.

Dee: Mm-hmm.

Chris: We know we're using Notion and stuff. But what else? What other kind of setup do we need here? What's in there?

[Laughter]

Dee: Yeah. Well, like we were kind of alluding to, even with just seven people, we have a tendency to diverge to many, many projects--almost like a project per person--which can be costly from a lot of perspectives. But one is context-switching, right?

If each of us is working on a separate project, then when someone submits a PR, we then have to stop doing whatever we're doing, learn about what the other person is doing, and then go through their PR and understand what they're doing enough to be able to give thoughtful feedback or ask thoughtful questions.

Part of our project management refresh was working on the same project allows you to give deeper feedback more quickly. And it means that if we're all working in lockstep, we can get the work done more quickly. It has been and continues to be a journey to get even a small team of seven people moving in lockstep on a massive, massive project.

Chris: Yeah.

Dee: And so, what we did was we divided the core functionality that we're working on into chunks of work and created a series of projects that we'd be able to ship. Each project has a clear deliverable, and that's typically the title of the project. That comes from Gantt chart-style project management where it's like, you know, deploy project services, or crud APIs for this piece of functionality.

Those are literally the titles of some of the projects, and we always start with we have our kickoff where we've got our document. This is what the scope of work is. This is the functionality we're trying to build towards, this is out of scope specifically, and then these are the series of projects that we're going to complete.

We always start with a data design project because just getting that loaded up into everyone's brains and starting with the data model is imperative for us because then everyone understands the concepts and can keep, maintain that thread whether it's client side, backend, or deployment-related, dev ops related. We're using the same verbiage and even documentation. Right?

Chris: Mm-hmm.

Dee: We're using the same verbiage. We understand what needs to happen. With that first project, we specifically said this time around, it's like a no-code project. It's documentation, meaning, in Notion, you have your tech spec, your design specs, things like that.

Chris: Mm-hmm. Mm-hmm. Just to keep focused. It's almost because all of us are so excited to code that it's like, "Take your fingers off of the freakin keyboard, nerd." You know? Because if you jump too far ahead, then you're starting to lock in decisions, which has harmed us in the past.

Dee: Yeah.

Chris: Don't do that.

Dee: Yeah.

Chris: Get the design right first.

Dee: Yeah, and just kind of going back to that same idea of context switching and trying to stay on top of a team that's as prolific as ours is in terms of producing code, that's really hard. And so, when it's like pencils down or keyboards down, let's think about it, that gives everyone time to not also have to stay on top of all the PRs that are coming through. I think that's been really helpful for people.

00:15:55

Chris: Indeed. There are phases, and then there's a bunch of projects within the phases that you just described.

Dee: Yep. Yep.

Chris: If you have a big project, we might be able to pluck a project and be like, "You know what? We actually don't need that for alpha. That's just not--" It's something we want to work on, but we can do it during beta, so that thing gets plucked up and put into the beta phase. We don't work on it until that phase.

Alpha is a big one because it's like the whole product.

[Laughter]

Dee: Yeah.

Chris: But there are bigger ones too. During beta, we're thinking then about what the public release is going to be and that'll be a lot of documentation creation and marketing thinking and stuff. Those will be big things too.

Dee: Mm-hmm.

Chris: But obviously the product has got to be really solid and good, and that's what's helping during this alpha phase.

There's not that many of them. It's not like there is 100 projects in alpha. What was there, like ten? In the end, there'll probably be more than that, but it's not like we went super granular.

Dee: No, and we started with the core functionality that we're building. It's like, if we get this done, then everything else is kind of ancillary and cherries on top because this is basically what makes CodePen valuable now and this is our next iteration on this core chunk of functionality.

Chris: Mm-hmm.

Dee: Let's figure out what the set of projects are that we need to do to get this core functionality done. Then we can talk about what comes next. Because it's such a big project, being able to see forward in that much time in a year - or what have you - can be overwhelming. So, just being able to focus in on that core bit of functionality, and these are the projects that we need to get done in order to get this shipped, I think that's been really helpful. Each of the projects have enough work for two to three team members, and it's scoped down to feature parity and production delivery. But then there are times when the front-end team is done with their--

Right now we have two active projects, and it's basically a three-to-three split right now. Typically, a lot of the deployment and backend stuff ends up taking a lot longer, which is also the case again. We're now at a point where people are like, cool. We're pretty much done with this project. What do we do next?

Having the set of upcoming projects ensures that everyone can stay on the same path but figure out what's next just within those sets of projects, which is new to CodePen, I'd say.

Chris: Okay. And so, within those, what's in the project then? These actually manifest in Notion too, right? Interestingly, there's--

Isn't there--? Correct me if I'm wrong because I think you set all this up, or it's in conjunction. There's a super board, like a massive, single database that has all these tickets in it. Even when we move phases, even when we move projects, all this stuff, it is all on one board, ultimately.

Dee: Mm-hmm. Mm-hmm.

00:19:11

Chris: We're able to scope the views down to really specific levels if we want to and do different grouping, but it kind of behooves us to have them all on the same board for some reason, right?

Dee: Yeah.

Chris: Instead of having a database per project or a database per - I don't know.

Dee: Per phase.

Chris: Yeah.

Dee: Was what we were thinking, yeah. Initially, yeah, we had tickets we were going to put on separate databases or separate Kanban boards. But then we just weren't creating tickets in those other phases, in those other databases. We were just working off of the one Kanban. So, then we added a filter where we add a phase to each ticket so that we can categorize them and only look at that specific view.

But what I added in this refresh was creating a project, and this all comes from Notion's guides and their videos where you create a project, and so you have a project database that links to each of the tasks, so you can say this task is related to deployment. And so, within that specific project, like the deployment project, you can click in and there is another Kanban that's isolated to only the tickets related to that project. And so, that's been super helpful for not having to think about all 200 tickets at the same time.

[Laughter]

Dee: It's project-by-project, doable chunk by doable chunk so that you can kind of graduate and feel that sense of accomplishment once you've completed 20 to 30 tickets that close out that specific project and you can move on to the next one. There is this feeling of making progress in a way that's helpful, known, and takes us down the path to actually getting over the finish line. Having that project and that Kanban within a Kanban view, I think, has made a really big difference.

Chris: Yeah.

Dee: We're about to close out our third project, I believe. Then I think we have five to six more to go. But it's just that stead feeling of progress that you're making every day and every week that really helps to keep the team spirits up and to feel that sense of progress and to keep everyone motivated, I think.

Chris: Yeah, right. And so, that's part of what you do is we have all-hands on Mondays and stuff because it's all part of this big board. I don't know. Maybe you should get into what the fields are in a ticket.

Dee: Mm-hmm.

Chris: You can do cool math in Notion.

Dee: Yeah.

Chris: And be like, "Oh, look, we're 82% done."

Dee: Yes. Yes.

Chris: That's not my guess. We are, based on these tickets.

Dee: Yes.

Chris: You know?

00:22:06

Dee: Yes, exactly. No, I mean I'm not shocked that I tried to add percentages. If anyone has heard any of my other boring finance podcasts, it's kind of what I do. [Laughter]

As much as we want to be flexible and understand that software development is just historically difficult to quantify and put timing around, it really upsets great developers when you're like, "Hey, can you get this done for me in a day or two days?" Developers who are trying to build something super quality and it just takes a lot of time to dig in, it can be really frustrating to have that timeline demand.

We're trying to have the flexibility of respecting the quality of work that you're trying to product. But also, having some numbers and some quantification so that we understand where we are. I just think numbers are some of the most black and white way to understand anything.

Chris: Mm-hmm.

Dee: Whether it's a project, it's a P&L, it's a business. If you can apply numbers to something, you just have a much better understanding of what's going on - in my opinion.

Chris: Right. It's been a little hard. Obviously, it's notoriously difficult to do that, to be like, "How long exactly is this project going to take?" But we've kind of decided that's okay if it's a little wrong or whatever.

Dee: We just need the data.

Chris: It's just to keep an eye on things. It's just to have some idea of what we're up against here because if we have no idea, all this PM work is great and all, but you didn't answer the main question, which is, "Are we--?"

Dee: How close are we to shipping?

Chris: Yeah.

Dee: Yeah, and one of the attributes that I added to the Notion task board is dev estimates. This is the first time in CodePen history that anyone has had the gall to ask developers to give us estimates.

[Laughter]

Chris: It's true. Yep.

Dee: Yeah, which is probably pretty tedious. We've got people on the team who have literally, I think, worked on the Gantt chart service for Excel. I think Robert worked on it. He was like, "We were too arrogant to assume that developers would give us estimates," but that's what we're asking.

Again, I grabbed that from the Notion guide, and it's number of days. People have different days. Like Rachel is working from Australia. Her number of days and number amount of time might be different than someone else's. She works part-time, so we're like whatever a day means for you, use that.

It's not so clear cut that a day means the same thing to everyone. But at least we're using the same metric and will have consistency based on that. And so, I have two attributes like estimated dev days and then actual dev days.

Now you put an estimate in, and then update it as you go. Then once the task is marked complete, you update the total number of actual dev days. If that means you have to update the estimate, then update the estimate as well because I don't want my percentages being weirdly off.

With that data, I get to do a high-level overview during our all-hands on Mondays where I can try to answer the question of how close are we to shipping and what if anything is getting in the way. Usually, we have our customer support overview and then what each of us is working on. I think that's the agile style. Now we've added this project management section where, for every active project, I review the following metrics like percentage of time complete, percentage of tasks complete, dev estimate changes. We added ten days to this project because we figured out that this other thing was going to take more time.

The number of new tasks created, the chunks of work completed, and the chunks of work remaining. So, I aim to automate as much of this as possible thanks to Notion's databases, views, and filters. But I also scavenge the team's weekly reflection and then our GitHub notifications channel to try to pull together a high-level overview to kind of point out any time we might be off the path that we need to be on.

I am to be flexible because our priority is quality of work. But I think quantifying our work is so useful. How has it felt for you, Chris? This is probably the most different that we've ever done project management.

00:27:10

Chris: Yeah, especially with the estimates and everything. We generally call it Kanbaning, right? When I say cards in the past, I don't even know if I have that verbiage quite right, but it's just what feels right to me. They kind of look like physical cards when you have them in the Kanban view.

Dee: Yeah.

Chris: You don't have to look at it that way, but it tends to be how we do because it tends to sort them into not started yet, in progress, and completed, and stuff. That Kanban look, to me, feels like the right look for doing work. At a glance, I can be like, "Okay, what's this project? What's going on? How can I be helpful?" Boom. Right there, I can be helpful there.

Dee: Oh, that's great.

Chris: So, I go.

Dee: That's awesome.

Chris: One of my favorites is that we've really homed in on the titles of them too. Titles that just say, "Assets," that's not cool anymore. Can't do that anymore at CodePen.

Dee: [Laughter] Yeah.

Chris: It has to say--

Dee: A verb. It has to be the action that you're trying to take. Yeah.

Chris: Build script for CodePen assets - or whatever. It says something really specific like that. Then in the card, too, it has times we've talked about it, relevant PRs, past discussions, whatever. That's good stuff, so it's actionable.

Then in that card it's not too much more, but there is a little more. There's the estimates, and it's not really tagging, but I think we even have kind of a rudimentary priority system per project.

Dee: Yeah. P1, P2, P3, but we're not great about actually using it at the moment.

Chris: Yeah, not really.

Dee: I'd love to be. But yeah.

Chris: Yeah, and we've backed off some of the stuff, too. I think, at the beginning of this, we took a look at the cards and be like, "What can go?"

Dee: Yes. Yes.

Chris: From our previous system.

Dee: It's funny. The team we have is people who just absolutely despise this process but understand how important--

Chris: Not everybody.

Dee: Yeah. [Laughter] Understand how important it is. They just loath to update a card or put their work in there. It's just like, "Ah, this is going to take too much time. Can I just do the work?" But then we also have people who are just like magicians in Notion.

Chris: Hmm...

Dee: I think it's helpful for me to be the person who is going to kind of go over what's happening because then it's like a forcing function for everyone else to update their cards. At CodePen, because we're such a small team, project management is kind of the Kanban and updating cards is everyone's responsibility. There's no one.

I'm not going to go in and update your cards for you. Sometimes I will because I need my numbers to be updated every Monday.

Chris: Yeah. Sometimes it's kind of fun too.

Dee: Yeah.

Chris: Although, you don't want to take the pleasure away from someone as marking the card completed.

Dee: Exactly. Yeah, and so I'll just have meetings with people who I know their work is not being reflected on the board. And so, we'll just go in and do it together. It's been a fun process to kind of educate everyone on Notion because there is that spectrum of super Notion users and then people who are just learning it. But everyone, I think, understands the process now and we've made it a very inclusive process. During our kickoff for this series of projects, we asked everyone to identify the tasks that are going to be needed for their area of expertise.

Chris: Yeah. These tasks were made by the people. By the people for the people.

Dee: They were made by the people for the people. I love that. Yeah, exactly.

I think everyone gets it because everyone is frustrated when it feels like we're not getting anywhere and we're not shipping. Developers hate that sense of feeling like just being stuck in muck and not moving at all. And so, my hope is that this new process is helping everyone feel like we're moving forward and it's very clear what needs to be done to get to the finish line, even though the finish line is not always exact. [Laughter]

Chris: Yeah. Yeah. There's no automatic connection, but there's a connection between GitHub work, too, which I like. If you put up a PR, you could be like, "This PR is related to this card."

Dee: Yes.

Chris: Somebody reviewing it has the context of, like, why is this code being written? Oh, because it's this work that's been talked about.

Dee: Yeah, and then NPRs is also an opportunity for us to ask is this actually in scope or not.

Chris: Mm-hmm.

Dee: Maybe we're diverging, so, "Should we be doing this right now?" kind of thing.

Chris: It also answers that we know when we're in trouble is part of the beauty of this too. If you can open up this project and you don't see a clear path forward for you, that's a problem - for anybody here - because the whole point of this thing is answering that beautiful question of what should I be working on. If this thing has failed that then we've failed, and we need to stop right then and just do more of PMing.

Dee: Mm-hmm. Then we also have another input. I loved what you said for the people by the people. We have this weekly reflection that I mentioned. We have Monday all-hands. Everybody is on that call. We go through this whole process. But then on Thursdays, we submit, everyone submits their weekly reflection of what they did and what issues or blockers might have come up for them that they need help with. And so, we use that as a way to make sure that everyone has what they need to make progress. Right?

Chris: Yep. Heck yeah. I mean it's kind of the point of all this too, so lovely. Yeah, again, we have a weekly check-in, and we can be like, "Where were we last week? Where are we this week? What's planning next week?" It has that scrum feel to it. I don't know how official Kanbans are a part of scrum, but they feel tight at the hip.

Dee: There are certifications, I think. [Laughter] Maybe I should get one.

Chris: [Laughter] Maybe. I think you have enough to do at the moment.

Dee: Yeah.

Chris: Mama, you know. [Loud exhale]

Dee: Points.

Chris: So, did we do it? Is that it?

Dee: I think we did it. Yeah.

Chris: I think we did it.

Dee: That's the PMing project. I wish I could have a PMing system for my twins.

[Laughter]

Chris: At a bigger company, you could be a PM that this is all you do, in a way. I long for that someday to have these really focused roles, but we never get to get there. You have to do this. Then you have to write a bunch of code. Then you've got to go feed your babies. Then you've got to catch up with taxes or whatever. It's like, "Oh, my god."

Dee: Yeah.

Chris: One of those things is enough, I'd say.

Dee: Yeah. It's funny. With the babies, now I'm like, "Uh, it would be nice to just have one job," because when I started, I really loved the small company feel and wearing so many hats, and being able to do all of it of running a business. It can be so satisfying, and you feel like you get to make an impact. You're responsible for the whole thing, which for my personality felt great. But that was pre-twins when I had all the time in the world to devote to this. Now I'm just like, "Maybe one job would be good." But that's why it helps to have such a quantified PMing process because making it automated means that there's less to do and we're still on track, bringing it back full circle from my twins to PMing. [Laughter]

Chris: Okay. Well, thanks so much for sharing all that. Hopefully, people--

Dee: Find it useful.

Chris: Let us know if you have any questions, but yeah, indeed.

Dee: Thank you for having me.

Chris: Hope you find it useful. Take care.

Dee: Mm-hmm. Bye.

[Radio channel adjustment]