Beyond Herding Cats: Lessons for Project Management in a Small Agency

- [Tori] Before I dive
in, I wanna thank you all

for coming out to this session.

I hope the camp's been super inspiring,

but also really fun.

This is actually my first
MidCamp, and I am a Midwesterner,

but now I'm in the Bay
Area Drupel community,

so it's great to meet
Midwestern Drupelers.

So, I'll try to make
this fun and informative

and keep our good conference
vibes going into the afternoon.

So without further ado,
welcome to Beyond Herding Cats,

Project Management in a Small Agency.

Whether you yourself are a project manager

in a small agency, a PM in a big agency

who's managing a smaller team,

maybe a freelancer who's
project managing themselves

or a developer or designer
who's trying to learn

to live with a PM without hating them,

hopefully this will be
a good session for you.

So, who in the room is a project manager?

Who in the room is a developer?

Lots of you, who in
the room is a designer?

Okay, good to get a sense.

So this session really came out of feeling

like most project management
resources were geared towards

people in big companies with
already established processes

and really clear
guidelines, but I'm someone

who doesn't work in a large company,

and the companies that I
work for are reasonably new

and very small and so what I was seeing

in my day-to-day, the
challenges I was dealing with

were not being reflected
in any of the materials

that I was finding for
education and resources,

so I decided to work on trying
to created some resources

out of those experiences,
out of those times

that we tried to implement
new processes and failed,

or the times that we were successful.

Let's see if I can actually

click through my slides (mumbling).

There we go, okay.

So, I'm Tori Lewis.

You can find me on
Twitter @torilewiswrites,

so if you have questions or
tips that I did not cover,

please find me on there.

I currently divide my time between

two different small agencies.

Fibonacci Web Studio is a
group which focuses on research

and higher education websites and apps,

and I bet you didn't see
I'm Director of Projects,

which means not only am I the Lead PM

and I'm the Contact Strategy Expert,

but I'm also part of our
sales and marketing efforts,

and a frequent dabbler in code and design.

I try to leave it to the professionals,

but sometimes I can't resist,

and that's a very small team.

We're a team of about five.

Rootid is a little bit bigger.

I'm a Project Manager at Rootid as well,

and they're a full-service
agency dedicated to nonprofits,

and at Rootid, I focus
solely on project management.

So, part of the reason
that I go into such detail

about my background is that I feel like,

while every small agency
feels really different,

and I know with working with two of them,

they definitely feel
different in the day-to-day,

there are strategies that can be adapted

to all of these environments,

and perhaps even to
larger agencies as well.

While these two companies are different,

a lot of the skills and tools that I use

can be adopted for both.

So, a former colleague
used to talk about managing

content editors,
specifically, as herding cats.

For those of you who might not
be familiar with this idiom,

basically imagine trying to make

a whole bunch of cats move
in a single direction.

It's hard and it's
frustrating, and ultimately,

cats really don't care what I have to say,

and they have a mind of their own.

So, while I don't think that
the whole of project management

is like herding cats, I
do think the skillset to

successfully managing a
project is kind of similar

to that of animal training at a surface.

So, you have all these diverse
and talented teammates,

but your job is to manage them

so that your team can
make a cohesive hold.

So, I have like three animal analogs

that I'm gonna use
throughout this presentation,

and those three most common animals

and small agency web
development are lone wolves,

so I have found that most web
developers who choose to go

to a small agency as
opposed to a larger agency,

or a really established company,

are, tend to be the
moles, they like building

maybe in small packs, but
often alone, and giving them

a clear goal can be the
best way to manage them,

and I'm sure all the developers
in the room can tell me

if I'm wrong (laughing) in the
question and answer portion.

Cats are basically your clients.

They have a lot of competing priorities,

and getting them to focus
on their web project

can be kind of like herding cats.

The other animal analog
that I use for small agency

web development is your mama
bears, so in small agencies,

you often have one or two team members

who are tempted to take on
everything about a project.

