In a book that I’ve been reading recently, I came across the following sentence “Each time, I ask what the problem is, and we get to it immediately. I like to keep a handle on all my [projects], and the problems are to be expected. The time I worry the most is when there aren’t any problems. That’s usually the result of misinformation or wishful thinking on someone’s part.” — Donald J. Trump, How to Get Rich, ISBN: 0-345-48103-8
This statement applies very well to software projects and yet the number of meetings I attend where anything but the truth is presented absolutely astonishes me. Stubborn, blind denial of the actual forces at work and the actual state of the project is peppered throughout one-hour status meetings that accomplish little beyond irrepairably interrupting the momentum of the team. I hate long meetings. I also hate unnecessary meetings. I hate most meetings in general. There is nothing worse than attending a droning waste of corporate expense and momentum that is filled with long-winded pleasantries and editorials, each of which are masking the intent of the meeting and sapping the attendees energy. Most meetings could be disposed of if more people took a commitment to the truth and reality of a situation and spent a little time working on their communication skills.
Meetings have their place. Collaboration is an essential part of successful projects and it is often necessary collect all or some of the members of a team together to discuss important issues and share critical information. However, most meetings achieve neither of these goals and can often cause a project to be pushed further from success by wasting essential forum time. There are a few good windows within any project during which certain critical issues can be raised. Wasting these opportunities will mean that any subsequent attempt to raise the issues will fall on deaf ears. If you waste a busy executive’s time with waffle and whining, she will be far less likely to grant the team an audience in the future. This goes not only for high-level decision makers but for every member of a team. If the team writes off a scheduled meeting as a waste of their time, they are less likely to listen or contribute, merely showing up for their face-time before returning to their cube to continue the day.
This is where the fine line between negativity and reality must be walked. Whining is equally as unproductive as masking the truth. Presenting an endless list of unsolvable enigmas just makes the team sound like a poor fit for the project; they have no possibility for success so why bother to continue funding it. Raising endless spin and sales talk to make the project sound like a flawless success will either raise real suspicion in a seasoned strategic executive or convince a less-aware manager that everything is fine, thus wasting the opportunity to solve real problems. The most beneficial path for all concerned is to raise the honest issues and problems, undressed, with a clear understanding of what it will take to solve them. An executive, be it the CFO of a fortune 500 company or a recently promoted tech lead that used to be a peer developer has a job to do just like every other team member. Their tools differ in that instead of a development suite and available servers they allocate budgets and manage long-term risks. It has been my experience that raising clearly identified problems with proposed solutions in short and focused meetings can work wonders. Lay the problem out quickly and concisely at the correct forum and with the appropriate amount of research to answer any pertinent questions. This to me is the essence of effective reality and it will eliminate the need for the other 56 minutes of a one hour meeting. An agenda is *not* a good forum for the presentation of problems in detail, nor is it a sounding board for in-meeting sub-agendas and politics. Simply including a line “Review current problems.” is perfectly legitimate, although many people balk at the inclusion of a problem review in a meeting and would much prefer to word it differently; “project status review” for example. However, this does not adequately prepare the audience for the purpose of the agenda item and presenting problems with a project at that point might feel like an ambush. Keep the agenda honest and professional and the meeting will be much shorter and much more effective.
Negativity is a poor contributor to any project. We’ve all encountered it and I know that I’ve contributed in my time to it. That doesn’t mean I don’t recognize it and don’t try to move past it and improve away from it. However, there is a difference between negativity and reality. I’m often painted on projects as the guy who constantly raises problems and is quite negative. This bothers me as I generally consider myself to be a fairly positive and cheery person, but it gives me enough cause for thought to think about where the comments are coming from. What I’ve found is that there is a mixture of genuine negativity at times, usually when I’m worn out on something, and a healthy dose of reality. The negativity is just wasteful and needs to be removed, however I only ever see positive results from turning up the volume on reality. Let me also qualify here that there is a difference between identifying and presenting legitimate problems with a project and simply being a whiner. I’ve worked on projects with whiners and it sucks. Raising legitimate problems with a project entails with it the requirement to present a proposal for a solution to the problems. That’s where the power of reality in a project conversation comes from. Unfortunately, it is easy to mistake one for the other and transpose the disadvantages of a negative attitude onto the genuine advantages of a realistic view of a project.
I keep a journal of all of the meetings I’ve attended in my career, paying specific attention in my notes to those that violate their own potential efficiency. I started doing this as a way of relieving the torrential boredom of being a participant in such gatherings, but have since kept it up and formalized the practice as it makes for some great material later on in projects when people stop to wonder where all their precious development time was spent. There are several in which I noted down in the first few minutes of the meeting what the obvious cause of the meeting was before the presenter had even finished their long-winded introductions and pleasantries. I would write things like “so they’ve just realized that [X] product and [Y] product can’t release together and that will hold up [Z], costing us an additional [A] development hours…finally!” However, instead of just stating that fact in the opening couple of minutes of the meeting, an entire pomp and circumstance is observed to carefully dance around the outskirts of the truth, weaving tales and excuses around the real reasons for the problem. By the time the point actually emerges from the sand, most people are clearly convinced that nobody did anything wrong, no mistakes were made, nothing really failed in the process. The team simply ended in an unfortunate and unforeseeable situation that has caused the project to go over budget. Everyone walks away having learned nothing and with absolutely no intent to change any part of the process in the future.
Everyone in the room knows that this meeting is 90% fabrication, 8% spin, and about 2% truth. The fact that no project plan had ever been put together, that no strategic questions had ever really been asked around the integration of the two separate products are excused away in a whirlwind of great sales talk. There are a few points I’d like to make before continuing. This is not an actual recount of a meeting that took place, it is a fabricated situation that has been echoed on many projects in many forms over the years. I’m not picking on any one particular instance here, rather I’m trying to lay the framework for an argument about the power of constructive problem identification. By the time the meeting has concluded, so much has been said about everything that was done right in the project that no action items are taken away beyond “we have to push the deadline”. The developers of the project quickly meet to figure out how to hack [X] and [Y] to work together for [Z], scope the work to fit the new deadline and then return to their cubes to work on it. However, before we leave this case alone, lets travel back a few months to the originations of the project and look at some of the meetings that took place then.
A project was conceived. A half-baked idea made its way into an executive summary in response to a sales idea that would solve problems with a current product line and ostensibly increase profits for the department. The half-baked idea was cut and paste into a funding summary, approved, and then cut and paste again into the opening section of a requirements document. A small development team was formed, the senior developer was named technical lead and people started to write code. The tech lead knew that this was leading towards failure. There was no formal project plan, the deadlines aligned with trade shows at which the company wanted to show off the product, and the requirements were little more than a half-baked paragraph from an executive summary. Weekly meetings were set up with the department heads and the tech lead and a daily meeting was set up between the tech lead and his team of developers. A build server was created and configured, source control was established into which a framework solution was added. The tech lead spent a few restless nights thinking “how are we going to integrate with the other team’s product?” (a subtly stated requirement in the executive summary about ‘third-party integration’) and worrying about the fact that no-one had actually tasked the project out to verify the deadlines. However, this is about the only point that isn’t raised in a meeting, instead the content is focused on the positive progress items and how much code has been written.
In the weekly meetings, a status report was delivered, and action items were created for “discussing third-party integration” and “formalizing a project plan”. Integration was left to the developers and the creation of a project plan was little more than an exercise in ensuring lots of little tasks conformed in concert to the previously stated deadlines. The tech lead wrote a few emails formally stating his concerns about the lack of integration planning and the lack of a realistic project plan, which were comfortably summarized by the department heads in more senior level meetings. Having performed sufficient CYA, the project then continued unabated until it reached the inevitable conversation about slipping deadlines and integration problems.
We’ve all observed situations like this in one capacity or another, either as a developer, tech lead, or a department head. Despite many opinions to the contrary, no single person is at fault in this situation. However, this situation could have benefited greatly from a few well placed observations quite early on in the process. The problem here is that no-one wants to be labelled as a whiner and as a result they will very often hold back the real issues that are burning in their minds and instead state rather pedestrian facts more appropriate for a written status report. The worst part of this situation is the fact that no-one learns from it. There are no action items taken away to improve the process in the future. Nothing is learned from the process and so its failure does not even serve as a warning to others.
Finding the correct opportunity to present observations of problems in a project can be hard. It is almost as fine an art as putting corporate spin into a meeting to maintain smiling faces. It might be prudent, however, to put some of the time and effort that was previously aimed at such spin into that art and to find the most effective and professional way to deliver the bad news. Status reports are ill-chosen locations for such feedback unless it was directly solicited. A crowded staff meeting is also a poor forum for information that most people in charge might not want to hear. Next time you’re on a project with little to no requirements, no project plan, or a glaring flaming elephant that no-one wishes to acknowledge, try the following and see how it works. First approach your project manager, tech lead, or department head, whichever you have the most “accepted” direct-report contact with and hence avoid going over someone’s head. People in charge really appreciate knowing that their reports will raise problems to them first and give them the chance to save the day versus watching over their shoulder for the next dagger or e-bomb. Schedule a short meeting with them (no more than five to ten minutes) and be sure to get to the point almost immediately to show that the time they set aside for the meeting is important to you. Depending upon your relationship with them it may be sensible to preface with “I’d like to raise some observations to you that I have made about our project and get your feedback on them.” That lets them know your angle and where you’re coming from with this, that its not just a social chat or salary negotiation. Don’t prepare a ton of handout material or do anything fancy like haul in a portable projector. A simple “I took a few notes” in your notebook will suffice. Present the problems cleanly, without window dressing, and with both firm ramifications and potential solutions. “I believe that project [X] is not going to integrate cleanly with project [Y] because the interfaces have diverged. This will hold up our launch and cause us to miss our deadlines.” Present a copy of the project [X] interface, with which the manager is familiar, then presents the project [Y] interface that you have researched and highlight the problem areas. “I haven’t approached the project [Y] team yet, but I think they’ll run into a similar problem unless we collaberate.” Don’t seek credit or place blame, this isn’t a career moving meeting, this is a way to make your project, and hence your life, much easier. Try to establish within the team a feeling that they can talk to you about such problems and set a clear example of the format that is most useful, this will encourage the culture of the team to tend towards a more effective working habit.
What if the meetings themselves are the problem?
The issue I have raised the largest number of times throughout my career is that of wasteful meetings interrupting momentum. Momentum is very important to me in a day and, once interrupted, can take some time to get going again. If the purpose for the meeting can be fulfilled in another way, by the team’s culture of open honesty and clean, efficient communication then I have found that most managers are willing to replace daily meetings with weekly updates from key team members. This is all down to a question of your own working taste and how your team works. I’m not dictating whether morning meetings or daily stand-ups will work, rather that a clean presentation of a problem (even the presentation that a daily meeting is the problem) can often produce unexpected and great results. I expect people working for me to get to the point quickly and cleanly and take up as little time in a meeting as is necessary. Sometimes it is essential to gather team members together to resolve a pressing problem, but if the same can be accomplished via e-mail then simply write it up and don’t break my momentum for the day.
Where are we?
I started on the difference between negativity and reality and I want to conclude very quickly that I feel most failed projects have incorrectly tipped the scales in favor of negativity without meaning to; in fact through an ironic intent for good. Although most teams start without much negativity, a lack of reality and the subsequent problems it brings soon lead to a very negative and defeatist vibe within the team. As oversights (an odd word in most usage) are both seen clearly and ignored, deadlines become tighter, real issues are hidden from management and then become too large to reveal, and the team is beaten upon to finish a race they can’t win. The lack of early reality leads to a heavier negativity as the project progresses and hampers any chance for expressing the reality of the situation. Whereas by taking a firm stance early on to accept that problems will crop up and are nothing to be feared, a more realistic view of the project can be taken right from the start and those problems can be dealt with quite easily and effectively. Choose your audience carefully, research the problem sufficiently, and present the problem without window dressing. Establish a reputation for getting to the point and presenting well-researched proposals and you might find that facing the truth bears much richer fruit than hiding it. As I stated before, I have been guilty of both negativity and failure to effectively communicate on many occasions. As with everything, I’m trying to analyze the outcome of my decisions and actions, learn from them, and develop a better understanding of how to garner success in the future. Every person in a team can improve the quality of a project and a commitment to clear and effictive communication of reality seems like a great place to start.