Skip to main content

Working with Adam as a PM

ยท 6 min read
Adam Kecskes
Operations and Engineering Manager

I wrote this originally a few years ago for teams whose members were new to each other; these suggestions acted as a guide to understanding my perspectives. I know that everyone has different points of view on how to run a project. By making myself the locus of attention, the idea was that the team could debate with me about the details and we could come to a consensus that worked for everyone.

Preamble aside, let's read on!

The TL;DRโ€‹

  • My style: "Continuous and automatic communication."
  • My style addendum: "We don't blame, we solve."
  • Comm priorities: @mention people rather than in general Slack (or other instant messaging); use general Slack rather than email; email only for formal occasions.
  • Tasks are smart objects โ€” describe, organize, link, attach, comment, add details as needed. Create meaningful context for others. Empty tasks are unloved tasks.
  • Keep transparency going by taking your thoughts out of your head and putting them into tasks, comments, and documentation. Then, @ specific people or everyone as needed.
  • Communicate early and often, perfect later. Plan the work; work the plan.
  • I'd rather know your concerns sooner rather than later.
  • Be secure, be safe, work smart, eat a banana ๐ŸŒ or an apple ๐Ÿ on occasion.

The Quickโ€‹

I have a particular way of managing projects that has served me well with past clients, both small and large. This is an attempt to summarize. For more details, go to the section below titled "The Long."

The essence of my style is: "continuous and automatic communication." This is a team effort. For me to be the single source of communication between clients, contractors, and employees would be mind-numbing (and I have seen plenty a PM go crazy trying to be that person).

How I do this is usually through so-called "work-management" tools like Jira, Monday, and ClickUp. I leverage three aspects:

  • "@"-ing people
  • Smart tasks
  • Links

These aspects assume that the team is responsible and willing to follow up promptly. It does not mean "instantaneous" communication. This system is inherently asynchronous.

"@"-ing peopleโ€‹

Have a question that pertains to a specific task? Don't Slack/Discord/Email โ€” rather, @ the person that needs to be queried. Were you the target? Answer inside of the related task or thread. In doing so, both of you maintain context for other people who touch that task in the future.

Corollary: If needed, re-assign the task to the appropriate person. If it's not your job, it's not your job; that's okay. But don't abandon the task. Make sure someone takes care of it.

What is the difference between communication styles? Slack and Discord (or phone and video calls) are useful for airing out your thoughts and concerns โ€” dynamic communication.

@s, on the other hand, are useful for getting people's attention without intruding on their workflow, plus adding to the context of the issue for others to see.

Email is just right out. We will only be using it for formal communications, and not for day-to-day efforts. I've shared my thoughts on email on LinkedIn, so I'm not going to share them here: https://www.linkedin.com/pulse/e-mail-killing-your-business-adam-kecskes/.

Smart tasksโ€‹

Tasks are not simply to-do list items. They are objects that have context and details. It is critical that developers and stakeholders alike add details that are appropriate and meaningful. Not perfect, but sufficient.

Add attachments, make comments, create checklists, and link, link, link. Do not be afraid to create another task if necessary. The whole purpose is to get details out of our heads and into the system for everyone to see.

An empty task is an unloved task (and not helpful to you or your teammates)

If you are a developer keep these ideas in mind: Tasks are objects with specialized callback (communication) methods. You need to provide a data payload to make it work.

And always follow the Git axiom of:

Commit early and often, perfect later, publish once.

The same philosophy applies here as well.

Links create context. Links improve findability. Links boost connectivity. Links help others help you.

You may have noticed I talk a lot about context. What will make our work easier is providing context so that other people can read, assimilate, question, and eventually understand. Sometimes that is best-done face-to-face, over a call, or on Slack (but not in email; never in email!). Quite often, context is created by the links you add to a task or document.

Link so other people can learn your thought process and the events that led to the situation you are in where you may need aid โ€” and this helps doubly so in the case where you need to pass the task onto someone else. Either way, you're either making your job easier for yourself or someone else's job easier. Both are better states than working too hard, falling behind, and being (overly-)stressed. Link away!

Bonus: Transparencyโ€‹

While I keep security top of mind, transparency is as important and is not a conflicting ideology. In fact, I look at transparency as being complementary to security.

Transparency does not mean sharing willy-nilly with the world. At a project level, it means keeping everyone up-to-date and at a personal level, it means taking responsibility for your actions.

How do we share? How do we keep informed? We share by @-ing people, or by adding them as the watcher of the task. We keep informed by proactively being interested in tasks or epics that are of particular interest that day or week, and becoming watchers.

Nothing should be hidden, except for particularly sensitive IP (of which you should know about in advance if you have access at all).

Continuous and Automaticโ€‹

To summarize, the system is continuous because as a team, we will be reacting as needed to task-level communications, informed by our use of smart tasks, @-ing people and Slack. It's automatic because the tool keeps our context for us in one place and calls out to interested parties (from the individual to the whole team).

(Honestly, "habitual" is probably a better word than automatic. You tell me.)

The Longโ€‹

Made you look. ๐Ÿ˜† There is a LOT more to be said about project management best practices. However, we have a project to run and you only have so much time to read. One major point to make: This does not work if people don't participate and work as a team. Sounds almost cliche, but it's true:

We build bigger and better when we're together than when we're alone.