In the last post, we validated our potential design with users and updated our design accordingly. At this point in the design process, I should have a clear understanding of the problem that I’m solving, and why it’s important for the end user. I’ll have an opinion that I feel good about, with user validation to back it up. My opinion will be strong, but not rigid. I still want to be flexible and willing to change my direction as new information comes in. But I should believe in (and feel confident in) my opinion!
I know my opinion is strong enough when I can defend it to a very accomplished and masterful person (VAMP) that’s skeptical of my idea. A VAMP is someone I respect greatly and has great technical insight in the relevant area, but also makes me slightly nervous (despite their friendliness) because they’re just that awe-inspiring. This person might be a manager, a company exec, or even an imaginary vampire squid who rules the depths of the ocean.
If I don’t think I’m able to hold my ground in a few rounds against a VAMP in a hypothetical debate, I haven’t convinced myself sufficiently that I’ve found a good solution (or the solution itself isn’t good enough). So it’s time to go back to the earlier phases and iterate until this threshold is met.
PHASE FOUR: MODERATING STAKEHOLDER CONFLICTS
Now what? Well, this is when I think about potential negative stakeholder reactions to my proposed design. This is a key moment, and ties into the Communication criteria for a Principal Software Engineer on the Career Development ladder:
Proven ability to navigate significant stakeholder disagreements, including proactively anticipating disagreements and finding communication paths that address them early.
Ideally, I want to gather a rough, preliminary consensus from my stakeholders before my design doc is published. The timeline is important, because there’s no quicker way to derail a design doc than too many harsh comments from unhappy people.
Fortunately, I already have a good idea what my stakeholder pool looks like from the information gathering. I know who will be disappointed and who will be thrilled. I know who cares passionately about the outcome of my design, and who has a mild opinion but is happy to defer to the majority.
Quadrant 1 is filled with stakeholders who absolutely love the design and feel strongly that this is a great design. Quadrant 2 includes individuals who like the design but don’t feel very strongly about it – they could be convinced to go in a different direction or they’re not particularly vocal about it. In quadrant 3, we have the opposite – individuals who don’t really like the design you’ll propose but don’t feel very strongly about it – they’re usually happy to go along with the majority. And finally, in quadrant 4, we have stakeholders who feel very strongly that a design is heading in the absolutely wrong direction.
I don’t really need to circle back to individuals in quadrants 2 and 3. Instead, I can focus on converting unhappy dissenters in quadrant 4. (Sometimes there are no dissenters, which means it’s time to skip ahead to Phase 5. Awesome!)
The best way to reassure skeptics is simply to have a conversation. After all, I’m working with smart people who have valid, intelligent concerns. So usually a friendly conversation is enough to reach a reasonable outcome – if I’ve made sure we’re on the same page on priorities and assumptions. That’s easier said than done, but here’s what I keep in mind when having these chats:
- Start conversations on a positive note. I make sure the other person has enough time and that they’re not distracted or having a bad day. I make sure that I’m in a good mood. I lead with a joke or fun casual banter, or bond over a shared love of guitar. Sometimes I learn a little more about their life if I don’t know them that well. Anything works, as long as it’s positive and authentic.
- Come prepared. This might be a diagram, bullet points, or a quick rehearsal/devil’s advocate session with myself – whatever I need to discuss the topic clearly, without meandering.
- Start with agreement. Again, I need to reassure someone that I’ve considered what’s important even if I’m moving in a different direction. Finding that common ground starts the conversation in a more productive manner (“we’re both trying to find the best solution”) instead of confrontationally (“I’m at odds with your opinion, and we both feel strongly about it”). For example:
- “Hey, you mentioned that this was important because of {reason}, and that’s why you favored {direction}. I completely agree that {reason} is important, and I’m glad you mentioned it. I’m exploring a different direction where I’m accounting for this concern in a different way than you proposed, so I’d like to run it by you and get your thoughts.”
- “You mentioned last time we talked that {concern} was really important to you. And that’s so true, because if {consequence} happens, that’d be bad, and I want to make sure I avoid that. So I dove deeper into {concern} by surveying users, and I actually noticed that the majority did not {behave in a way that causes concern}. What a surprise! This suggests that I can deprioritize {concern} with {alleviation in worst case} – is that okay with you?”
- “I know you’re really worried about {concern}, which in the worst case might lead to {consequence}. You mentioned we could alleviate {concern} by {method}, which has {a less desirable side effect}. I believe we could alleviate {concern} reasonably well without {side effect} by moving in this direction – let me go over it with you.“
- Success is not limited to convincing someone that I’m right. Yes, it’s satisfying when someone comes around to my perspective. But entering “aggressive persuasion mode” is usually not the right answer. Maybe I tweak my design slightly. Maybe they disagree, but they understand where I’m coming from and are okay with my approach if the majority agrees. Maybe they’re okay with moving forward but they’d still like to officially register their differing opinion. Maybe they’re nervous, but they’re willing to go along with it if we can collect certain success metrics to reassess later. Those are all acceptable outcomes! After all, I’m only trying to clear quadrant four – I don’t need to push everyone over to quadrant one to move forward.
You’ll notice that I haven’t actually started writing up my design yet. At this stage, I have detailed notes that could easily be turned into a design, and are roughly organized in the same manner (a section for requirements, a mockup, concerns, alternatives, etc). But I haven’t created a draft design doc yet, and I haven’t started transforming casual notes (“blergh takes forever to turn a customer-reported datasource name/problem into a connector into a log into an error“) into polished sentences (“Support engineers must first dive through logs on the Seeq Server and remote agents to determine which agent and which connector a datasource belongs to, as all of the troubleshooting information is stashed away in agent or connector logs.”) Why not? Three reasons:
- It’s tempting to send a draft design doc to stakeholders for review before you post it, with the hope that you’ve addressed all their concerns in writing. But I find that this is almost always a disaster. A Skeptical Stakeholder opens up what seems like a fairly complete design doc, triggering a visceral reaction of “whoa this has already gone too far down a bad path”. It can also make them feel like there’s no longer room to negotiate the design in good faith (even if it’s not true!). It’s also easy for them to focus their nervousness on relatively unimportant parts of the design (such as naming), which sidetracks the discussion. And finally, this approach usually takes longer, because it requires someone to set aside a significant amount of time to thoroughly read several pages (compared to a twenty-minute conversation where I can drill into only their specific concern).
- Writing a design doc can over-solidify my ideas. I convince myself more that I’m heading in the right direction just by writing something down, and I may be less open to reassessing my perspective when I circle back to stakeholders.
- If I decide to move my design in a different direction based on additional conversations, then at least I don’t have to re-write my design doc.
Now what? Find out in Phase Five: Communicating Your Design.