Kosmothink

Developers get a bad rap from us IT PMs.

We IT PMs have a sort of prevailing wisdom about dealing with the ‘devs’. We even talk about it in our job interviews as a known issue; this idea that Devs are cantankerous arrogant curmudgeons, and we need to have certain skills as PMs to navigate through Dev incurred roadblocks to timelines.

Well, I’ve worked with and been friends with Devs for a long time and I think it’s time we think a bit differently about them. From what I’ve seen, Devs have always been good to me (made deadlines, stuck to process, built incredible things) when I’ve thought of them, and given them high regard.

I think any PM will see an improvement in Dev-Pm relations if you remember and adapt to the following:

Appreciate The Knowledge

Requirements become design and merge with the human skill of the builder/artisan to become something usable and beautiful

Developers are  like skilled artisans; people who shape, and mold an idea into something concrete, movable, usable. We respect someone who, for example, builds a beautiful table, because we understand that the ability to merge art and function is unique and rare. Perhaps because there is so much work, and so many developers, we tend to down play the work they actually do.

With an artisan point of view, we should approach developers with an appreciation for their knowledge. This attitude manifests itself when we interpret questions around requirements not as stone walling, but instead, a desire to build the best thing possible.

Artisans tend to develop a sense of pride in their creation. We should recognize that when we shift gears too suddenly in requirements, that thing in which pride was taken, has to be tabled. There is some kind of human cost to this, a disappointment. Multiple disappointments can lead to bitterness. As PMs we should recognize this sensitivity. Our role in controlling the process and QAing and ensuring good requirements is key to minimizing this phenomena.

Trust the Delivery

I approach that edge of the full elaboration of requirements and the beginning of the magical transformation into something functional carefully.   As a team, we want to explain the design, but relax and step back slightly to allow the technical ability to form idea into function to show itself and flourish.

I think a lot of PMs have a hard time letting go at this point. We often want to know the exact details of how something will be built. So we have to employ trust and allow the development team to prove that they can deliver. Paradoxically employing trust, even if things arrive a little late, serves to open up the channels of communication about the details.

It’s ok…let go!

I learned this directly from a dev manager when he suggested that instead of questioning why something was done by a certain date, I instead inquire about the complexity of an item. The implication of ‘is this more complex than originally thought’ is that the developer is doing their job. The implication of ‘why isn’t this done’ is that the developer is not doing their job. Subtly of approach respects the individual and lends towards a better delivery.

Give em a say in the Process

Contrary to popular belief, I think most developers actually like process. I’ve worked with dev teams who’ve initially resisted process become dev teams who champion process. The win for the developer is when process produces good requirements, be they requirements documents, or super clear user stories with well thought out acceptance criteria. The other win for process is when the process keeps WIP at some kind of sanity level to allows the developer to do the kind of work they take pride in, and the team to trust the delivery. Monitoring both – clear requirements and scope sanity – will be an immediate win to reducing barriers to process.

Especially when it comes to code migration process, we can really engage developers. Let them create the process while providing guidance that the process should be simple, clear, clearly elaborate roles and serves to ensure traceability. PMs can help by then documenting what the developers agreed to, helping to shore up any holes in the process, and then acting as an oversight on that process. The key is it’s their process, not something that was dropped on top of them.

Course, those three things, appreciation,  trust and communication are the basis of all good human interaction.  PMs, let’s do what we can to make sure that when it comes to developers, we employ these tools to become partners, not antagonists.

A while back I wrote about the Project Management Institute’s 2011 Journal Paper of the Year by Manfred Saynisch.

“Here’s the deal – what Saynisch et. al. are proposing is a fundamental shift if the way we think about project management. We are moving from Project Management First Order to Project Management Second Order. And it’s all about the shifting collective beliefs…. Project Management theories and processes should start incorporating these ideas:

• INSTABILITY IS TO BE EXPECTED
• CRISIS IS AN EXPECTED OUTCOME
• RAPID EVOLUTIONARY JUMPS PROVIDE A CHANCE TO EVOLVE TO A NEW LEVEL, EMPLOYING THE PRINCIPLE OF CHANCE”

As PMs we do expect a bit of progressive momentum on our projects, regardless of the method we choose. If we are in an iterative project, we expect progression to the plan. On agile projects we expect a certain rhythm; standups by day, planning, showcases and retros every few weeks.

But what happens if we accept Saynisch’s idea that we should accept that instability, crisis and rapid evolutionary jumps will occur, just when we least expect them?

Here’s the issue: we have the techniques and tools to plan for crisis (though I would argue most places don’t use them), but we don’t really talk about what our approach will be as Project Managers when control is seemingly lost. How do we, as people, make it through? How do we prepare our thinking for crisis? What expectations do we have about what we will or will not do during those times?

A Short Minor Crisis Story

I have one story, a positive one, about managing through minor crisis. As a program manager at a small company, I had been working hard to raise the level of project management maturity. With over 30 projects, we hadn’t connected projects to strategic programmatic goals and we had not prioritized the projects. People were going slightly nuts.

