I attended a conference several months ago where the CTO of a small development company was adamant about one thing: Making excellence a standard should be a focus on getting teams to work together. This is not a new concept, but one any successful organization embraces.
Around the same time, I ran across Robert Martin's 'Whiners that Fail' post at objectmentor.com. In it, he basically addresses how there are those who will complain about having to pay for things like white papers and how those people expect employers to shell out cash to make their own personal lives better. His point? "YOU are responsible for YOUR career and no one else."
I agree with that statement strongly, but not just because I realize my boss or company is not my mother. This mindset extends to how we deal with our work lives, especially when confronted with managing a problem project with difficult people, systems and requirements. How we take responsibility for our own lives/work/projects makes all the difference.
Making excellence a standard should be a focus on getting teams to work together. And part of that excellence model? Establishing excellence is not whining.
A somewhat recent example jumps to mind. A project I'll call Vortex does a bunch of stuff: It retrieves some records, manipulates them, massages them, then makes them reportable (allegedly). There are several environments at play, including flat files generated from a mainframe, a monolithic database, some half-working Java-based Windows apps, and some database engine processing. It's slow, it has jobs to run jobs which may or may not run, has entirely too many moving pieces, and is a mess overall.
The point is this: Even the very nature of its architecture is suspect, but it's way too late to even entertain gutting the overall project and rewriting it. While it can be shown we spend thousands of dollars on it, the millions it would take to recreate it from scratch mean we're pretty much stuck with it. Most large companies have at least one of these.
Of course, there are way too many voices in the conversation when it comes to making changes to it and in determining how those changes should be facilitated. The rules of overall agreed process are regularly overruled by political demands. Roles are unclear or dismissed altogether, process is conditional, and the support requirements are incredible. The ongoing support alone is a medieval gauntlet–those who survive may not have been eaten by lions, but would probably prefer it.
It becomes very easy to complain about a project like this. It almost encourages a chant of bonding where all involved fully agree with only one thing: It sucks. Have you been on a project like this, where everywhere you look a process or procedure or design is broken? A project like this truly has the potential to become the thing that ushers us all into Armageddon. Or at least wish for it.
If you are (un)fortunate enough to manage a "Vortex"-type project, you can bet everyone involved already knows how bad the project is. The very last thing you must allow is the introduction of complaining into the equation. As a manager, you must not tolerate it. All whining does is choke the team and encourages an attitude of negativity and blame all around. Encouraging a bad attitude happens to be the exact opposite way of pulling a problem project out of the miry clay it has lived in up until now.
Here are some steps to start shifting the mindset on a "Vortex" project into one of excellence:
- As the blessed manager, make the decision to stop the negativity in its tracks. Beginning with you. You hold the keys to raising the bar, so you need to check yourself first before you take the position of checking someone else's behavior.
- Regardless of your role, make the decision to be solutions-minded. That means for each of the items you find wrong, think of possible solutions to fix them. Don't just complain, think of ways to fix what you're complaining about.
- Take the solutions mindset into every meeting or discussion you have with anyone attached to the project. As a manager, you are responsible for establishing the atmosphere in the meeting. If needed, even draft some 'rules of engagement' of what will and what will not be tolerated.
- If a role identity crisis has occurred, clarify the roles and who belongs to them. This can take some time, but it must be done so there are no misunderstandings about who should do what. Chances are the upper management must make this clear to everyone involved to ensure it sticks.
- Hold a separate meeting or brainstorming session to identify and consolidate the issues causing the torment. It is a safe bet everyone has their own list of what is wrong. You may need more than one session to hammer out all of the details.
- Draft an attack plan with your team to deal with each of the items recorded in the above meeting or meetings. You are not "the hero" here. Your team must help create the plan and buy into it. Period.
- Execute the plan. Execution will take some time to do well and will likely face resistance, even after the pretty plan is drafted. Stick to the plan and revisit it often, tweaking it when necessary. It should be recognized this will be painful, but not any more painful than the grip the Vortex already has on you and your team.
If you're the one whining or allowing a spirit of complaint to dominate your project, you are intentionally taking away from the one thing that can fix a bad project: your team. Spend that ill-spent energy getting in small groups with your team to knock out an attack plan, then focus on conquering the enemy--disorganization, undefined issues, stakeholder strangleholds--one battle at a time. If you can realize your team and you hold the keys to escaping the Vortex, you may just do it.