A Rational Design Process: Part 3

Hegel Revisited: Synthesis and Integration

Until the moment when a design can be used by its intended customer, it is not finished. A design is only an expression of intent. Until those ideas are manifested, in code or stone, they are only abstractions. Potential realities that may never exist. It's true that design specifications are difficult to write, and that good ideas are fleeting and rare, but until the design is in it's final form, it's far from finished. Much can happen between the moment the designer finishes the expression of the idea, and when the development team has finished building it.

It is only during the building or development process that many important design decisions are made. The design is a plan and, in the development process, the team may or may not follow it. There are always unforeseen conflicts of resources, politics or technologies that could not have been anticipated by the designer. Someone must lead the engineering team through these times, and drive the project to completion. This person, often called a project manager, may have more influence over the final design than anyone else on the project. They decide if a feature should be cut to balance a late schedule, or how unexpected engineering constraints will affect the planned design.

Some teams encourage designers to be as involved as possible with the engineers, helping them to maintain as much of the design continuity as possible. But often it's the project manager that bears more responsibility, and has more rapport with the engineers. In the best situations managers and designers are partnered like movie directors and cinematographers, relying on each other's strengths and dedicating themselves to a shared vision for what the outcome should be. Some project managers and developers go further, and grant significant engineering decision making power to designers. This can be ideal, provided the designer is prepared for the greater responsibility involved. What follows is some advice to project managers on how to think critically about these aspects of their position, and how designers can get the most out of their project managers.

Work for the people you work with

American culture offers many myths about leadership. We are asked to believe that leaders are the ones who give the orders, and who establish positions of visible dominance over the people that work for them. These notions should be dispelled. If you work with intelligent and well meaning professionals, the dictatorial style of an army sergeant is destructive. It forces people to take lines of opposition or defense, and discourages them from offering you their best ideas. Critical thinking for managers requires an understanding of different styles of leadership, and assessing which style suits you, and the team and project you are working on. In some situations force is necessary. However, you should always be clear on how and when you are using it, and make sure you consider other ways to get things done.

An important consideration to make is the difference between earned authority and granted authority. You should want your team to follow you because your ideas are sound, not because you have a certain job title. As often as possible, decisions should be discussed before they are made. Allow your team to review your draft plans, and give feedback before important changes become final. Email can be a great mechanism for quick discussion: inform your team what your deadline is, offer the problem and your intended resolution, and ask explicitly for feedback. Be brief, and allow those who are concerned about the change to seek you out and discuss it with you. Keep an informal web log of new changes as part of your design specification for reference and to maintain continuity. In general, it is better to over-communicate to your team, than under-communicate.

There are psychological advantages to an open view of the role of leadership. See the role of management as assisting the people that you manage, instead of driving them. As often as possible, make the relationship feel like a partnership, not a hierarchy. Stop by each person on your team every few days, and ask "Is there anything I can do to help you meet our team goals?". (note: I am currently working with a Program Manager that literally stops by my desk and says this exact line: "What can I do to help you meet our goals"). Offer yourself to them. They are the talent that creates the work, and your job should be to maximize their happiness and productivity. Help them to be effective. Take responsibility for removing their political or organizational roadblocks. Even if they ask nothing of you, making the offer to help changes how they see you and your role. When the day comes that you need something extra from them, they'll see it as reciprocating your behavior. Leaders create a sense of teamwork and morale by offering of themselves, not by demanding of others.

All good partnerships require that you encourage people to be honest with you. Learn to listen and work to understand their perspective. Encourage the intelligent and wise on your team to question your thinking: if you can't provide good reasons for your decisions, then maybe you're making the wrong ones. Remember, the goal isn't for people to do what you say, or for you to be right all the time: it's to ship the best possible design. With an open approach, you establish the lines of communication that help you achieve that goal.

Goal clarity

Goals were discussed in the part 1 essay , but they deserve more coverage in the context of project management. Goals are your foundation. If you never know where you're going, you are unlikely to get there. Without goals, everyone will slip into their own direction, and fracture any sense of unity in the work that is produced. Goals should establish what tradeoffs will be made, and which aspects or components of a project will be placed before others (is schedule more important than quality? What are the business goals and do the design goals line up with them? What features will be cut first if necessary?).

Goals are glue: they keep the team bound together from the inside, moving in a single direction. Everyone on the team should feel like the goals are theirs: not something handed down from above. There should be a period of time where drafts of the team goals can be reviewed and discussed. The challenge for a project manager is twofold: first, to define goals that are specific enough to be actionable, but broad enough to flex with the circumstances that will arise. Second, to maintain composure and balance as things go wrong and adjustments are needed. The ideal leader is strong, but supple. They know to bend if there is too much pressure, but still maintain the integrity of their team and the project goals.

Get Aligned - Resources aligned with commitments

From the project management perspective everything is a resource: people, time, equipment and money. Whether you manage the assembly line at Ford, or updates to the website home page, the basic process management principle is the same: maximize the alignment of your resources with your goals. Whatever your goals are, your job is to manage the available resources to fulfill those goals. This can work at the project level, as well as the division or corporate level. Depending on your scope of responsibility, the breadth of the goals you consider will change.

One easy way to review alignment is to list every work item that your team is scheduled to do. For each item on the list, write in the team goals that the work item will help achieve. If you can't find a connection, something must change. You do not want resources being consumed for things that are not part of your goals for the release. They should be reallocated towards other work items that are better aligned. Exceptions can be made: in rare cases there is a surplus of resources, which gives you flexibility to invest in less essential, but potentially beneficial, work items. However, the process is of matching work items to goals forces you to make those exceptions explicitly, instead of allowing them to occur unintentionally. Decisions made unintentionally are the bane of project management.

Bonus: If you are doing well, your teammates will voluntarily review their own work and ideas, and fit them into the project goals. The investments you make in creating partnerships with your own team, and growing morale, encourages this to happen.

Conducting the orchestra: Communication and Synthesis

Project managers do not make anything themselves. Their primary obligation is not to write code, test code, or run usability studies. The true domain of management is communication. Listening to problems, considering solutions, and catalyzing change through interaction with others. The best managers are the best communicators. They develop their ability to translate between the dialects of developers and designers, or businessmen and lawyers. The more effective you are at expressing or understanding points of view, the less time you will waste arguing with people about them. If you can't master human to human interaction, how can you master human to computer interaction?

Bringing designs to fruition requires many disciplines: development, test, business, design, usability, documentation. Unifying these divergent contributions into a single website design is a synergistic task, and synergy is much harder than entropy. It requires master level skill to bring these divergent contributions together into an organized, meaningful, and unified single expression. Every orchestra needs a conductor. Every film needs a director.

However, unlike music or film, the people we trust to bring everything together in the web and technology industries do not often have broad sensibilities. They often have limited knowledge about each of the different domains that contribute to good work. They are more likely to be technicians than artists. This is unfortunate because synthesis is an artistic process, demanding a broad awareness of how everything effects customers, combined with knowledge of the engineering complexity involved. Great project managers are great integrators, and they are rare.

What's required are the same sensibilities found in great architects, film directors or music conductors. To develop those senses, you have to explore domains, outside of our narrow industry, that have been balancing the diverse objectives of design projects longer than we have. Learning how film crews manage the process and complexity of production will provide insight into how you manage your team and web production. Understanding how directors manage actors, studio budgets, cinematographers, and screenwriters will enhance the perspective of any web or software manager (Are designers our cinematographers and art directors? Are developers our actors? Testers our editors?) Become a student of the masters of synthesis, and learn about design integration wherever you can.