I (obviously) wanted to get a handle on this. Over time, I developed the relationships to have the senior leadership trust me enough to begin to work on these issues. After a number of months I was able to get all the execs in a room for a portfolio planning exercise.  And the goal was simply, place the projects into strategically aligned portfolios.

Within minutes it became apparent that my plan was going awry. The cool card sorting thing I envisioned was confusing people. And the discussions were moving away from the topics I wanted. And I thought ‘ dammit, I’m about to lose a golden opportunity’. The execs started questioning why there were there. Schmuckers!

But..I had done my research. And I knew where the problems lie and I started to honestly communicate. I admitted immediately that the method I had envisioned to solve the problems had gone a little nutso, but reiterated that we could still solve the problems we faced. Then there was discussion amongst them, and I sat back and let it unfold. Which was hard. I didn’t know where it was going. But the problems we faced had been laid out before us, and we all knew we had to solve them. And then, like instant magic, they decided, en masse, that instead of portfolio planning, they were going to prioritize projects.

And I was like ‘Booyah!!’. That was better than I could even have hoped.  My original plan got thrown out the window (thank God), and during the turbulence between the old plan and the new, the things that helped me keep up forward momentum were:

• the relationships of trust I had with the team (they’re thinking “Michiko’s not an idiot, so I think we must be here for some good reason”),
• the knowledge I had (I’m saying “Hey folks, we have some serious issues to solve here; here’s example 1, and here’s example 2”), and
• it was ok to abandon the method to move forward (“well, looks like the card sorting exercise is a bust, but what can we do to solve our problem”).

And the outcome was fabulous.

It could have gone something like this: I keep trying insanely to stick to a method that obviously was not working, I shut down. I say something like ‘ok, we’ll pick up at some other time.’ They then lose faith in me, I lose some cred. We stop moving forward.

Preparing our Human Project Manager Selves

Saynisch’s model says that we should expect crisis, and out of crisis we will experience evolutionary jumps. I think the implication of that model is that we need to plan and prepare our personal response to crisis.

In other words, what are we thinking when the you-know-what hits the fan?  How do we manage ourselves well, so that we have the right expectations and subsequently help to manage others well?  What do we hold onto and what do we let go to make it through?

What I’m suggesting is that shifting our paradigm to expect crisis also involves shifting our approach to project management during these times of crisis. I thought I would share with you some of my own learning from crisis periods, and how I’ve adjusted my approach to fit those crazy times.

So here are three things that I think happen during crisis and three changes in thinking that I think may help you prepare and manage through crisis.

In crisis, trust relationships trump authority

Trusted enough to run a movement from jail. Master of relationships.

Crisis represents the breakdown in normalcy. And during crisis the normal reporting relationships and hierarchies will not be as important as who people actually trust. In crisis, people will follow who they trust.

Implication: If you want to lead through crisis, develop relationships of trust.

Build your relationships. Work to appreciate people and what they do. If you have beef with people, try to work it out. Make sure you know the names of everyone on the project and understand what they do and how. Take time to talk to people about life in general. Revisit your own methods, see where you can adjust if you have an area that needs work. Read a self-improvement book. Read books about team building.

This Guy (the one standing up)! Knows everything. And no one follows him UNTIL the crisis.

In crisis, knowledge trumps authority

Similarly, people will most likely follow those who know how to get out the crisis, not the stated authority figure.

Implication: If you want to lead through crisis, keep learning; fill yourself up with knowledge. The more you know, the more you’ll be able to quickly connect the dots to develop a plan for getting out of the crisis.

During times of normalcy, become knowledgeable about everything related to your project; how the enterprise works, what systems do what, how communications occur. Most importantly know the intimate details of your project. Read the requirements, read the test scripts, understand the business benefits and know why the enterprise needs to achieve them.

In crisis, forward momentum is more important than method

Turns the method on and off as needed.

During crisis, Its more important that group feels that they are somehow making progress rather than that they are following the norms and rules of methodology.

Implication: Be willing to abandon the method, in favor of forward momentum. And then communicate like crazy, all the time. Because method is really about communication. And you’ll have to pick up that slack.

Be hard on yourself about communication. Make sure everyone knows as much as they can. Walk around. Tell people. Email. Post it on Yammer. Use every form of communication you can to tell people what’s going on.

Avoiding the Shutdown

Here’s what some people do in chaos: Shut down. Stop communicating.

Why? Because they don’t have the knowledge, they don’t have the relationships and they realize that without both they won’t be able to do the communication necessary to keep forward momentum going. And they know that as soon as they start speaking people will realize it. And in extremely chaotic situations, people will stop following them and follow the person who does have the relationships and the knowledge.

Let’s prep ourselves to avoid the shutdown.

Talk Back

So these are just a few ideas to start the shift in thinking. What do you think? What crisis experiences have you had to manage through and what did you learn?