In the calmer waters of late last year, the company I worked for started an initial effort to standardize how we do project management across different projects. This was less about creating rigid adamant boxes that every project should fit in, and more about finding patterns of good practices that each PM could adapt to in their projects, without losing flexibility to manage differently the things that make them unique: a starting point for processes that make sense and create actual value to the day-to-day of the operation.

As the more senior PM at the company, it was assigned to me to make a brief presentation to the more junior PMs regarding what I see as these “basic processes” that every team should follow, to avoid known problems, keep the team delivering in a good pace, and improving over time.

When working on this presentation, I concluded that, in general, you only need three things process-wise to put your team in a good direction to move forward. Let’s get to it!

A mechanism to document the source of truth

What are the roots of all evil in whatever project you’re working on with a team? Miscommunication and misunderstanding. I cannot stress this enough.

And if you don’t believe me, just think about whatever delay you faced on your team: if you start asking several “whys”, you’ll get to miscommunication and/or misunderstanding at some point. Here are some examples that happened to me in the past month:

Chatting with Mordin, a Fullstack Engineer on my team, responsible for fixing an issue we received from a security audit we did on the platform:

Hey Mordin, I just received back the second report from the audit firm, after they re-tested the platform, and it seems our fix for the JWT Authentication problem didn’t solve the issue they reported in the first place. Why is that?

Because they pointed out the problem is happening in our admin portal, and not in our marketplace, and we only addressed the problem in the marketplace.

Why?

Because we didn’t understand it was related to our admin portal.

Misunderstanding.

Chatting with Shepard, one of our Backend Engineers:

Have you met with Joker to discuss the integration that is offline because our IP got blacklisted?

Not yet, he never contacted me.

Chatting with Joker, our DevOps Engineer:

Have you talked with Shepard about the integration that is offline because our IP got blacklisted?

Not yet, he never contacted me.

Miscommunication.

Both problems could be solved if the information was clearly described in some medium everyone has access to, such as a board of tasks. You can use whatever tool you’d like for that. Jira, GitLab, ClickUp, Notion, I don’t care. But please don’t use it carelessly.

Don’t add just a title and walk away. Properly describe each task that the team needs to address. Talk about the context, what is the goal with that task, what are the subtasks, and the steps to completion. You’ll spend 5/10 more minutes now, that will save you weeks in the future, trust me.

In the first example, if a task described that the JWT Authentication problem was in the admin portal instead of the marketplace, we would have solved the problem several days before.

Even after the task is properly defined, your job — and the team’s — is not done. Decisions made regarding the tasks should be documented in the same tasks, as either comments or editions to the original description, so it’s always up-to-date regarding what needs to be done. In the last example, it could be a meeting schedule, or who was going to contact who, this sort of thing.

You’ll use it to track progress, see the cards moving around, closing tasks, sure. But that is not the complete value you take out of a board of tasks. Most of it comes from creating shared understanding and alignment across the team, a single source of truth.

Cool, but when the board will be updated with the news?

A mechanism to get updates

Ultimately, each person on a team is responsible for a set of tasks documented on a board. This means driving it to completion but also generating clarity on their status, road blockers, help needed, and so on.

In practice, as busy as our days get, sometimes not all these asynchronous updates happen and blockers are not always noted down. A cheap and easy way to remediate this is by having daily meetings.

The good-old Standup Meetings, in a remote-work world replaced by sitten-down daily calls. An interesting point to note here is that they are called Standup Meetings because, by design, it’s a fast meeting. So people stood up from their desks to talk for 5/10 min about the progress on tasks and road blockers.

Photo by Annie Spratt on Unsplash

In a remote environment, is easy to lose track of this “agile nature” and use this gathering to have discussions that could be taken elsewhere and not cost as much. Remember, even a “just 30min” call with 8 people on it costs your company 4 man-hours every single day. In a week, that is 40 man-hours spent on a discussion that sometimes is relevant only for a handful of team members, and not the entire squad.

That being said, the meeting should be straight to the point. Every person goes one round and talks about:

What you did do the previous day
What are your plans for the day
If you have any blockers

The first two are to assure the correct things are being prioritized, the last point is to solve blockers. The whole team participates so we create shared clarity of the problems and priorities for the team.

In smaller teams, this is 5/10 min tops. Bigger teams 15/20min again, tops, meaning everyone has blockers to discuss. Realistically speaking, not a situation that your project should be in. If this hits too close to home, time to evaluate other organizational points in your squad.

During the meetings, did you notice someone going off the tracks from these three topics to discuss something else that they need? Stop and think if the conversation is relevant for the whole team or if it could be solved in a meeting with a smaller audience, maybe even a 1–1 between you and the Engineer. If the answer is yes, politely interrupt your colleague, and ask him to discuss it with you after the daily is done. That’s it, you just saved your company money while keeping the team effective, yay!

Now, when a bunch of “meetings could be emails”, should we have daily synchronous meetings? Can’t we just replace them with asynchronous discussions? Well, it depends.

One thing we cannot replace with emails is the interaction with the team. When you’re building an effective team of Engineers, you don’t want mercenaries. You want a well-oiled machine where things move forward smoothly. Sometimes, these 10/15 minutes a day is all the human contact they will get with their peers the whole day, and can make a difference in their work lives and, ultimately, in talent retention for your company.

But this is not truth always, and the team will work well and is happy regardless. My suggestion is to bring the team together in this dialogue and define what works best for you and them.

A mechanism to close the loop

Alright, calling this one “one of three things” is kind of cheating, because the concept is broad and it can be extended as much as your team can afford.

Even if the concept is broad, doesn’t mean it’s not simple. Consider this: you know that your team is moving forward, coding things out, solving problems, and being great. How do we make sure we’re continuously improving? Closing the loop and getting feedback.

Here, as a PM, you can create these mini-checkpoints on the operation to improve further and extrapole the concept as far as you’d like. Below are some examples:

Do you want to make sure the codebase is growing cohesively and we’re having constant knowledge sharing among the engineers? Do peer reviews of the codebase.
Do you want to make sure the implemented feature/bug fix is working as it should? Do testing.
Do you want to review the processes define for the team and identify problems? Do Lessons Learned every once in a while.
Do you want to make sure each Engineer is moving up in their career? Do performance reviews.

Do something, stop and review it, adjust, repeat. Close the loop and get feedback. Even small improvements will make a difference in your team over time.

Defining which ones of these you should do is up to you. Identify the pain points and patterns of problems your team is having, and make sure you have something — a meeting, a ritual, a document, a focus time — in a certain frequency to go over what you tried to do to improve them and propose new things if needed.

Wrapping up

And that’s pretty much it! Some final regards:

As with everything else described in this article, as your team grows, managing it becomes trickier and more time and energy-consuming. So don’t think you won’t make mistakes or that the team members will never get an orthogonal understanding regarding the same topic, but if you follow what was described here, it will reduce these problems substantially.

Heck, I got those two examples out of several in the same month. They didn’t cause huge delays, but bumps on the road to success, and I consider myself pretty good at this stuff. The larger the team, the bigger the challenge.

And finally, you shouldn’t follow processes “just because”: this is a recipe for disaster. Understand their concept and goals, and you’ll avoid implementing something on your team that doesn’t make sense for your context, waste your time, and doesn’t get you anywhere :)