They wanna do everything
from beginning to end,

they're super strong and super capable,

but they have difficulty delegating pieces

to other members of the team.

Obviously, this is mostly a silly analogy,

and no one person fits into
each category perfectly,

but like an animal trainer,
your job as Project Manager,

especially at a small
agency, is getting to know

each member of your team
so that you, in your role,

can support them individually
and help the team put on,

to continue the metaphor, a great show.

I promise that we're gonna
start to get more practical,

but as an English Literature graduate,

I can't resist a good
or bad circus metaphor

to begin my presentation.

So, my number one tip for
working in a small agency

is to be agile, lower case A,

even if you are not agile, capital A.

So, trying to adopt a
full agile methodology

while you're working in a team
of two or three can really

illicit a lot of groans,
especially from developers

who've been burned before
by a project manager

trying and unsuccessfully
implementing agile.

Trust me, I've heard these groans

in trying to implement
agile on some teams.

Developers at small agencies
often wanna maintain the reason

that they've moved to small
agencies to begin with,

which often include fluidity,
individual ownership,

flexibility, and a little
bit of room to play.

So, they often value being
agile with a lower case A

over being agile with a capital A.

You can definitely try to implement,

like, full Scrum agile
methodology at a small agency,

and if you do, please be sure

to blog about it so that I can read it,

but I've found that it works
better to adopt some practices

from a lot of different PM philosophies,

and to keep changing, really,

along with you and your agencies.

What's gonna work today is
not gonna work tomorrow.

What works with five people on the team

is not gonna work when you
have seven people on the team.

So, daily stand-ups can be great,

but what if you have part-time freelancers

who don't work with your team everyday?

Perhaps bi-weekly, stand-ups
are a better solution.

What if a project only involves one member

of a very small team, so we
take on some smaller clients

that we only have one developer
working on those projects.

A daily stand-up's not really
gonna work the same way

for that project because
not everyone is as aware

of what's going on, so we try to schedule

occasional team brainstorming sessions

as opposed to, like, an official stand-up.

Weekly sprints might not work if you have

a project that takes less than a week.

We do have some clients
that have some quick

turnaround projects, and
so doing weekly sprints

are not the best way to
get those projects done,

and I found that,
oftentimes on a small team,

you don't have enough people
to have both a product owner

and a Scrum master as sort
of two separate individuals,

so oftentimes, those
responsibilities can be combined

across various members of the team.

So, one thing that I do consider sacred

from the agile methodology,
but you might not,

every team is different,

is the project debrief or postmortem.

Every project brings with it lessons,

and especially in a
small agency, one project

will probably not make
or break your whole team,

but not learning from that project,

and kind of taking the same
mistakes into the next project,

it's really easy to kill a small agency

with three or four projects,
so making sure that

after every project, you're
able to learn from it,

and recover before your next
one is really important.

So, ultimately, trying to adopt
wholesale single methodology

is really difficult in a
small agency because each team

is comprised of different
people, and different methods

will help them use their skills the best.

So, your job as a Project
Manager at a small agency

is not only to manage individual projects,

but to especially manage
the agency's process,

and so, ideally, each
project is managed in a way

that is more suited to
the context each time.

And again, if you're a
small agency that's growing

a little bit, even going from
five people to seven people,

can make a big difference in what sort

of methodologies are gonna work for you.

Going from a team of
two developers to a team

of four developers is a
really big difference,

so you have to make sure that,
again, you're being agile,

lower case A as the
word, even if you're not

adopting a full agile methodology.

So, next thing I wanna
talk about is meetings.

So, meetings for two to three people

can feel like the Wild West.

Everything goes, let's
just rush in guns blazing.

And, while I hate to break it to all

the spaghetti western fans in
the room, this is a mistake.

It's certainly tempting
because, in a small team,

you all know each other's rhythms,

you feel like you can
read each other's minds,

you've been working together for awhile,

and you might as well just
hit the ground running.

