Every team I've worked on as a project manager has enjoyed some degree of success. And yet when I think about my style of leadership, I perceive myself to be a "servant leader", always aiming to find and highlight what the team can do do improve its processes and its results. As I struggle to decide if this is a gendered evasion of my own skill, I've started to capture some of the elements that would make my success repeatable for someone else.

I've broken it down into two parts, or five elements:

• Outcomes
  • Targets
  • Monitoring
• Attributes
  • Transparency
  • Pacing
  • Creativity

I'm not sure if the names are right yet for the two groups, but I do think there are two clusters. When I tried drawing diagrams for how the pieces fit together, I started with arrows because I thought it was important to show progress in the diagram. But it didn't feel right. I played around with trees with each of the attributes acting as a branch. But that didn't feel right either. Finally I settled on a Venn diagram -- my go-to-cop-out diagram shape of choice.

I would love for you to come up with your own diagram, or shape, or visual representation of these ideas. I think the easier it is to replicate a sketch, the easier it will be for people to remember the elements.

In the mean time, let's take a look at these five elements in a little more detail. Much of this is taken from reading I've done on Agile, Scrum, business management; and my own experience in athletics (lapsed cyclist and triathlete; and even further back certifications in coaching and reffing).

Outcomes

First up: the elements which are easiest to measure: the outcomes. This includes not just a destination, but also progress reporting along the way. Outcomes tend to have artefacts, tools, and things that are easily measured.

From a business perspective, outcomes are cyclical: through monitoring we noticed a problem, we have defined a target outcome of the future state, and now we'll aim to achieve that target. The monitoring aspect feeds back into the target:

• Are we still heading towards the target?
• Is the target still the right place to be heading?

Project Process = target + artefacts + monitoring + tools

Targets

Most of the teams I work with these days are using some kind of Agile/Scrum or Agile/Scrumban (yes, Scrum + Kanban). There is a horrible tendency to think that any kind of Agile means "no planning". Wrong. The Manifesto does not prohibit you from making a plan, it coaches you to respond to change when the plan is no longer valid. So keeping that in mind, I use the following artefacts to create targets:

• User Story Map
• Project approach document -- makes a transparent summary of what the team has told me the project will look like as it unfolds. Subject to change.
• Technical architecture document -- high level overview of the software / services / APIs / languages / etc. Enough to get a critique from other devs / architects, but not a detailed implementation guide.
• Epics -- must have a definition of done, may be sorted according to theme (e.g. "design" = theme); relatively general on implementation details; very specific on the business value
• Tasks / User stories -- created 1-2 sprints before they're to be implemented by the development team

The importance of the target is to have something to aim for. Hitting the target is actually less critical than aiming for the target. It helps to provide unity in vision for a team, so that they can identify potential issues with the direction the product / project is going in. More about this aspect in "Transparency".

The second most important reason for having a target is to identify when you will get a break. I have trained for a lot of races and competitions. The level of mental focus is only sustainable for so long. After a while, you need to take a break. This is true for your muscles as well. You build and build and build with the intention of peaking at competition. As a competitor you want to leave everything on the competition grounds, and take no additional capacity home. I bring this same philosophy to the development teams I coach: let's build the best we can, knowing that there is an end in sight. More about this aspect in "Pacing".

Monitoring

It was a difficult decision to separate "Targets" and "Monitoring" as they're most definitely related. A target generally defines a future desired state that is different from the state you're in today. To ensure you grow (or shrink) from one state to the other, you need to have a way of measuring both states. This measurement will use some kind of monitoring tool. Monitoring isn't just a green traffic light on a CD build dashboard, or Google Analytics (although both are quite useful tools).

A monitoring tool is anything you can use to continuously measure the improvements your team is creating. Everything can be measured, and therefore monitored. Don't believe me? Read How to Measure Anything. You won't have time to act on the trends in changes for every measurement though. So focus on monitoring things that create value for your team, your customers, and therefore your business.

As a coach, I measure and monitor:

• Individual and team health -- quality of work, tone of voice used in meetings, level of engagement. A lifetime of dealing with my own moods has given me a capacity to track this (more or less) in my head. Those who've not thought about how to track this information previously may find value in reading up on "mood logs" used by psychologists and their clients.
• Code health -- regressions, defects

I will also keep an eye on the domain-specific monitoring done by specialists on the team (e.g. dev/ops, business). For this list I will generally monitor the monitors (e.g. talk to the people who are doing the monitoring, as opposed to checking the dashboards myself). This list could include:

• Code health -- performance, load
• User interactions -- generally with Google Analytics, Kibana

There are definitely ways to manipulate monitoring tools. For this reason I am very careful in how I apply anything to do with "measured velocity" (i.e. the number of tickets your team is closing in any given unit of time).

Attributes

If the "outcomes" describe what I do, the attributes describe "how I do it". There aren't necessarily tools or artefacts or "things" in this section. But rather a series of techniques that I apply in various situations to improve the health of the project and team trust.

Although I believe everything can be measured, attributes are often harder to measure than outcomes. As a result, this part ends up being more of my hand waving magic. I can describe the techniques I use, but until you have experienced the effects, it might not be as easy to understand. Please ask questions (ping me on Twitter @emmajanehw) and I'll do my best to clarify / expand.

