Immutable vs. Variable

What are you doing blogging about software concepts? Sure, you still manage developers, but maybe you should think about leaving this stuff to the experts still on the tools.

Yes, yes. But I needed to get the attention of those guys. What this is really about is a contemporary view in the psychology of personal development that we exist on some continuum between having a “fixed mindset” and having a “growth mindset”. See what I did there? Very clever. On with it then.

The premise is that with a fixed mindset, we believe that our personal qualities are set in stone. Our intelligence. Our moral fibre. Our personality. All static, all unchangeable – what we’re born with is what we’ve got. Inherent in this assumption is that our success is therefore a measure of these qualities, that any failure is due to some deficiency in one or more of these. Worse still, it infers that these failures cannot be overcome. People with this mindset will seek situations that validate their intelligence, scenarios that they will succeed in, avoiding any potential failure at all costs.

The growth mindset is the opposite. Those traits – intelligence, character, even creativity – can be developed, cultivated and grown. Where those with a fixed mindset see failure, those with a growth mindset see an opportunity to learn. Instead of taking a tried and true approach, or tackling a problem in which success is guaranteed (and thus validating their intelligence), someone with a growth mindset will stretch themselves and accept a challenge where learning and effort will be required, and failure is a very real possibility. Success in this mindset is in seeing that effort can grow your intelligence, that experience can develop your personal characteristics.

I’ve included here a graphical representation to help visualise this, put together by Nigel Holmes, and found in the seminal book in this area by Carol Dweck, Mindset: The new psychology of success

dweck_mindset

So, what’s the purpose of this post? I’ve really only recently begun to move from a well-entrenched fixed mindset, to appreciating and having the courage to adopt a growth mindset. And I can tell you it’s confronting when you start out. It takes a degree of self-awareness that I’m also still growing, to be able to identify where you stand, and why. You then need to challenge (look, already growing!) the reasons why you are approaching your personal and potentially career development from a safe and effortless position, and make a conscious and concerted effort to change.

We are all born with, and form further when young, inherent abilities that direct and guide our adult lives. It has been a welcome realisation for me that we can change the hand we were dealt many times over. I’ve had the luxury of two leaders in both my immediate boss and a coach pushing me in this direction, and challenging the status quo I’d reached. My challenge to you is take a step back and determine where you stand.

Do you have the mettle to accept that you can further develop traits that affect both your career and your relationships, even ones so important as those with your spouse and your children? Are you really ready to say that you can’t and won’t put in the effort and take the risks necessary to improve these, simply because your fear and belief that failing in some endeavour is a failure of self, and not an opportunity to learn?

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.

Accountability?

Accountability is a term that is used often in organisations all over the world, across all manners of industry. The meaning however can be, and is, vastly different.

Over the course of several posts, I’ll attempt to define how I view accountability for an individual or a team within an Agile organisation, outline some ways to ensure the most beneficial and appropriate application of accountability between product stakeholders and a team is undertaken, and finally discuss how accountability relates to an individual within a team.

So what does it mean? To be accountable for something is having the obligation, the expectation, that you are willing and able to share, discuss and explain the actions taken to achieve some result. To openly articulate the decisions made, the consequences considered, and ultimately justify those individual actions that both were and weren’t undertaken as part of that process. Accountability has less to do with the actual result, and more to do with how you get there.

Oftentimes, it is thought of in terms of blame and punishment – this occurs where accountability is misunderstood, and applied from the paradigm of an assured result, of having a promised outcome that wasn’t completely or exactly met. In this situation, the result has not been separated from the actions that led to it – which is where real accountability should be measured.

How then should accountability be applied, and what are the benefits of espousing it as a value within your Agile team or organisation? Applied from the correct perspective, accountability should foster teamwork and collaborative effort. It should provide direction and focus, and remove the need for meeting after meeting where no real outcome or alignment is achieved.

In order for accountability to be truly effective in this manner, there are certain prerequisites that must be met. The team or individual must have the goals and what will be considered success and failure clearly defined by them, and agreed to by the stakeholders, as well as the consequences of not achieving them. They must understand how and why transparency and visibility into the progress of the team will be achieved, and how external feedback and input will be given throughout the process.

Most importantly, they need autonomy. Autonomy and accountability go hand in hand, and to desire or attempt to apply one without the other is misguided and will lead to discord and a lack of trust. A team needs the ownership and the ability to make decisions on how they are to achieve the agreed upon measures. To have this dictated to them undermines the very notion of empowerment the autonomy seeks to provide, and will ultimately lead to a lack of drive and motivation to work towards the goals of the business. Conversely, without accountability, the focus and alignment with the needs of the stakeholders and business can become unclear, and lead to the team or individual working endlessly to a solution that doesn’t satisfy any immediate need of the organisation.

Applied correctly, accountability coupled with autonomy fosters wider collaboration and an alignment between teams and the organisation’s goals, and that initiative and ingenuity are encouraged and celebrated in achieving them.