But, this is a surefire way

to get all turned around on your horse.

So, running meetings for small teams.

I wanna do just kind of a,
hopefully, quick and dirty

meetings 101 for small teams.

Like with agile, there's
no need on a small team

for formality, for formality's sake.

Again, you do all know each other.

You don't wanna implement things

that people aren't going to
enjoy or find productive.

There are a few cardinal
rules when running meetings

for small groups that will
save you a lot of time

and headaches in the long run.

Number one is have an agenda.

Don't assume that you'll
all remember everything

you need to talk about, because you won't.

I find a quick bullet pointed
list is usually enough.

It's great to share in advance,

but having it up on a
screen share or a whiteboard

during the meeting works well, too.

If everyone knows what
the map ahead looks like,

then you're less likely to lose the trail.

Number two is the time box.

This obviously goes hand-in-hand
with having an agenda,

but once you know what you
wanna cover, make sure that

you can actually cover it
all in the allotted time.

No one likes an hour
meeting that turns into

an hour-and-a-half, and
it's much better to have

two 45 minute meetings than
one hour-and-a-half meeting.

Give an estimate for how long it will take

to cover each item, and then
be sure to keep your eye

on the clock, and kind of
give people a little bit

of a nudge when they start
to hit their time zone.

The next tip is to take things offline.

So, if you've ever worked
in a corporate office,

you might roll your eyes a little bit at,

can we take this discussion offline?

And, while certainly, it's
a little bit of a cliche',

it can be a really helpful tool.

So, the idea of taking things offline

is basically the difference
between a reply all

and a reply on an email thread.

So, let's do a little scenario
where you're in a meeting

with a designer, a PM, and two developers.

You're all on the same project,

you're all talking about the
implementation of that design.

A good conversation to
offline in this meeting

is when your two developers
start having a very highly

technical discussion about an API.

I, personally, as someone
who is managing the budget

for this project, do not
wanna pay the designer

for you all to have a 45 minute

conversation (laughing) about an API.

The designer doesn't need to be aware

of all of those details,

so this is a great time
to do some offlining.

Now, I don't recommend actually
saying, let's offline this,

because people kind of have
that visceral reaction,

especially if they've worked
in the corporate world before.

So hey, developer X and Y, it seems like

this is a great thing
to have a conversation

in more depth about, why can
you put it on your to-do list

to follow up with acts about this later.

Everyone's gonna appreciate
that you're respecting

their time, and X and Y still
get to have that conversation

that's really important to them.

The designer is gonna really respect

that they don't have to
sit in on this conversation

that they don't fully understand,

and when you're looking
at the budget later,

you will thank yourself.

The next tip is not to
ignore the niceties.

This is especially important
for remote workers,

but all small teams can benefit from

a little bit of small talk.

It's really tempting when you
know each other super well

to just sort of dive into
the problem straightaway.

But, give yourself some
breathing room at the beginning

and the end of the meeting
to catch up on your weekends,

compare March Madness brackets,

and brag and commiserate
about non-work exploits.

Again, if you're doing the
time boxing agenda method,

you can just build in
three to five minutes

at the beginning, three to
five minutes at the end,

to make sure that you can all

sort of connect on a more human level.

Fostering team morale is always important,

and it's easy to ignore company culture

when you're working with a small group,

but a little bit of bonding

during every meeting can go a long way.

Next thing is that everyone should walk

out of the meeting with a to-do list.

Every decision needs to be
documented and acted upon.

There are a couple of
different ways to do this.

So, each person can document
their to-do list individually

and share out at the end of the meeting

and ideally at the beginning
of the next meeting.

Alternatively, you as
PM can take ownership

of taking notes on all action items

and sending out a group
email after the check-in.

My personal favorite method is to use

a project management software
directly in the meeting.

So, on my teams, we use Asana,

and I'll have that up during the meeting,

and as we go through all
of the different issues,

we create and update
the tasks in our system,