Transparency

I have a special hate-on for friction. I don't avoid it. I seek out friction, determine its underlying causes and smooth things over until things are working better. I'm not entirely sure where I picked this up, but let's go ahead and blame it on physiotherapy: When you're injured you shouldn't just throw a tensor bandage on something. You should seek to understand where the problem came from and then work backwards to repair the injury and ensure it doesn't happen again. This can mean taking a break; changing a training routine; physical therapy....all with the aim of uncovering how to fix the problem.

As a team coach, transparency reduces friction between siloed roles. It eases tensions between developers and stakeholders, or even developers and developers.

The techniques I use to improve transparency are as follows:

• Sprint planning meetings, Standups, Retrospectives, Deep Dives. Have a purpose for your meeting, and keep the focus during the meeting. Be transparent about the problem you are trying to solve--which means identifying a problem and then meeting to solve it.
• Onboarding documentation for developers -- sets expectations for how tasks will be completed, and to what standard of work
• Project approach document -- sets a target plus a range for the definition of "done" ("MVP" vs. "long term wishlist"). This allows developers to focus on scaffolding for the future instead of just bolting on a few new features. Yes, I know I have this artefact listed under Targets as well.
• Ticket descriptions and comments -- capture conversations and conclusions in your ticket system. (I take my cue from the Drupal.org issue queue.) Allow stakeholders to see your notes (when relevant) about what you're planning to do. If something is going to take you X^n amount of time to complete, but a variation would take significantly less time, have that conversation. This will allow everyone to prioritise work appropriately. More on this under Creativity.
• QA steps for testing -- allowing developers to know up front what they need to do to succeed can reduce the round trips for testing, and reduce the irritation the developer experiences if work is returned to them for something they could have easily included had they known.
• Five Whys, fishbone diagrams, and any other tool that allows a team to assume good faith on bad actions and fix the underlying problems which allowed the team to fail

In DevOps chatter there's been a lot of talk about getting better (and ultimately automating) hard things. Deployments are hard? Fine. Do them more often. Make it a repeatable process, and then automate it. The Scrum meetings are an example of this: meetings are irritating so make sure you know what you're meeting about, focus on excellent outcomes, then stop the meeting when it's done.

Pacing

Pacing is definitely a chapter out of my sports coaching book. I have ignored this element with only near disasterous results. A person cannot sustain a full-out pace for an extended period of time. And they definitely can't do it if there is not a real, defined hard stop target they are working towards. I personally get irritable when I get burntout. As a result, I do not "let" my teams work overtime hours. Because when my team works, I am also working.

To pace a team, I look for a routine or a rhythm. (In Scrum terms this is a "velocity" -- which is too easily gamed for my liking.) The elements of my pacing are the ease for the following sequence:

• conflict / question
• conversation
• conclusion
• next action

During meetings, I listen for:

• tension ("X is broken", "Y is not working", "Z is confusing", "A will be hard")
• glossing (generally implies that something is so hard it can't be described / requires invisible knowledge to complete)

Then I look for ways to reduce the friction and create a steady pace. Does that mean taking things out of a sprint? Getting outside help? Making connections (pairing, getting feedback from a stakeholder). Sometimes I will miss problems, and sometimes I will invent problems by mistake when I "problem" language that was actually just brainstorming.

When planning sprints, I will try to sequence Epics so that there is a break after a particular difficult one so that the team can recover a bit. I talk about Pacing more in my talk on Change Management.

Creativity

Artists create constraints so they can be creative. A painter will choose the type of paint and the size of their canvas. A comedian will choose a theme for their show. Every part of what I've written up to now provides you with some form of constraints. In this final element, you start breaking out of those constraints and add life and fun back into your project. Generally my "fun" is a little less at the very beginning so that people take me seriously, then I introduce some elements of fun when the first targets are met. (When I'm on a project, animated GIFs and project approach documents are considered equally important tools.) The humour often ramps up as the project progresses and more people get in on the fun. The only rule is that we never punch "down" (the humour is never at someone else's expense). The pacing of my creative injection changes as team members start to push back with their own creative ideas -- the humour I bring injects levity and also shows people that they are permitted to think outside of the rigid experience they may have had with other teams.

• Brainstorming alternate solutions -- getting stakeholders to come up with lots of ideas of how a given business value could be realised (User Story Maps are great for this)
• Pitch sessions -- getting developers to pitch ideas to stakeholders on whether any given Epic should be scaffolding or duct tape.
• Animated GIFs -- used for rewards and motivation
• Personalities / Thinking preferences -- get to know the people on your team, and then find creative ways to keep your team engaged and focused. You're already monitoring the "health" of your team...now work to improve it by injecting relevant creativity into the project

From my years and years of training, I have a playbook of ways to present ideas to people. Unfortuntely it's not a written record. If I were better at documenting all of the things I've tried, I'd have enough to fill an encyclopedia. Learn from my mistakes and start recording what you try. Include notes on the conditions that made you try it and why you think it was / not successful.