Big data abstract works, compile | vigorously, chia-hao chang, Mr, field Mr Leo, NingYun state.

It’s often the number of engineers on a startup team that starts to go awry.

That’s how Derek Parham, a former deputy CTO on Hillary Clinton’s presidential campaign, describes the problem of working with teams of engineers. Without knowing what was going on with the team, a new engineer is likely to rewrite code and mess things up.

Engineers’ work overlaps and they tackle similar problems without realizing it, so valuable time (especially for senior engineers dealing with messy situations) is wasted.

“As the number of engineers increases and the number of products increases, teams can get stuck in unhealthy work patterns,” Parham says. “It’s like a child’s clothes, they grow out of them. And she’s not going to wake up one day and find her shoes are too small for her. It’s always a slow, small pain for the engineering team before they realize there’s a problem, ‘and something has to change. ‘”.

Parham is familiar with the challenging task of organizing and managing large engineering teams. The Clinton campaign quickly hired an 80-person tech team, with Parham in charge of recruiting, data infrastructure, mobile, operations and security — based on a group of more than 500 tech volunteers called Devprogress. Before that, he helped develop G Suite, Google’s smart office Suite, where he served as director of technology. G Suite aims to bring productivity applications to all companies, schools and organizations. Today, Parham advises many fast-growing companies.

Working with a focus on engineering architecture, team growth, and product development, Parham saw the same problems pop up in his team over and over again. In this interview, he shares with us the technical design review system (including the ones he reviewed himself). Its greatest success is in keeping the engineering team healthy, well-communicated and productive, even as the team grows and the number of projects it needs to work on increases.

Doing an engineering project is exploring a wilderness

Most engineering teams rely on design documents to describe, review, and support projects or components. These are not new topics (these are just the basics we’ll get to later). Starting a project without a design document is like a backpacker venturing into a forest without a map. The engineering team doesn’t have that much time to explore. For those who are not familiar with these concepts, the following example is a good illustration.

There are many reasons why a design document can be helpful:

  • Calibration: As a team grows in size and starts working on various aspects of the product, some people start to lose track of what others are doing. If members do not fully know where things are going, the code and the system can clash. The design document provides a platform for discussion, consultation, and mutual understanding for the entire team.

  • (Reason 2) Understand the background: If the design document categorizes the previous work, the new engineer can quickly integrate into the work, understand how the product and function were created, understand the specific operations and what experiments were conducted and how decisions were made in the past. A design document is a record of the past work and decisions of engineers who have left the company.

  • Develop criteria: “Any effort to optimize a system for new functionality needs criteria,” Parham says. “Maybe you need to save time, manpower, or schedule a product release in advance, and you have to take on technical debt to get the job done.” If you keep a record of your criteria, you can help your team prioritize their work. If the situation changes, you can easily check to see if you need to make the same judgment again.

Simply put, a design document can carve your way through the wilderness, giving you signposts along the way, so you know exactly where detours and roadblocks are and how they are created. “If your engineering team doesn’t already have a design document and review program, you can get started,” Parham suggests. But the basic design documentation was not enough to deal with the messy work. In fact, design documents can cause other problems if they are not handled properly.

Design effective documentation

In fact, how to create these documents can become a hot potato — often no one wants to do it. It’s tiring, tight, and a distraction from other programming tasks. In many companies, there is often no response after the document is designed.

“People email design documents and ask for feedback,” Parham says, “and you see the problem, where everyone thinks everyone else is going to read the design document and give feedback, when in fact nobody does. Engineers take this silence as the default or no matter, and build features or systems without any feedback. Such systems tend to go wrong after a few months, which would not have happened if people had actually read or talked about the design document. So it’s important to make sure you have a system in place to make sure people read the design document.”

Because of this vicious cycle, many engineering teams consider the work of designing documents to be worthless. This often becomes a self-fulfilling prophecy, and the whole team’s communication collapses. That’s why it’s not enough to have a good design document; you also need a process that fully performs design reviews. In his long career, Parham found that engineers only work when they know their work is being properly reviewed by the whole team.

To start the new process, Parham, suggest you will receive feedback channels to expand to interested in what you are doing or be able to come into contact with the other team up your work security, operations, front-end and back-end or products (team), not just the engineering team, in this way, more and more people will be incentives and provide feedback at the appropriate time. You can start by telling them, and it won’t be long before they start giving you advice.

