I actually listened to Margaret Maloni 3 weeks ago on the PM for the Masses podcast. While I was expecting to just listen and post, I’ve been hesitating due to a real learning experience that resonated with Margaret’s ideas.

Before diving into my lessons learned let’s get the good stuff up front.

Work Breakdown Structure

Work Breakdown Structure (WBS) is a “Picture of the Work”, an “org chart”, a “list”, or “graphical representation of the work”. The purpose of which is to “Answer the question: What are we doing?” (Margaret Maloni). Based on that description, I’ve templated what a listed WBS may look like here:

  1. Project
    1. Deliverable (Action / End Result)
      1. Task – Owner
      2. Task – Owner
    2. Deliverable
      1. Task – Owner
    3. Deliverable
      1. Task – Owner
      2. Task – Owner
      3. Task – Owner
  2. Repeat

Deliverables must be descriptive with actions and a proposed result. Really, the same principle is used in writing technical instructions i.e. a step is made up of individual actions.

Here’s a quick example of a project-deliverable. Say you own a business that makes wedding cakes. The project of each cake would have deliverables like 1. Provide beautiful and attractive design 2. Make said cake 3. Getting the cake to the venue on the Big day. In the 3rd deliverable, Rebecca is tasked with getting the vehicle and driving. Jim is task with getting directions and knowing the time the cake needs to be at the wedding. Finally, both are tasked with getting the cake in the vehicle and out of the vehicle safely.

Really, I knew about a WBS before I knew that’s what it was called. I’ve used Jira, Asana, and even Google sheets to breakup work into meaningful chunks. That’s not to say I understood the value or meaning, but I do understand the importance of clearly defined boundaries. There’s nothing like when a teammate oversteps their role and does someone else’s job. The worse result is when multiple teammates confuse ownership. Try feeling comfortable after hearing “I thought you were going to do it” in the eleventh hour of a major deadline.

Lean on Your Team

That all being said, I’ve been having some growing pains in my position. For such a long time I’ve been tasked with projects that didn’t require help or required minimal team effort. This is called “siloing” and has really be a trip overcoming the bad habit.

For building out a blog, I know all the steps. 95%+ is easy enough to do on my own. Heck, I can pump out a blog in a day with no problems if it wasn’t required to talk with a client. Heck, every project would be incredibly easy if we didn’t have clients, but then we wouldn’t have any projects to manage now would we?

Recently, I’ve had a client that made several back-to-back changes to their blog. The project started with a “need to get this blog done by yesterday” level of speed and I allowed that feeling of urgency drive my communication and actions. I made sure to address every ask, make every change, and drop everything to get the blog over the finish line.

While I was able to do most things (change a color, update some text, fix a broken link), there was one ask that confounded me. Instead of asking for help, I decided to try doing it myself. The outcome was a horrible looking button in the footer of the blog. At that point, my want for getting the blog “done and out the door” surpassed my own expectations of quality. Let’s just say my designer wasn’t happy about it either. Ignoring him was a poor choice that could have had major repercussions with our relationship and the company-client relationship.

The lesson of leaning on your team is one of trust and humility, but also one of assigning the right tasks for the right people. I know I can fix almost anything, but why should I? The team knows what they are doing. Sure, I can learn and grow, but for important matters I need to leave my hubris at the door and admit when I don’t know something.


If you’re a new project manager like myself, try your best to assign tasks and ask for help. Don’t allow your want for getting a project done get in the way of building trust with your team.

I really hope you found something neat to add to your everyday rhetoric repertoire. Remember there is no such thing as a solitary stakeholder and your teammates have their names attached to projects as well.

Also, if you get a chance check out Margaret Maloni on Twitter. You’ll be glad you did. I appreciate her thoughts and have already started putting them into place.

Thank you for reading. Until next time, keep doing your best to learn and grow your rhetoric arsenal.