so I, as PM, kind of
take ownership of that,

although people add their notes as we go.

We assign each one to a team
member during the meeting,

and we assign a due date
again during the meeting.

This means we're not adding any
extra steps to our workflow,

so you don't have to send
out the followup email,

you don't have to make
sure that you're including

five minutes at the end for everyone

to share out their to-do lists.

It's very clear what's going on,

and you're maintaining your
up-to-date project tracker,

so you're not only taking an
extra step out of your day,

but you're also making
sure that you don't have to

go back to that project tracker

and follow up with everyone's to-do items.

And additionally, everyone can
see what decisions are made.

I don't have to email you to
ask you for your to-do list

to see what you're doing, it's
right there in Asana for me.

Additionally, if someone on
the team is not in the meeting,

you can still assign tasks then.

It becomes clear during
a development meeting

that there's a design task
that needs to be done.

You can still assign that, and ideally,

you leave a helpful note saying,
if you have more questions

on this design task, reach
out to this developer

with details or for more questions.

So, what if you only have
one developer on your team?

So, we're talking small teams,

but what if you're like
a really small team?

So, surprise, all of these
things are still true

if you only have on developer.

It is still important to have
regular one-on-one meetings

between the PM and a sole
developer on the project.

It is still important to
come in with an agenda

and leave with a to-do list.

It is still important to be respectful

of that single developer's
time by timeboxing,

and ensuring that follow-up
meetings are scheduled

if specific items require
more in-depth detail.

So, unlike when you're
offlining with multiple people

because you're concerned about one person

getting distracted and not being invested

in that conversation, in this case,

offlining things is so that you
can have a dedicated meeting

about that issue, and make
sure that you still get

all the items on your agenda done.

Additionally, even if
you have one developer,

still spend some time sort
of doing that casual chat,

that small talk, so that
you can keep your lone wolf

happy and well prepared
for the work ahead.

Next tip I have is to love and live by

your project management software.

So, project management
software is critical

to keeping projects moving
on schedule and on budget.

Again, I think very highly
of Asana as what we use

on our team, but there are
so many tools out there

that trying to list them all

would take me the rest of this session.

Some of them are more geared
towards enterprise solutions,

and some of them are more
geared towards small teams,

and then there's a giant gamut

in the middle of those two things.

So, I like to think of PM software as

the project manager's
version of the text editor,

in that everyone has their preference,

there are a lot of options,
and trying to convince someone

who uses Basecamp to love Asana

is better done over beers
than in this session,

so find me later if you wanna have

an argument about it. (laughing)

but, whatever software you love,

all of them are built around project tasks

and deliverables to keep you on task.

It is critical to use them intentionally

and thoughtfully to ensure
your project's success.

I don't know if you've
ever started on a new team

or come back after a vacation and you see

that your project management
software is just a mess

of overdue items that no one's
looked at in three months,

and there's a bunch of stuff in there

that no one really understands
when it got entered and why.

We wanna avoid that,
and in order to do that,

you have to be really intentional

about how you're using the tracker.

So, no matter what tool you use,

I have some tips to help you
try to get the most out of it.

So, one is that you need to
be aware that notifications

are very customizable, so,

it's both a good and a bad thing,

so maybe on a development task,

I wanna know every single
thing that happens.

I'm managing that developer very closely,

but maybe on a design task,

I only care if someone mentions me.

I only wanna know when the
design task is finished,

I don't need to be involved
in the ins and outs.

So, I can make that work for me,

I can set up those notifications
on a task-by-task basis.

But, if I have a mama
bear tendency co-worker,

they can get notified
anytime anyone does anything.

So, even if the task has
nothing to do with them,

they can still get a notification

so they know everything
that's going on at all times.

So, that's great, it's great
that it's so customizable

for individual wants and needs, but,

because everyone can set their individual

notification preferences,
you can't be entirely sure

that people are seeing what's happening,

unless you are intentional about it,

so you need to get to
know your team's flow.

