Skip to main content

It depends


A few months ago I wrote a post I Don’t Know. It was a post that explained why being honest about things you don’t know is important, as it builds trust amongst team members. I also explained why saying you don’t know something and following it up with a desire to actually take action, in order to gain that knowledge, is important. Today, I will talk about the words “it depends”.

Dependency Diagram for a recurrent artificial neural network. Source: Wikimedia Commons

Consultants are accused of overusing this phrase and rightly so. You see, if someone is asked a question and the response is “it depends”. Neither is the question answered nor is the information necessary to answer the question supplied, or a request for more information communicated.




When being consulted on a certain subject matter there is the reasonable expectation that the consultation will result in an answer or be directed to an answer. As such, I have been trying to follow up the words “it depends” with context on what the dependencies are. You see, a lot of the time I’m not lying when I say “it depends”. To stop at "it depends" though is not helpful, what is more helpful is following up this phrase with a request for context or a statement on dependencies. For example:

Question: “Should we run UI tests before merge into master”
Answer: “It depends, how long do the tests take to run?”

Question: “Is it worth having failover into another region”
Answer: “It depends, what is the consequence of downtime?”

What I found after months of actively follow up the words "it depends", is that at times, I’ve completely eliminated the requirement to say “it depends” all together. Let’s try the above examples again:

Question: “Should we run UI tests before merge into master”
Answer: “How long do the tests take to run? If they don’t take too long it may be a good idea. We can try it and see whether the slight increase in feedback time annoys developers”

Question: “Is it worth having failover into another region”
Answer: “What is the consequence of downtime? From my understanding we are a phone call away from all users of the system. Taking this into consideration in addition to our small user base, it may be a bit of an overkill to have failover.”

The above examples try to provide direction from the request of consultation. In many cases though, it is up to the person who's consulted me to eventually make the decision. I can only give my opinion, the facts as I see them, and seek clarifications on dependencies.

If someone has asked me a question it means they value my opinion. For me to simply respond back with “it depends” without actually providing clarification on those dependencies would not actually achieve anything. It’s OK to not be able to answer a question straight away and ask for further clarification, it's even OK to say you don't know Either way, not leaving the question hanging is the key to actually getting it answered.



Comments

Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.


from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Context and agile practices

At times we have competing responsibilities - ship code or don't ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it's important to strike a balance that will help us in the future, but also deliver in the short-term.