The 80/20 of Team Cohesion

Olin excels at creating many opportunities for group projects from the very beginning of the curriculum and in extracurricular teams.  Within those group projects, the Olin faculty attempt to impart some skills around team conflict resolution, proactive reflection on work styles, and advice on how to give feedback.  I found much of it to be valuable, but there is no compendium of this advice to my knowledge.  It was often delivered in lectures, sometimes in videos, and also in direct guidance given to teams.  Much of it could be written down to advance the broader project of innovation in engineering education, but also to guide practicing engineers today who did not receive the same kind of instruction.  Here I hope to describe what I believe are the simple ways to solve most team cohesion problems, with a focus on setting up good structures to not merely prevent conflict but promote growth.

How do we not merely resolve team conflicts or try to prevent them, but promote team cohesion?  Here I try to present a few simple ways to improve the fundamentals of cooperation within engineering teams, though I believe much of this is transferable to any professional setting.

1. Respect: This is the foundation for professional team cohesion.  Most people already have a sense of what this is, so I will describe the single most important attitude that promotes it.
   1. The Learning Mindset: Engineering organizations are learning organizations.  Each member is learning, as is the institution as a whole.  From the newest member to the most senior expert, everyone must constantly grow in technical and interpersonal skills.
      1. This perspective teaches that everyone has the potential for contribution, even if they currently lack certain skills.
      2. It instills humility.  Everyone must be aware that there are still things to learn as individuals, that the institution does not have everything right, and that it may have to adapt to change.
      3. It promotes collaboration, because the best way to learn is often from the practice and expertise of others.
2. Begin with the End in Mind: The organization must begin with its final result in mind, which might be the products delivered to its customers or learning among its students.  It also must focus on its “end” in the sense of its purpose, which could be to “organize the world’s information” or “innovate in engineering education”.  Within Amazon, “being the Earth’s most customer-centric company” translates this into the principle of “Customer Obsession”.
   1. Work Backwards: Teams accomplish this by starting from values, such as safety, customer satisfaction, frugality, or environmental impact.  Then, by deriving evaluation criteria from them and means of experimentation or assessment for different solutions.  Finally, by generating ideas for solving these problems and working together to develop them.  This ordering of values, criteria, and designs directs everyone’s attention to the common purpose first, and avoids having “solutions (such as certain technologies) in search of a problem”.  Solutions are chosen based on their fulfillment of the institutional goal and not the standing of their proposers.  See the “Generative-Evaluative Design Meeting Style” for how to do this in detail.
   2. Align Individual Success with Team Success:
      1. In a commercial setting, everyone’s goal is to deliver value for the customer.  Create incentive structures that reward achievement of this common goal along with success in individual contribution.  Contributors who did more should be recognized, rewarded, eventually given more responsibility, and should mentor others; but success of the individual is not possible without success of the whole.
      2. In an educational setting, individual learning goals should be aligned with completion of the project objectives.
   3. Minimize Assignment of Blame: Suppose a bug in the code gets to production.  The focus should not be on assigning blame to the author, but assessing the processes that allowed it to happen.  Was there a code review done?  Was there enough time to do the code review?  Was it perfunctory, or were honest efforts applied to it?  Were there unit tests for the code in question?  Were there integration tests?  Were those tests insufficiently representative of real cases?  Was the task clear?  Was there sufficient detail in the design document?  In general, the goal is to find a process or “mechanism” that could have prevented the problem, and if there were already mechanisms in place but they were not followed, then the appropriate action (depending on the severity of the issue) is to reemphasize training or documentation for this process.  Engineering organizations are learning organizations, and it is expected that sometimes things go wrong.  The assignment of blame to a specific person is typically unproductive and does not advance the common goal.