You need to know who's using Asana

or your project management,
and I will use Asana

as my default word, but you can feel free

to translate that in your own head.

You need to know who'd
using Asana in what way,

you need to know if someone's
checking it every morning,

if they're checking it every evening,

if they're only checking
it when they get emails

and what those notification
structures are like.

You also need to follow up
on Asana tasks in person

or on your next phone call,
especially if you have

someone that isn't fully invested

in that project management structure.

I also like to use Asana during meetings

so that it's very clear
what my expectations are

in terms of Asana, so I like to make sure

that it's pulled up on everyone's screens,

that everyone can see what I'm seeing,

that we know where the details
of each task are living.

Basically, I wanna teach
my team to use Asana

as the central source
of truth on a project.

So, if anything comes in to
me via email from a colleague

or from a client, I make sure to update

the Asana instance right away.

Email is not the source of truth.

Asana is the most up-to-date
version of all information.

So, two, if you don't
have someone monitoring

and cleaning up your instance often,

it can quickly become an
overload of information.

I've seen everything from
people creating duplicate tasks

for the same issue to
trying to build an entire

admin interface in a single task in Asana.

So, setting norms and enforcing
them is critical to using

the software effectively,
and so is regular cleaning.

You need to set aside time to review

your team's entire instance,
and clean up things as needed.

Again, this is where the,
like, three month overdue tasks

come into play, where you
can actually have a meeting

with your team and say, okay,
so this is some cleanup tasks

that we set up three months ago.

Is this actually a priority for us?

How can we make it actually
happen, as opposed to just

pushing back that
deadline for three months?

You can and should include relevant files

and links in your Asana system,

and sync to your Dropbox and Google Drive.

You want to ensure that everyone
has access to everything

so that they can actually do their jobs,

and once they see something in Asana,

that they can kind of run with it.

You can also integrate your
project management tool

with your time tracking tool.

I recommend, if you're
already using a time tracker

and you're looking into a new software

for Project Management or vice versa,

that you see what tools can
integrate well together.

This is super, super
helpful with a small team

'cause I know a lot of people

look at Slack or email and
forget to build that time

to the client, so if you're
communicating with your team

about a specific task in your
project management system,

you can make sure that
that time gets tracked

so that everyone gets
compensated appropriately

and all the time gets tracked and billed.

Alright, quick touch up,

which is that I'm running
quickly out of time,

(laughing) but I wanna talk communication.

So, communicate often and well.

My number one thing to
say about this is that

communication is a skill,
and project managers,

it is your job to teach that to your team.

So, it can feel often
like a miscommunication

is the fault of whoever
is miscommunicating,

but I do feel like, as a project manager,

it's part of your job to make
sure that your team knows

how and when to communicate,
what the norms are,

and the ways that you should be doing it.

So, on the technology side,
be sure to share new features

as you find them, so if
there's something specific

about Slack that people need to know

about the do not disturb function,

whatever your team
members don't really seem

to be internalizing about your
tools, share that with them,

have a little meeting, show
them whatever Gmail tool

is coming across your way, or
a plug-in that's really great.

Additionally, ask new team members to lead

specific portions of meetings,

and give feedback where it's appropriate,

especially for client
facing communications.

It's great to have
developers and designers

communicating directly with clients,

but you need to make sure that
the norms are set for that.

It is helpful to at least,
once a month, add a new layer

to everyone's communication competencies.

If you're a small team,
making sure that you're

bringing everyone along with you is really

the only way to keep getting
better and better as a team.

So, err on the side of being more clear

than you think you need to.

I used to say err on the
side of overcommunicating,

but I don't think it's just about volume.

It's really about focusing
on the quality and clarity

of your communication to ensure that

everyone is all on the same page.

I will say, regularly
check in to ensure that

the communication
strategies you're employing

are working well, so if you notice

that someone is never responding to Slack,

ask them if they caught the discussion

of the share bug on Tuesday.