“Let your junior engineers write the original design document, and then your senior engineers edit it,” he says. “Spreading the work out to more engineers will help you keep your team active and give your senior engineers more time to work elsewhere.”

At Google, Parham has created a set of templates for detailed design documents to help your team work. However, your document should not simply be a collection of ideas, but should actually clearly separate (and list) the different parts, including:

  • Context: The context of the problem you are trying to solve. Why does it need to be resolved? What other related systems, features, or products does it have? Who is primarily responsible for this problem?

  • Design objectives: Requirements and objectives of the project. It should also include data on traffic inference, usage, required uptime, and so on.

  • System diagrams: Diagrams of all binaries, databases, and third-party services associated with this design. Visualizing data greatly helps people get a high-level view of the project and make it easier to fully understand what is affected.

  • Design Summary: Summarize the problem in a paragraph or two. This summary should not be too long; Designed to help people quickly and easily understand what is being built.

  • Design details: The detailed features of the design need to be listed here. This can include many detailed sub-widgets, code locations, test strategies, internationalization, extension strategies, and so on.

  • Make judgment criteria: This is a perfect place to make a disclaimer about how a particular decision was made, how the negative effects manifest, defects to consider, technical liabilities to work on, and consequences that may need to be changed in the future.

This pattern forces an engineer to start communicating with other relevant members of the team. Instead of scribbling something out of thin air, they must begin to carefully gather information and implement projects. In addition, this process will lead to better communication, bad ideas will be eliminated faster, and any negative problems will be nipped in the bud.

“Design documentation is really the documentation of a lot of one-way conversations and criteria.” Parham said. “The document should not really reveal a lot of new issues to the team but rather focus on areas of agreement.”

The initial design document should theoretically be approved by all key members (i.e., the document information provider and the senior engineer responsible for the project) before you can send it to other groups.

Then, instead of allowing everyone to comment directly on the document, create a blank Google Document where everyone can list their comments on the design document and add their name. This will be on the agenda for the upcoming design review. For anyone interested, this is what a design document looks like after people give feedback and before design reviews.

“By the time you send the design document, almost everything unknown should have been discovered in the process of writing the document,” Parham says. “This hands-on design review process does not in itself mean making decisions. It’s about creating a better team culture so that everyone knows what’s in the document, as a safety precaution to catch any hidden or pressing issues.”

Establish ground rules

Once you have a solid design document, it’s time to prepare for the review itself. But how do you effectively vet so many people? Parham gives very specific advice.

First, choose a moderator and a minute-taker for your session. They should be neutral parties with no emotional connection to the issues you’re involved in (but need above-average coaching and conversational skills). Then, 48 hours in advance of the live review, email the people you want feedback on — send the design document and a blank Google Doc for questions and comments. Set ground rules and expectations for the meeting in this email. Parham suggests sending the guidelines from this list to your team to ensure meetings are productive:

  • Everyone should add questions to the issues document prior to the meeting. This document will serve as the agenda for the review and allow us to confront the issues directly, saving everyone’s time. When adding, please add your name next to the question.

  • Everyone can sit and listen, but unless they have read the design document, no one can speak during the meeting. If the answer is in the document, the moderator will skip over and interrupt the question so as not to waste everyone’s time. We have a lot of people in the room, so let’s make the most of it. “As a result of this rule, you’ll see a lot of people skimming documents before meetings, much better than not reading them before.

  • No E-mail, no typing unless you’re taking notes. Open your laptop at will, but only read design documents. We are here to devote the next 45 minutes to this product or feature. When you submit a design document in the future, you’ll appreciate others doing the same for you.

  • The moderator will continue to push the content forward and may request that specific discussions take place offline. This is also intended to save most workgroups time.

Leave non-topic questions until the end, but feel free to jump to anything relevant to the moment. Note-takers should write down everything they can. “Ninety percent of teams will probably initially ignore this email because they’re busy with other work,” Parham says. However, if they have the opportunity to read the documentation, they will certainly have problems to add (since no design document is perfect). Observing who is adding problems is a good way to track team involvement, which also creates a lot of responsibility and accountability. You can even use this process to see who has the potential to move from junior engineer to senior engineer and how much their insights and questions can help other teams.”

“My strategy is to watch the problem file over the next 48 hours and make sure it starts to fill in,” he said. “You usually see a pattern — one or two engineers ask the vast majority of the questions. It doesn’t matter, because they may ask common questions that other people have. But you want to have a diverse group asking questions — diversity on the team means diversity of experience.

