This is part 2 of last week’s post: Communication: Getting on the Same Page. I thought about it more this week and summarized a few more points I missed in the first post.
1. Make sure people share the same understanding about the end goal.
At the beginning of the project, we were using the same words to describe the end goal without realizing we meant different things. Because we had different understandings about the what and why of what we needed to accomplish, we had a hard time getting on the same page and sharing the same priorities. For example, something one team treated as the essence of the project was treated as a scope creep by the other team.
We should have spent some time together as a team to talk about our understandings of the deliverables, instead of rushing into planning. Sharing the same understanding about the end goal is critical because it heavily influences how the team prioritizes different tasks and approaches.
For multi-quarter projects involving many people, it’s best to document what is the end goal, why it’s important, and what’s not part of the end goal and have everyone involved to review, modify, and agree on the document.
Verifying people’s understanding is hard. Aim for over-verifying. The only approach I can think of is to talk to each other more, use different words, and rephrase things in different ways.
2. Identify stakeholders at each level and what they each care about
For projects with high impact, there will be stakeholders at different levels. It’s important to identify who they are and what they each care about.
For example, for a project, there might be stakeholders at four different levels. The first one is the engineers that actually go on to implement and deliver the goal. Engineers normally care about knowing the importance of their work, having a reasonable timeline, and having autonomy in choosing technology and technical designs.
The second one might be the managers of the engineers. Engineer managers care about how their engineers feel about the work. They think about questions like: is the work aligned with their career paths, are they interested in the work, are they having fun, and are they stressed.
Then it comes to project managers. They normally care about if the project is on track, are milestones being hit, and if they need to allocate fewer or more resources to the project.
Last, if the project has a high business impact, people from the executive level might care about it as well. They mostly care about on a high level, how the project is going.
Stakeholders at different level can share the same interests. For example, it’s likely that all stakeholders care about if the project is still on track.
Different projects can have different kinds of stakeholders. For example, if the project has direct customer impact, the customer support team might be one of the stakeholders. They might want to know when and how the project will impact customers and how to answer some common questions customers might ask.
Identifying different stakeholders and what they each care about can help you communicate with them more effectively and timely. It also helps you to know who to ask for help when you need them.
3. Use visual presentations
I lost count of how many times someone told me they were visual learners. That included many engineers. Many engineers think they are the only few visual learns and most other engineers were not visual learners. In my experience, almost everyone prefers seeing things visually. We prefer simple diagrams over long paragraphs of descriptions.
Visual presentations are specially powerful to show a workflow of an existing system and the workflow of a proposed system. Having two simple diagrams showing the before and after makes understanding a proposal much easier.
4. Leverage PMs for breaking ties and documentation
Product managers are great at helping engineers stay focus on the big picture. Here are two common ways they can help. But don’t feel limited by these two. Feel free to leverage their help as much as possible.
When the team has a difficult decision to make, looping in the product manager is a great idea. They are great at asking key questions and making decisions based on trade-offs. They are not as technical as engineers, so they are great at taking a step back, looking at the big picture, and not getting attached to specific approaches.
Product managers are also great at documenting. It’s important to document how key decisions are made and the trade-offs involved. Because product managers are not as technical, their documentation tends to focus more on the ultimate business impact of the trade-offs.
5. Give engineers the problem and the information, not the solution
Engineers enjoy solving problems. If you hand a solution to engineers, they might feel that you took the fun away and only left the work behind. Although you might have a preference on how to solve the problem, don’t present that to engineers immediately. Give them the problem, relevant information, and time and space to think about it. It’s best to work out a solution together as a team. It’s important for engineers to feel they have a saying in terms of how to solve a problem.
6. Survey how the team feels
A simple but powerful way to get a pulse of how the team is feeling is to send out a simple survey (i.e. google forms) asking a few simple questions.
A common format is: from a scale of 1 to 5, 1 being strongly disagree and 5 being strongly agree, answer pick a number for the following questions: “I understand the problem we are solving.” “I feel included in making technical decisions.” “I understand the plan.” “I understand what my tasks are and why they are important.”
All in all, the more I am involved in planning and leading projects, the more I realize how challenging communication can be. It’s a hard topic that I’m still learning about. I would love to hear your thoughts.
My career plan for the year is to grow into a tech lead. I’m excited about all the learnings ahead and would love to share this journey with you in a brutally honest fashion. I will be sharing my weekly learning on the blog.
In the next few months, I will focus on growing in the following areas. You can expect to see posts related to them:
- focusing on the big picture of the project instead of near-term implementation details;
- balancing my efforts between leading projects and coding;
- work-life balance for long-term productivity;
- the human side of software development: making sure everyone riding with me enjoys the ride and feels fulfilled and inspired.
My best content on Career in Tech and Software Development. Delivered weekly.Enjoyed the article?