What could possibly go wrong?

What could possibly go wrong?

This has been for quite a while now, one of my favourite aphorisms. It entered into the common vernacular of a small group of developers who I worked very closely with, and remain great friends with to this day. Going to the Casino by Philadelphia Grand Jury would often get spun up when the turn of phrase would be especially applicable. And in the days of a rapidly growing startup, with a bunch of self assessed superfly developers on board, this was regularly the case.

I still use it to this day, with reference to any number of things, be it at work, home, or otherwise. I’ve used it as a means to display my own confidence in something – delivery and context with that meaning is important, so that those hearing it interpret it as such. However it is more often than not used with a heavy serve of cynicism, irony or sarcasm – it’s usually applied with a negative connotation, not as a positive or supporting observation. It’s used when you’re on the edge, taking a risk, or simply don’t care. None of these are especially confidence inspiring, and not something you’d therefore want to hear in your team or organisation.

I recently attended a course and the relevance of this question and how it could be used to empower and support, rather than undermine day to day and longer term decisions and actions became clear. But it needed a slight adjustment, a change in how it was phrased, and the meaning and power that it then carried was completely different.

What’s the worst that could happen?

When framed like this, and posed thoughtfully and with purpose when considering a problem, proposing a course of action, or reflecting on some personal decision, we are able to really identify the risks, what we are afraid of, and what is stopping us from taking the next step.

From a business perspective, considering this question when planning a feature can allow us to identify the major issues with the proposal, and therefore work to mitigate those risks, or remove them entirely. It may even lead to a re prioritisation of that feature all together if the answers to this question highlight major potential pitfalls. Conversely, it can validate the assumptions made throughout inception and definition, with the answers providing further evidence as to the viability and feasibility of the project. Nothing can be more reassuring than looking for the worst, and finding that it has been catered for.

Alternatively, in an environment and structure that supports and promotes the ability to “fail safely”, the question identifies those outcomes which are less desirable that should they eventuate we need to address immediately, and those which if we fail, are acceptable outcomes that we can learn from and develop ourselves or the product with respect to. I’ll cover the concept of failing safely in another post.

The question can be even more effectively applied when assessing personal risks, or perceived shortcomings when making a decision that might affect your career or personal life. You might find that when answering this question, the fear that was held was misplaced, and the results or outcomes that were stopping you from making the decision weren’t as bad as first thought, or weren’t likely to eventuate. This can often be the case when facing some question over competence, or ability to fulfil some role, and the fear of failing or the presence of imposter syndrome is holding you back from taking the next step forward. Of course, the truly self aware and honest application may raise issues that do need to be addressed before continuing, which is still a hugely beneficial result.

So I challenge you – the next time you face a personal decision or are looking at a solution to some problem, instead of simply taking the easiest or safest option, or conversely flippantly dismissing the risks, ask yourself, what’s the worst that could happen?

What’s the worst that could happen? 🙂

Feedback is Fun

I participated in this session with Jerry, and it was really, really worthwhile. I personally found it quite fun as well, but it is certainly a challenging experience. Being able to both give and take constructive feedback is a tremendously valuable skill we should all be trying to develop in becoming better professionals and leaders.

One thing is key here – the participants must truly be doing it for the benefit of the other person. If you are giving feedback with any other motive as the driving factor, you are likely doing more harm than good, and/or for selfish means. So please, if you find yourself wondering why you’re giving someone feedback, and the answer isn’t to honestly help that person become better at what they are doing – don’t.

Wasn’t this meant to be about accountability?

In my last post, I covered what I see as the real definition and value of accountability within an Agile organisation. Achieving a higher level of collaboration, teamwork and focus through the ability to discuss steps taken to reach some result, the need for clear goals and measures, for transparency and feedback mechanisms. That it’s less about the aforementioned result, and more about how you got there. Most importantly, I highlighted the requirement for teams or individuals to have autonomy to make accountability a relevant and useful concept to apply beneficially in an organisation.

When I first decided to write these few posts, I had a clear-ish idea of how they would flow. The first has been posted, and wouldn’t have changed anyway. The second would then cover some methods to achieve alignment between stakeholders and teams, the benefit of meetings (who would have thought?!?) built around those methods, and the resulting confidence that the team is doing the “right” thing, by all parties – the team, it’s members, and the company.

As is wont to be the case with things at the moment however – change is on the agenda. I’m going to break things down again into some key concepts which in and of themselves will constitute and lead to further posts. So instead of a bounded series on just accountability, there will be a coherent, but mixed bag of ideas that relate back to autonomy and accountability within the organisation. For example:

Setting team goals with stakeholder buy-in

Maintaining a goal based focus during feature inception

Clear definitions of constraints and assumptions, as early as possible

Feedback mechanisms

Being able to “fail safely”

Aligned with this, I also hope to share some thoughts around leadership within this space. A lot of the ideas (such as creating an environment where teams and individuals can fail safely) overlap – and rightly so. It’s up to individuals in leadership positions, from the team level up, to change the way they think about getting things done. To foster a culture of understanding and believing we can always do things better, that we don’t know what we don’t know, and always have something to learn. To encourage the next group of leaders – to make everyone a leader.

This all comes about because I am currently in a phase of rapid learning and change at work. My role has changed, how I work has changed, what I need to be thinking about has changed. My personal accountability has changed.

And now, what I will be posting has changed. Slightly. For the better. And if it isn’t, thankfully, I can just try something different.