Know the messages in your review session. One way to ensure that no one is excited to attend the review is to make it look like a formal presentation rather than a discussion.

“One of the patterns people have for design reviews is to take slides and turn it into a written presentation,” Parham says. But that doesn’t work. The reason you want to submit a design review is because you are looking for feedback on the proposal. If people think you’ve already made an irrevocable decision, they won’t be upfront about it in their feedback.

Choosing a moderator is a great opportunity to involve different members of the team in the process. You want someone who is a great communicator who has a good command of a room, understands technical details, and doesn’t let the conversation get contentious or go back and forth quickly. That’s why you want to pick this character from an objective faction. It’s hard to be emotionally calm and rational when you’re in close proximity to a job. If you defend your work too much, instead of collaborating, you will only want to detach yourself from this objective work. In contrast, lead engineers from other parts of the engineering team are well suited to the role of moderator.

Parham points out that if the front end team is proposing a new feature that integrates with several systems, ask the back end lead or operations lead to act as moderator. You can train your senior engineers to take on more responsibility in this way. You don’t want the CTO running these things all the time. In fact, you want ctos to be participants more than moderators or speakers.

In order to solve simple questions without any conversation, it is best to answer them in advance in the questions document before the meeting begins. For example, with questions about release dates or client requirements that are not specified, perhaps a chart or link can be the most effective way to answer a query, in which case an online response makes sense. However, the author should still be prepared to follow up on each issue.

Stay focused

On review day, a good level of organization is essential, you need to keep everyone focused for 45 minutes, and the only way to do that is to create an agenda and stick to it. Here are the steps Parham suggests you take to ensure a successful hands-on design review:

1. Send reminders

A few hours before the review begins, send an email reminding the group to add their questions to the specified document. More often than not, this is when most people actually read and contribute. Then, about 30 minutes before the review begins, the moderator should deal with the questions as appropriate and classify them in batches.

  • What are all of your operational issues?

  • What are all your security concerns?

  • What are your ux issues?

“This may require a good logical grouping, because in the review process, you need to discuss similar things at the same time to establish the conversation between similar things or answer relevant questions at the same time,” Parham says.

To ensure that the right people attend and actually show up, you may need to be a little creative. Everyone has their own method, but the common denominator must be vitality. Find a moment where you can explain how important it is to you and your team. You’re happy to get feedback because it’s possible to build the best possible thing. You should use whatever tools you have to deliver that excitement.

“At Google, I would use the Nerf weapon [a toy gun] to get everyone to participate in design reviews,” Parham says. “We will fire on them until they get up and pass. I would run down the hall and say, ‘Design review time! Design review time! ‘” You can use food, shut down their email accounts, anything, as long as you can get people to show up for design reviews.

2. Review rules

Initially, the moderator should remind the note-taker to keep track of key points and insights during the review. When everyone is in the room, they should simply go over the rules to re-emphasize that they need to be enforced.

“You need to emphasize that people don’t talk unless they’ve read the design document,” Parham says. This is key, because in many design reviews people who don’t read the document will start asking questions that already exist and have already been answered, wasting everyone’s time. There can be 20 people in a room and you need to be very efficient. Engineers appreciate it when their time is respected.”

After reading the rules, a bunch of people would open their laptops, open the design document and start reading. People will often go to meetings and just listen, but if you tell them they can’t actually offer anything valuable before they read it, they’ll read it.

3. Have each person read their own questions aloud

In the design review process, the moderator should not be the questioner, but should give everyone the opportunity to ask their own questions.

“By giving everyone a voice in the group, you get more effective and realistic answers and feedback,” Parham says. “This kind of communication and discussion is more natural and sincere. “If the host reads and answers one question after another, it’s hard for people to be focused and engaged, and they don’t know the questions well enough to give good answers.”

If a question takes up too much time or an answer is too long, the moderator can interrupt them. The minutekeeper is responsible for taking notes of every agreement and decision made, preferably in as much detail as possible. You can see which questions were answered and the details of the responses in the Google Doc questions list. This will help people review the meeting, especially those who didn’t attend but are interested.

“If you’re doing a good job with your design document, you’re not going to get a lot of broad questions.” “The questions will be clear, and the answers will be straightforward, like, ‘We didn’t do this because there was a trade-off, and the main factor was XXX,’ or ‘We’ll put this in,'” Parham says.

4. Open up discussion

