[](https://plus.google.com/+BrunoOliveira/posts/B9eSCNK7oNe)Project management is a weird thing I tend to see projects from a developer stand point. How do I organize this project and gather as much information up front that I might empower my team to make decisions about the project? I think this way not because I am a great project manager, but because of my exposure to the kind of tasks my team is expected to preform. It is profoundly more complicated than that it’s a good way of thinking about the management of a project. Working with developers and being a developer in my free time I have noticed a trend in the development community that I think underlines a larger problem that I want to address. This chart in recent history May”ish” 2013 made the rounds. It landed in our group chat at work months later. It received many resounding hear hears and huzzahs! from portions of my team. > How can I reestablish the thought train after a catastrophic derailment that killed all the passengers and left the conductor a shivering husk of a man. Who is only able to mutter "it was just a penny" over and over again. I can honestly say to a certain degree I shared their enthusiasm about the illustration. It does not resemble my own productivity, I am a morning person, I can relate to it. The part that really got the attention though is the interruption graph. It got me to looking over the internet for articles about interruption. How can I help my team be more successful I asked myself. So I began to read and learn and see if there was something I could change about the way I do things to minimize this effect. This law of nature. How can I reestablish the thought train after a catastrophic derailment that killed all the passengers and left the conductor a shivering husk of a man. Who is only able to mutter "it was just a penny" over and over again. This is when I discovered that apparently interruptions are considered the modern plague of developers and creative types around the globe. Never before has there been such a undercurrent of productivity killing poison. So what to do about it? As a project manager interfacing with multiple clients, developers, designers, marketing people, and researching, documenting, and generally being, both the decision maker and the man in the gap. My work week can sometimes be one long interruption. Granted larger tasks like, researching and scoping tend to make me close my door and put up a do not disturb but for the most part I am a man interrupted. So my first course of action in my quest to limit the interruption of my developers was to interrupt them and ask what their major source of interruption was. We have a unique situation at my company. We have a sister company that grew out of us in the same building as us. Their needs and requests over IM, email or in person were not a major problem by themselves, you throw in the few that I had, a few that come from the ukrainian team and my developers had several sources of interruption. If they were not staggered they could really destroy a day of progress and frequently did. I began to do what I had full control over limit the interruptions that came directly from me. As a project manager at a web development company I began to do more than my job. I had knowledge of HTML, CSS, Javascript, Java, PHP, and a host of smaller less complicated web technologies. I helped with support, fixed things where I could and only interrupted when I absolutely needed to have an answer, help or when camaraderie and morale were more important. This seemed to mitigate a portion of their distraction but I found that the other sources of their distraction were still significant. So I made efforts for everything to be filtered through me. This seemed to mitigate things to a reasonable tolerance. Some of the complaints about distraction stopped and I asked them to be more vocal about where they were at in projects so I could make better decisions about the time we would spend working on projects. All my efforts though mostly effective, somedays better than others, did indeed limit interruptions. It was still a struggle when I did indeed need to interrupt. There seemed to be an undercurrent of resentment not just in my team but in the developer community at large. This idea that development is this art form that has a group of people that are non normative. Having spent time as a developer and now as a project manager I would argue that there is not a normative person in any profession. I would also point out that this mentality of "this is when we are effective" and "this is what interruptions do to us, see its your fault" is extremely damaging to the community and how they are viewed. ## So what is the solution? I have thought about this over the months. There is not a hard and fast fix. There is however a cultural vision that I think if we worked towards it everything would become better. We need to have both "project management” or in this case I will call it non development team members and development team members to come to a unified view of everyone. I would call the over all vision a unified, trust, ownership and dedication/vision to the team as opposed to members in the team or a particular department. What does this look like? > I would call the over all vision a unified, trust, ownership and dedication/vision to the team as opposed to members in the team or a particular department. Well you have to ask yourself do you need your team members? Some will say no! I could do this alone. I feel that way sometimes. I could roll my own web service and start making some money without ever touching any code. A developer could interface with a client, scope the project, and manage overall expectations and they do! You have to ask yourself though is that what you want to be doing. So we all need each other for the most part. Some of us have to “decide" we need each other. We need to trust one another. Sure, bounce ideas off of each other, disagree, argue, and brainstorm for the best solution. In the end team members should be trusted for their expertise. I am not saying you should not challenge each other but a developers expertise is important as long as they understand the limitations. This trust must start with non development team members and it must be reciprocated by the development team members. If a project manager says we have 15 hours in a budget to do feature A then the development team should use their expertise to solve the problem within that time. If there is time to hash out a plan and scope it then the non development team should give their development team a chance to do that. All parties should trust that the other is working with in that trust. The development team needs to acknowledge the expertise of the non development team especially if they do indeed know what they are talking about. I can’t count the number of times I have pointed out mistakes in projects only because I know what is going on and I have the 1000 foot view. There has to be trust there if someone is to forget the path. Especially when you take into account ownership. We should all own the victories and mistakes. This is where I get a little hard on non development team members specifically those considered the leaders. If your team fails then you stand in the gap for them. Hold the blame and let it wash over you. The non development team should prop your leader up give him or her the tools they needs to either A) defend the outcomes or B) explain the problems. Own your failures to him or her later. Leaders when your team succeeds you need to make sure that you point to the team members by name that made the victory possible. That is your reward you get to be the one that waves the banner. The last one is certainly not the least. Dedication and vision are coupled together because you can not have one without the other. If there is a vision one that we can all get behind then we have something to work towards. We can lock arms, dig the trenches, and pave the roads to the goals. The vision needs to be more than profit though, it does need to be part of it. Something like a profit+ kind of vision. Where I work we have been in business for 10 years and we have a vision Imagine, Create, Deliver and the unspoken Profit. The profit is there because we all want to have jobs and get paid. We went through a hard time chasing profit because profit was elusive. We had to have profit because we have to stay in business. Now that we are beginning to gain some ground again what we have found is the the imagine, create, deliver has gone by the way side. So we are doing the hard work to get back there while dragging profit kicking and screaming. A lot of that work looks NOTHING like imagining, creating or delivering. It looks a whole lot like the same plus some cleaver office management. We have dedication though, true sometimes we have to be reminded. Sometimes our feelings or desire for the fulfillment of the vision clouds the work in front of us. So we dedicate ourselves to each other 8:30 - 5:00 Monday through Friday we work knowing that even if it does not look like it we are making steps towards the vision. A change like this in the culture of web development and the management there of, would make the industry that much healthier. I might go as far to say that it might usher in a new renaissance. We would at least quit seeing graphs like this that really embody complaints rather than solutions. [Or reading articles that tell us our team members are literally dying]( http://www.businessinsider.com/syndromes-drive-coders-crazy-2014-3 "Literally Dying"). I hate this about our industry but I love my team. <iframe src="//www.youtube.com/embed/JwU7SF0i0Ws" height="315" width="560" allowfullscreen frameborder="0"></iframe>