Vision doesn’t happen in a vacuum. Instead, it almost always emerges through collaboration and idea-sharing across stakeholders. Most tech executives learn this lesson — sometimes the hard way — at one point in their careers.
As head of engineering and tech at your organization, technical vision falls squarely into your domain. You are designing a technical roadmap to give your team clear direction on how specific projects and day-to-day decisions align with big-picture goals. Understandably, your voice and viewpoint should take precedence when setting the strategy.
That said, as I wrote in my last post, engineering leaders must remember that the purpose of a technical roadmap is not only to support the engineering and tech teams but also to fuel the success of the overall business. The vision for the company must stem from business goals and involve stakeholders who can speak to those objectives.
Seeking input from stakeholders will improve both the visibility and the viability of your vision. Inviting outside feedback at the right time and from the right people will ensure your planning process is aligned with rather than compromised by other leaders across the organization. To strike the right collaborative balance, leaders must determine three things.
3 Key Questions for Developing a Technical Vision
- When to seek input from stakeholders.
- Whom to seek input from.
- How to use the input you receive.
By taking technical vision out of a vacuum, you will not only drive greater results for your organization but also save time and energy along the way.
1. When to Seek Input from Stakeholders
Timing is everything when you’re collaborating with other parts of the business. You must receive feedback, reactions and input from key stakeholders early in the planning process. If you do nothing else while developing your roadmap, do this.
For some, sharing an unfinished vision could be the stuff of nightmares. Speaking from experience, however, this approach is far preferable to completing your work, presenting it to the CEO and only then receiving the feedback that it doesn’t match the business needs. In school, I always wanted to be 100 percent ready or complete when I turned something in. Things are different at work, however, where presenting progress over perfection can help you align with others every step of the way.
As I develop the technical vision for Opendoor, I seek feedback at several intervals: when the roadmap is approximately 30, 80 and 100 percent complete.
- 30 percent complete — We make sure the guardrails are in place to keep strategy on track and that the team’s technical direction is aligned with business priorities.
- 80 percent complete — We’ve figured out the medium-to-large decisions and we need feedback to ensure key stakeholders are on the same page
- 100 percent complete – We don’t necessarily need feedback; the doc is finished, this stage is about informing people so everyone is aware of the plan.
Receiving feedback from business and product leaders early on will ensure that your technical strategy will match the needs of the business and its customers.
2. Whom to Seek Input From
To be clear, the opposite of a vacuum is not an open floor. Engineering leaders must be intentional when identifying stakeholders to engage for feedback, or else they open the floodgates. Seek diversity in job function and seniority to obtain appropriate, dynamic feedback.
Personally, I’ve never been one to lock myself in a room with a whiteboard for an entire day. Instead, I prefer to collaborate with two or three colleagues and iterate on the vision together. When selecting who those two or three people are, keep in mind that seniority is not always the most important factor. Tenure at the company, on the other hand, might be. When I consider someone’s tenure, it’s because I need a colleague who deeply understands the complexity of our business, our products, our problems and the state of the market in which we operate.
For this reason, a colleague who has worked at the company for 12, 18 or 24 months may offer more insight than the new, highly-regarded leader who was hired last week. Although that person’s opinion is certainly valuable, contributors need a foundational knowledge of the business to craft a long-term vision. Note that this knowledge can be found outside the C-suite and beyond executive teams across functions including design, product, and more. Junior colleagues can also offer beneficial, fresh perspectives that round out the feedback you receive.
3. How to Use the Input You Receive from Stakeholders
Once you receive feedback from stakeholders — the good, the bad, the actionable — how do you incorporate it into your plan? I like to start with a collaborative working session. I gather two other members of the Opendoor engineering team via Google doc or Zoom and work on solving problems for two to three hours. I always come to these sessions with a framework outlining our initial thoughts. I never start with a blank page.
What you bring to a working session is just as important as what you should leave at the door: your ego. I’m happy to look at the initial roadmap, click “select all” and “delete.” As leaders, we must be open to starting from scratch.
That said, engineering leaders need to strike the right balance when it comes to ownership. Collaboration without boundaries can over-democratize the planning process so that nobody takes ownership of the final product. This approach does not have a good success rate. If all input is prioritized equally, teams can quickly become oversaturated with feedback. The end result is often lack of progress or, at best, iterative improvements.
At Opendoor, we embrace the DACI Model, which assigns a specific role to each person involved in a group decision, improving the efficiency of a project. If I own the technical vision, I will be the one driving decisions and pushing it forward. While I will be seeking input along the way, the vision is my responsibility when it crosses the CEO’s desk. Within this decision-making model, engineering leaders can feel empowered to push back on certain input and only incorporate the feedback that they, as the drivers, believe will serve the vision, the teams, and the business.
Shared Vision Beats Tunnel Vision
When setting a roadmap, engineering leaders must make sure their technical vision doesn’t become tunnel vision. When the planning process is collaborative, open and agile, the end product will be, too. After all, your roadmap is intended to help your team navigate their role in the business. So, collaboration should be part of the process, both by default and design.