When all the questions written in the Google Doc have been asked, if there is time, the moderator should leave it open for discussion, other specific questions, suggestions and feedback, etc. It would be better if some new content or amendments were proposed in the open discussion, but not much. Occasionally there might be a lot of them.

“At Google, if there’s some obvious controversy or issue in a design document, we’ll update it and then discuss it again,” Parham said. “This is especially true for large projects and teams, such as 100 or more people, and it’s important to make sure everyone knows the details. Because what you’re doing is a system that can take years, and it takes a couple of weeks to sort it out.”

This was the case with Marketplace a few years ago.

“I remember the design document being revised a lot because Marketplace was such a big project. It was done remotely, and it was an early project, and there were a lot of communication problems. That’s where the design review process comes in, because it’s better to spend a couple of weeks tweaking and tweaking things, rather than six months doing it and finding bigger problems, like it doesn’t work, or it doesn’t work with other products or features, or it doesn’t meet people’s needs.”

Parham believes that such a design review process can be very helpful for large teams or those with many remote collaborations. For team members who are out in the field and often feel left out or left out of the discussion, this process allows them to keep track of the progress of the larger force and participate in the discussion.

“The extra time spent writing design documents and doing reviews in the beginning is worth it. This ensures that everyone knows what to do, what the trade-offs are, and why. Make sure communication is adequate, especially with engineers in key positions, to avoid future problems and hassles.”

Deal with objections and disagreements

It is natural, but detrimental, that positive and even heated debates sometimes arise during design reviews. If the argument goes on too long and delays other issues, the moderator should step in and stop. If the debate continues, it is up to senior engineers to keep order.

“If a heated argument arises during the judging process, the moderator should control the situation and make the disputants aware that we should move on to more important issues and move from public debate to private discussion.”

In general, if there is a major dispute, it is because there has not been sufficient communication with the people involved. You may have to talk to them one by one and rewrite this part of the design document. Please tell the disputing parties that you will work with them further to discuss the merits of each argument and take their views into account.

“If the design document is perfect, then there will be no problems in the review process, and people will say this is optimal,” Parham said. “But we have limitations and deficiencies, and it’s hard to get things done overnight, and there will always be constant review and improvement. In this process of continuous improvement, people may come in different order, good advice may come later, don’t feel disrupted, this is part of the plan to move forward.”

If this is your first design review, controversy is inevitable. As you get better at it, arguments will diminish.

“Arguments are good things,” Says Parham. “It’s amazing what they do. And you find, wow, we found this bug now, not three months from now. You can do that by doing design reviews together before you start coding.”

The harshest criticism makes the best problem prevention system

Harsh criticism and opposition are also good learning opportunities for team members, both junior engineers and non-engineers, to learn in detail about the technical solution and the trade-offs decision process.

Benefits to the team

“Think about how many companies solicit ideas and suggestions after a project has been implemented,” Parham says. “Important issues have been missed, and a lot of code and time and effort have been wasted, and they have to start all over again. “It’s a huge drain on a startup and you have to keep that in mind.”

The design review process, from initial documentation to subsequent public and private discussions, has many benefits for the team:

  • Promote communication throughout the company

  • Improve understanding of technical infrastructure, especially for non-engineers

  • Better understanding of past completed and ongoing projects

  • Design better features and products

  • Save time and effort, especially in more senior positions

Following these steps in a design review allows every engineer to speak up, not just the most vocal or aggressive.

“Technical leaders understand that you’re going to have people on your team who talk a lot, and people who don’t talk a lot,” Parham says. “A lot of times, they actually have a lot of thought, but they just don’t express it. For example, when people are having a discussion without a clear purpose or topic, or arguing about something in an email, these quiet engineers don’t join in. The design review process makes it natural for them to participate.”

Design document preparation and review process, can avoid unnecessary waste of time and energy, and can effectively promote communication between various functional departments within the company.

“Most engineers just want to be heard, and even on past projects where their ideas weren’t heard, they still want to be involved,” “While more senior positions make the final decisions, fostering an atmosphere where everyone contributes to the decision-making process, rather than being told or told what to do, is what the design review process is all about,” Parham says.

In addition to the technical department, it is also helpful to other functional departments, such as marketing, sales, design, etc., so that their members can participate in the realization of cross-department information opening and communication will benefit a lot.

“Anyone can participate in design reviews,” Parham says. “Good ideas can come from anywhere. I like to involve both the design and product teams, who can think better at the company level and understand how to do their jobs better.”

The original link