Just make sure that they
know what's going on.

Make sure that your
team is checking Asana.

See if they're in too many meetings

and they just don't have
time to do their work,

or if they're in not enough meetings

and they feel like they're
just like, flying out there

in the open and no one's
checking in on them ever.

Communicate about your communication.

An often overlooked aspect
of project management is

a positive and productive team culture,

and of course, I have
about five minutes left,

so I'm almost gonna overlook
it (laughing) in this talk,

but I'm gonna try to get there.

So, for small agencies, team culture

can basically equal company culture.

While you're not the sole
source as project manager

of team culture, you do
play an important role

in insuring that company
culture is maintained

throughout the project life cycle.

So, allow flexibility, but make
sure that your team members

understand the limits of the flexibility.

Have clear guidelines on how

communication needs to be processed.

So in our contracts, it says
if a client reaches out to you,

you have 48 hours to respond.

Now, that's a pretty long period of time,

so our team norms are
much faster than that,

but you have to be clear with your team

about what the norms are
around communication.

If I, as Project Manager, reach
out to you as a developer,

you need to know when I
expect you to respond.

Do I expect you to
respond in five minutes?

Do I expect you to respond in 10 hours?

That's a really important thing to know.

Ensuring you have, again, some
avenues for non-shop talk,

so whether it's a happy hour,
a dedicated Slack channel,

a weekly meme challenge,
a quarterly dinner,

just make sure that you
have some time built in

to have a little bit of
fun with your co-workers.

This is especially,
again, important if you're

working on a remote team, so
that dedicated Slack channel

where they can share their
personal joys and accomplishments

can be great, and also just sharing memes

that are relevant or
irrelevant to your work.

And, give kudos.

So, most platforms now have the ability

to thumbs up messages, react with emojis,

or at the very least,

send the clapping gif from Citizen Kane.

Make sure that your team members know

how good of a job they're
doing when they're doing well.

Encourage and set boundaries.

You, as a PM, should not be on Slack

every night until 11.

You're teaching your team members

that they need to be on Slack until 11.

Teach and then encourage folks to use

the Do Not Disturb and other methods

to disable notifications
during non-working hours.

Talk about your office setups,

maybe share co-working fees if
you're all working remotely,

and set yourselves up for success

by setting your boundaries.

At least quarterly, have
individual check-ins

with all members of your team.

If you're working in a small agency,

this is very easy to accomplish.

Working in a small team
requires that you be attentive

to your team dynamics, and
team members might have issues

that you can solve, or
suggestions for how to improve

communication, collaboration,
or company culture.

You won't know if you don't ask.

So, whoop, while small agencies

can feel like a circus,
they are our circus.

They're fun and they're
agile, again, lowercase A,

and they're a great way
to meet clients' needs

without a huge overhead cost.

Being a project manager at a small agency

often requires wearing a lot of hats,

but luckily, like the Mad Hatter,

project managers are known
for looking very good in hats.

This circus means everything to us.

I hope that your small agency circus

continues to be successful.

Alright, so we have
Contribution Day slide up there.

Contribution Day is tomorrow!
(audience applauding)

You don't have to know code to give back.

So great, and then I have a
feedback slide, I keep it there.

It's 202.

There we go, (laughing) mid.camp/202,

for feedback, and we have
just two minutes left,

so I don't know if we have any questions,

but you could find me after. (laughing)

- [Woman] So, in your
definition, and I think

you might've said this
before, what's a small team?

- [Tori] I mean, it depends.

If you've worked in a big agency before

where you have, like, 200 people,

- [Woman] So, it's relative?

- [Tori] I definitely think it's relative.

I do think that once you get over 20,

there starts to be,
sort of, more processes

that need to be more formalized,

but once, when you're under 20,

you can really be agile
and quick on your feet.

Alright, thanks everyone. (laughing, audience applauding)
 

 

Captions made possible by ClarityPartners.com. Chicago area Drupal consultants