3. Professional Development: The organization must proactively create opportunities for professional development of all of its members, and align that development with the objectives of the whole.
   1. Regularly state and review development goals:
      1. In school, at the beginning of each project, and at least every semester for extended projects, have everyone explicitly state their technical and professional development goals.  For example, on a robotics project, one person might want to learn about network communication protocols and scrum management.  Another might want to learn about end effectors and improve in technical writing.  When reviewing the distribution of work among the team, make sure that some of each person’s goals is fulfilled.  It might not be possible to accommodate all development goals within the confines of the project, but given that learning is the major objective within school, it should be prioritized.  Further, team members will contribute more effectively when they are motivated and their work is aligned with their learning goals.  Balance drawing from the prior strengths of each team member with presenting opportunities for developing new skills.  Periodically check in as a group for progress towards these learning goals and allow for updates to them.
      2. In industry, there is necessarily a stronger emphasis on utilizing each member’s current expertise to meet the needs of the business.  There are fewer clean delineations between project cycles than in a school schedule.  For these reasons, the team and especially the manager must intentionally review opportunities for professional growth that align with the delivering results for the customer and each member’s development goals.  Emergent business demands will naturally interrupt the intended flow, so the manager and member should regularly work together to adapt the development plan.  All members should be proactive in documenting their goals, and in identifying opportunities for growth.  However, the team should not artificially create tasks just because someone wants to learn something new.  For example, suppose someone wants to use machine learning in his work.  It would invert the pattern of “working backwards” to try to use machine learning in a project just for its own sake, and would lead to a suboptimal design if machine learning wasn’t actually needed.  Instead, that member should review problems that the business faces to find ones where machine learning would provide value.  His manager should help him connect with other teams to learn more about potential opportunities.  In general, team members should have at least quarterly reviews of overall career trajectory and growth plans.
      3. A regular and formal review process ensures that everyone’s development goals are heard, which promotes common feeling within the organization.  Publicly stating these goals also allows others to give advice on how to pursue them.
   2. Growth Mindset Over Scarcity Mindset:  Everyone (or nearly everyone) wants to learn in school and grow in his or her career.  The team will cohere and succeed when everyone believes that opportunities for development will increase with the success of the organization, and that opportunities are not scarce.  Following from the previous example, as long as there are new ways to serve the customer or learn new skills (which there always are), opportunities naturally abound.  If instead the solution space is constrained and organizational processes cannot be revised, opportunities will seem limited, which can lead to a zero-sum perspective.  Focusing on the end goal and not the internal current state will help to instill the collective growth mindset.
   3. Distribute work among the team by type, urgency, and tediousness: There will always be tedious tasks that are too heterogeneous to automate, or fires that need to be quenched but get little recognition, and these tasks should be spread among the team intermixed with the main technical challenges so that all members are given opportunity for growth.  Not distributing urgent work leads to disproportionately fatiguing certain members.  Failing to spread the tedious work leads to boredom.  Without conscientious review of work assignments, these negative effects can compound.  In a professional setting, the same people may work together for years, so patterns of interaction can settle with certain people taking on specific kinds of work.  Team members must be intentional about not developing silos of expertise so that many different perspectives can be applied to the same problem space and the organization can be robust to movement.
4. Clarity of Commitments
   1. State commitments at the beginning of each project, periodically during the project, and as new events arise.
      1. Use a project management and work tracking system to make it clear what everyone is working on, and who owns each task.  Regularly update the status of tasks.  A regular scrum meeting fulfills this.
      2. Promptly communicate external demands such as family responsibilities so that the team can be mindful of what each person is experiencing and redistribute the work as needed.
      3. In school, at the beginning of a team project, everyone should state their course load, expected extracurricular commitments, and family responsibilities.  All members should also state if they want to make the project their focus for the semester.  Is their aim a job well-done, or do they want to go above and beyond what is required?  Explicit acknowledgement of what everyone is signing up for at the beginning facilitates common understanding and helps to manage the workload through the project.  For example, if someone expects that she might have external commitments arise through the course of the project, she and the team might plan to complete the work early to allow for more flexibility in the schedule.
      4. Management of commitments in industry follows a similar pattern with the addition of long-running ownership of products and services.  The creator of some product naturally becomes the subject-matter expert, and if he does not document it and train others on how to support it, he may have an unstated and irregular commitment to teaching others about it.  Answering questions might not rise to the level of an explicitly acknowledged task within the work tracking system, which can undermine the clarity of commitments.   To maintain this clarity, avoid repetition, and propagate knowledge, the team should have common documentation of responses to support questions.  Depending on the intensity of the inquiry burden, it may be appropriate to have a rotation among the engineers for answering questions each week and improving the documentation.
   2. Unity of ownership:
      1. Every task has one owner.  It must be clear who is responsible for each task.  If that owner needs help, it is his responsibility to ask for it, subdivide the work appropriately, seek guidance, or have someone more suited to the task take it.  Such tasks range from the smallest code submission to the delivery of a contract to a customer.
      2. Single-threaded Owners: For each solution-level deliverable, such as a product that enters a new market, there should be a “single-threaded owner” who is working exclusively on it, and is ultimately responsible for the product performance.  Not every task or program will be large enough to require a single-threaded owner.
      3. Responsibility of routing: Every problem requires an owner, and it is the common responsibility to route each problem to its appropriate owner.  Becoming aware of a problem does not make someone its owner, but he or she must notify the team or party responsible and communicate all known relevant details.  Completeness of this communication makes the transition of responsibility from the noticer to the owner clear.
5. A Well-Ordered Sense of Duty
   1. How do you view your work?  Is it merely a burden?  Is it a source of identity or validation?  What portion of your life does it take up?  From the perspective of managers and executives, how do you view your employees and reports?  Are they numbers on a spreadsheet, resources to be deployed, partners in working towards some goal?  What do you expect from them in terms of commitment?  Is there common understanding of that commitment level?
   2. Some say that they want their employees to be like “missionaries not mercenaries”, but unless their work truly has a higher purpose, this is inappropriate.  Most people will have necessity as their primary motivation for work, not mission, and it is unreasonable to expect the kind of commitment associated with a higher calling to, for example, deliver food or facilitate online payments.  Doing your job well is dignified and honorable, whatever it may be, but for most people it does not deserve the zeal of a missionary.  Also see Rerum Novarum.
   3. It is a matter of duty to society and ultimately to God to use one’s talents well (Matthew 25:14–30).  This duty must be “well-ordered” in that it should neither be shirked nor all-consuming and the sole source of one’s identity.  It must be understood as a contribution to the common good and participation in the goodness of Creation.
   4. This is admittedly dissimilar from the rest of the “simple solutions” in that this cannot be accomplished with better communication or meeting styles, and for some people is entirely different worldview, but once accepted is simple to apply.  This sense of duty points the work of the team towards its proper end.