Comment by dvtrn | Hacker News Reader

Comment by dvtrn | Hacker News Reader

Parent Full thread

I think of Steven Covey's "Begin with the End in Mind".

This has been a point of struggle lately in my career; I know exactly the source you’re quoting and it’s paid dividends in my own ability to deliver and manage teams when I was an engineering manager

and yet

I’m finding a lot of frustration lately-having intentionally gone back to working as an individual contributor-with jobs where a leader takes on a massive undertaking of a task, or decides to start picking at a particularly nasty process/business/engineering scab, making it my priority, but giving no guidance on what “done” means or looks like (aka: acceptance criteria). Even when I blatantly, directly, and simply ask.

It’s difficult to know where you stand in terms of an OKR deliverable when you have a definition of “done”, but stakeholders are preventing any kind of hand-offs or closure to the project when they have a different definition of “done” but are avoidant in sharing what it is and where your deliverable comes up short.

Got an open-ear and open-mind on ways to better ‘manage up’ on this tangent.

You need a definition of done for your definition of done. (e.g. your requirements for the requirements they give you.)

It's an essential part of integrating with a team that you are able to get good requirements. Maybe you can get them to express requirements in a way you like. In some cases I've gotten written requirements that were inadequate but developed some process like "ask a few questions", "write my own version of the requirements and send it back for approval")

Perhaps. My challenge probably lies in finding out what my requirements are, it sounds like.

In the situation I’m dealing with presently, I don’t necessarily need this stakeholder to take any action other than make a decision on two similar options with different outcomes only they have the business authorization to make.

For my part, I’ve documented, and shared documentation with the stakeholder, and had multiple sessions with them about requirements and next steps to complete this project, and asked them repeatedly if there was anything that prevented us from moving to the next step. Each time the answer is no. By every measure I’ve tried so far, it seems there’s no question marks or missing inputs from me on actually executing the next phase of this work, and the stakeholder understands the options/risks/trade offs by their own admission…

Yet when I ask “then what is your decision on these two options for the next step?”, we end up going back to questions if the previous requirements have been met-which we already found a consensus that they were and the stakeholder suggesting we aren’t ready until those are met.

It feels…cyclical.

—- a forced analogy: it’s like you and your friend are working together to build a custom bike, your friend knows a little about bikes, but asked you for help because you really know bikes, and after you finish putting the bike together, the last thing to do is wrap up the handle bars, so you ask your friend what color grip tape they want, but they start asking you if the tires have been inflated.

I know the relative power dynamic can complicate things... but, it sounds like you need to stand up for yourself more. Tell the stakeholder that no more work will be done until a decision is made. You have done your part, the stakeholder has the authority to make the decision so on their head be it.

If that doesn't work then you have three options: escalate to their boss, live with it, or quit.

My current approach to situations like these are based on “Never Split The Difference” by Chris Voss and “SPIN Selling” by Neil Rackham. For me, I’m trying to identify what the other party _really_ wants, rather than what they _say_ they want.

All too often I’ve taken the other person at their word: “we want to reduce time to approval”, “we want all these features”, “we want to reduce operating expenses”. However, when time came to implement a plan to hit those goals, it turned out those weren’t the actual objectives.

A combination of sales, negotiation, and an attempt to identify the actual underlying need (belonging, recognition, autonomy, etc) has increased the hit rate.

But, at the end of the day, we’re monkeys wearing pants trying to squirt ideas at each other via flapping meat. Let’s just be amazed that communication between people can happen at all :)

It sounds like the stakeholder doesn't know what they want, which is why you are stuck in this Ground Hog day process of meetings.

Is this a decision that could easily be reversed? If that's the case, then if a bad decision is made, well it could be reversed pretty quickly. If this is the case, then I would just try to gently recommend the option that seems right to you. You might even suggest to the stakeholder that it's their idea and give them credit for coming to a reasonable conclusion.

You've solved the software engineering problem, now you need to solve the social engineering problem.

Unassisted, people have trouble with cycles.

Cycles are why people are afraid to get lost in the wood at night.

Theseus escaped the maze of the Minotaur because he had a tool to avoid cycles.

You need to document cycles as soon as you notice them and be polite but firm and ready to have the same conversation over and over again, documents in hand, making it clear that there are a few difficult issues that aren't staying resolved.

Sometimes you need a written and/or practiced explanation of something difficult that you or your customer have a hard time remembering.

Sometimes the customer really wants things that are contradictory and that's a common situation, in the long term the contradiction is resolved, sometimes you might be in a "pick 2 out of 3 situation" and might be able to try a few different pairs of 2 you can live with.

It is is one thing to be in a state of confusion that is tractless, but frequently there are a small number of persistent problems and those have to be kept on the surface.

Reply on news.ycombinator.com