Science and Software

Lately I’ve been thinking more about the approaches and methodologies we use to develop software. With the introduction of terms such as TDD (Test Driven Development), ATDD (Acceptance Test Driven Development), BDD (Behaviour Driven Development), Specification by Example, User Stories, User Journeys, etc, etc, it’s easy to see why teams may be struggling with understanding and using these approaches. The introduction of these terms can sometimes see people getting hung up on definitions and forgetting that these approaches all have one thing in common. The intent is to build a common understanding between team members and stakeholders of different disciplines and knowledge or skill levels. All of the above approaches have a purpose and if understood and implemented well can be of real benefit to a team.

Overarching these approaches, we also have the two software methodology juggernauts of Agile and Waterfall. Agile is often seen as the new kid on the block and Waterfall as an outdated relic of the past but these views can also just be a common perception. Agile has, as people will tell you, ‘been around since the 70’s’ (depending on who you talk to) and Waterfall is still an approach being used today with success. I’ve worked on software under both of these methodologies along with hybrids of ‘Watergile’, ‘Water-scrum-fall’ and other such terms. I’ve seen a good percentage of time that should be spent developing software spent on clarifying definitions of terminology. At times, this can feel a little bit dogmatic. Jared Spool studied the habits of highly effective teams and noted that those who were more effective favoured tricks and techniques over methodology and dogma. In his transcript of ‘Anatomy of a design decision‘ he uses the analogy of a recipe as an artefact of a process not something that is exclusively needed or required to cook.

decision-making
Anatomy of a design decision – Jared Spool

 

Thinking about the things I’ve experienced and researched, I kept coming back to a process (or method) I learnt in school and one that has been around for hundreds of years, the scientific method. Regardless of the approaches, tools, techniques, tips or mindsets used in software development, the scientific method can be applied to the software development life cycle (SDLC) as an aid to understand the purpose of each stage. I’m not using explicit definitions of known SDLC models, more phases I’ve seen teams go through (or strive to go through) during product and feature delivery. I aim to be methodology agnostic.

 

Research1. OBSERVATION | RESEARCH

Before starting any project we need to know ‘What problem are we trying to solve’ and ‘Who are we solving it for’. Once we know the answers to these questions, we are then able to observe and collect information about the problem or our intended users. Our research can include things such as data analysis, market or competitor research, customer feedback or user interviews. At this stage it’s important to make sure we have both quantitative and qualitative data as well as using multiple sources to help negate the impact of bias and assumption. If we collect information from multiple sources we can make better hypotheses. At this stage we may also observe that our initial thoughts about the problem or user needs to be modified for greater impact or success.

 

2.  HYPOTHESIS | DESIGNHypothesis

If we have a balanced mix of research, observation and information, it puts us in a really good place to make a hypothesis about what we’re building and how to build it. This can be thought of as design. Making a hypothesis about software is thinking about ‘If I change X, then I expect Y to happen’. X is the visible change, and Y is the consequence of that change. For example, ‘If I change this link to a button, then I expect more users to interact with it’. From this point, I then have something to measure in order to know how successful that change has been. Design could be thought of as the visual representation of my hypothesis whether that be UI, code, architecture or infrastructure.

 

Experiment3. EXPERIMENT | BUILD & TEST

During the experimentation phase, we start to build and test the change we are intending to make. Testing also allows us to modify our build as we discover more information about the change that we didn’t know before. We may also choose to build more than one experiment if we are wanting to measure the success of an A/B test.  This phase is not to be underestimated in terms of the amount of information it can provide us and should also be considered dynamic, rather than static. The more rigorous and defined our observation (research) and hypothesis (design), the clearer the purpose of the experiment (building and testing) should be.

 

Analysis4. ANALYSIS | MEASURE SUCCESS

After the development or product team has done all their hard work, it’s then time for the push to production. It’s at this point, most teams stop and move onto the next thing with the only measure of success being that the code has made it into a production environment and is alive. But what about our hypothesis? We now need to see if what we thought would happen, happened or if we need to make further changes. Measuring the success of a change is critical to knowing what to do next and also provides us with more information about what went well and where we went wrong. This analysis of what happens when we put our software in front of either part of or our entire user base can not only provide us information about what to do in the immediate future but can also gives us insight into what to focus on longer term.

 

Conclusion5. CONCLUSION | ITERATE

By this stage we have a lot of information and because of our initial observation, hypothesis, experimentation and analysis, the conclusion about what to do next should be relatively clear. Do we need to perform any modifications or are further experiments required? Were we successful enough to leave this area of focus for now and move onto another one?  Like any good life cycle, once we have reached our conclusion it’s time to start on the next iteration armed with more information and insights than we had before.

By treating software development in a more scientific way I find it easier to understand both what needs to be done and why.

Science Based SDLC
The scientific method in software development – Stephanie Wilson

 

Approaches to Leadership

I recently went to a meetup as part of the Wellington Leadership group on the topic of ‘Learning to Lead’. During this meetup we talked about the following leadership styles, listed in order of effectiveness in bringing about positive change:

  • Visionary
  • Coaching
  • Affiliative
  • Democratic
  • Pace Setter
  • Commander

This got me thinking about leadership styles and how this can sometimes be reflected in where someone is on their own personal journey. This order of effectiveness could also be seen as something of a maturity model for personal growth and leadership. Before I get started into each style, I think it’s important to make clear that each style has attributes and traits that could make it effective in one situation but could equally make it ineffective in a different one. The ability to change the approach to suit the context is also key to this maturity model and that requires an additional understanding of the environment around us.

The Commander

This style of leadership is directive and is very task orientated. You might recognise a commander by their focus on achieving the task or goal at the expense of everything else e.g. people’s feelings, emotions or time. While useful in situations where action and a clear directive is critical to short term success, this approach can also be seen as overbearing and may alienate people due to its absence of empathy.

When people first step into a leadership position, this approach can easily become a default style as it aligns with the cultural norm of what being a manager is, telling people what to do.

As organisations and people mature, we begin to appreciate that there are different ways to get buy in other than having to use the ‘big stick’, authority or title.

The Pace Setter

When someone works hard and produces results, it’s natural for other managers to want to replicate this in other people. One way of doing this is to promote the pace setter so that they can build a team just like them. This style will encourage others to work extra hours, chase aggressive deadlines, work over lunch and commit to overtime. This can be useful when important deadlines have to be reached and momentum needs to be built but can easily lead to burnout and resentment within teams, especially when personal time is expected  to be sacrificed.

The difference between the pace setter and the commander, is that the commander is more likely to tell others what to do whereas the pace setter will lead by example and create an environment where everyone else feels they have to keep up.

Not all roles or responsibilities require this urgency and it often reduces creativity within teams as thinking time is replaced with continuous action.

These two approaches, the commander and the pace setter do come with a word of warning to use with caution. While they can be effective in some situations, they should also be used as more of a seasoning rather than the main course.

The Democratic Leader

This style of leadership is not political as the name may suggest but wants to make sure everyone’s voice is heard. These leaders are usually focused on gaining a consensus and making sure that no one is left out. When situations are tense and communication is key to resolving issues, having a leader who values everyone’s thoughts equally can help to create an environment where everyone feels heard and respected.

Because this style values each person having a fair and equal say, it can also create an environment where there is a lack of action.

This style tends to avoid decision making in isolation or without counsel and as a result of this can slow down the decision making process and create a bottleneck by preventing actions. Having an awareness of the bigger picture and understanding when it is time to ‘think’ and when it is time to ‘do’ can help to keep momentum.

The Affiliative Leader

The affiliative leader likes to build relationships and usually has a wide reaching network. They are usually warm people who have high levels of empathy and are good at resolving conflict between people as they can help to create positive connections. This emphasis on relationship building can also mean that these types of leaders are less likely to address poor performance as they value the relationships highly and may be more cautious about putting that in jeopardy or upsetting someone.

The Democratic Leader and the Affiliative Leader are similar but do have a key difference between their focus. Where the democratic leader focuses on making sure everyone has a voice, the affiliative leader is focused on building the relationships. It is possible to be democratic without being affiliative.

The Coach

One of the two most effective leadership styles, the coach is good at asking questions. By asking questions, the coach allows others to figure things out either on their own or with guidance and creates an environments where mistakes are things to be learnt from.

The coach is also good at looking at an individual as a whole person and is usually more interested in getting to know the person first choosing to see the work/life balance as just ‘life balance’.

Coaching can be difficult to do correctly and requires a healthy amount of empathy, self awareness and a growth mindset. The individual doing the coaching must also be mature in many aspects of their own self. Coaching done wrong can come across as micro managing and people can lose trust and become defensive or cynical.

The Visionary

These are the leaders tha have a vision and know how to share it in a way that encourages others to want to take part. It is considered the most positive of the leadership styles when trying to effect change. Being a visionary requires the skills to see the bigger picture and also communicate how the individual has a vital part to play in achieving the end result. This approach can empower the individual as they can feel a part of something important and also encourages autonomy.

Having a vision is not enough for this leadership style to be effective, there must also be the maturity and ability for that person to be able to hold others accountable in a positive way. To create this, trust and support are key elements for an environment to be created where no-one wants to let another person down.

How can these styles be combined?

One of the scenarios we imagined at this meet up was that of a dysfunctional team. Our facilitator asked how we might approach a team that was experiencing conflict or dysfunction as a leader. The combination we talked through was:

  1. Be Affiliative, build the relationships first, get to know people one on one and listen to what they have to say, hear their perspective
  2. Be Democratic, once you’ve built an affiliation with each team member, create an environment of democracy where everyone’s voice can be heard. It’s important to let everyone get their perspectives on the table without arguing back, contradicting or fighting. The point at this stage is to allow everyone to be heard and feel like they’ve contributed equally.
  3. Be Visionary, now that everyone knows where they currently are, it’s important to create a vision of the future and bring people into the idea of where they could be with some changes. Remember that being visionary also means that you have the ability to hold people accountable for their actions or lack of.
  4. Be a Coach, once the vision has been agreed to and people know where they want to go it’s then time to step back, be a coach, create an environment of experimentation and ask questions so that people feel a sense of control over their direction.

I really enjoyed attending this meet up and it has given me a lot of food for thought into how I can apply different styles at different times as well as being aware of what I’m currently doing and where I have gaps.

Adapting to Change

Working in tech has many challenges, one of those is the rate of change and how we respond and adapt to those changes. New languages and tools are constantly introduced and for some this can be a fearful time. I once heard that we don’t fear change as much as we fear loss and I personally believe that to be true. The phrase ‘people don’t like change’ is a misnomer for me as it doesn’t fit with my view of the world or reflect the progress (rate of change) we’ve seen in the past 150 years. Some change is born out of necessity however some is out of curiosity, frustration, pleasure or by accident.

Lately my world has been a veritable epic centre of change and this has forced me to apply introspection and really think about what is happening both externally and internally. This thinking also follows on from my last post about expectations and how these too can have an impact on how we perceive the world around us.

Compromised Values

We all have a set of internal guides that help us to make decisions and sense of the world. These are often referred to as a values, the emotive elements of life that we place a varying degree of importance on. For example, Integrity is one of my highest rated values whereas safety is something I value much less. This can be seen in my frustration with people I would consider unreliable and my ease at which I can pack up and move to another country without first securing a job. These are some of the things that make me, me. Everyone has their own set of values and their own ranking of these. If I propose the idea of packing up and moving overseas without a job and somewhere to live to someone that does value safety highly, I’m likely to meet quite a lot of resistance to this idea and probably a lot of questions.

When our values feel compromised in any way it’s likely that we will start to feel anxious, uncertain, frustrated and other things that make us feel a little uncomfortable with what’s happening around us. By knowing what our values are and taking the time to identify how something is making us feel, whether our values are being compromised or fulfilled, we can start to understand our own behaviours. This can help us to rationalise change and is a technique I find particularly useful when I feel as though the change is out of my control.

Fear of Loss

Loss can be an incredibly powerful emotion and I know that times in which I’ve been most troubled has been when I’ve lost someone or something that I had a strong connection to. When we’re first confronted with losing something it can be a difficult time. A role change can stir up many varied emotions, such as being excited about new responsibilities or opportunities but it can also be a difficult time as we come to terms with perhaps losing team relationships that we had built up over time. With almost every state transition we take as people we are usually gaining something but in the process, also removing or losing something.

In times of change where a feeling of loss has been involved I have found it helpful to focus on what I have gained. Being able to come to a place of accepting that things won’t be the same as they were can be difficult and it’s important that we are honest about ourselves as been accepting of a loss or not accepting. Some losses can feel bigger than others so I also like to use a scale system to put things in perspective.

  1. On a scale of 1 to 10, how much of an impact is this loss going to be on my life?
  2. What would be a 10?
  3. What other options do I have still have in my life?
  4. Is it still ‘X’ on the scale?

This exercise helps me to think of events more critically and I usually end up downgrading the impact of the loss by the end of this.

Unmet Expectations

Most of us have an expectation about what is going to happen to us in the next day, the next week or for those of us who really love to think ahead, perhaps longer than that. If we’re the type of person who likes to think about the future and what that might bring given our current set of circumstances, when one of those circumstances change, this can throw things in to disarray. There is thinking that if you change your expectation, you change your perception.  When people don’t met our expectations, even when we haven’t communicated what those expectations are, it’s easy to feel disappointed or frustrated that someone else hasn’t done what you think they should. Talking with people who have leadership positions about people who report to them, one of the common complaints is ‘Why did they / didn’t they do what I thought they would?’

The answer to this question lies in the conversation about what is or isn’t expected, not what you perceive the expectation to be. My perception is that most people want to be kind to other people and want to do well. Once a conversation takes place about what both parties expected, the source of frustration is usually clear. Having a growth mind set also helps with this as it allows us to be more open to other possibilities. This isn’t a case of ‘lowering expectations’ rather than ‘understanding expectations’ so that an outcome which is shared by both parties can be reached. Having the courage to talk about what we expect with others is a skill which I am continuing to place more importance on. It can be a good tool in diffusing a frustrating or difficult situation.

Underlying a lot of this is ‘the unknown’ which, if not understood can sometimes cause paralysis of change. These are some of the types of change I commonly experience and how I try to adapt to the undulation of emotions that come with these events. The more practice I do with these tools, the quicker I am able to get back to a place of comfort where I feel empowered to act.

Are there any tools you use for adapting to change to either these types or another type of change?

Setting Great Expectations

I recently had some furniture delivered by two different companies and the experience of each was vastly different. One was easy and delightful while the other was frustrating and tiresome. The function of each company was the same, to place an order, inform me of it’s arrival and to deliver the furniture yet what I experienced was not the same. The only difference between the two was how they communicated and set expectations.

The first company, let’s call it Company X told me that they had to order my furniture in, which could take up to two weeks. They charged a $65 delivery fee to which I asked what that delivery fee included which was delivery, unpacking, setup, taking away the packaging and any old furniture which they would then deliver to the Salvation Army. This sounded reasonable and I was happy to pay for that service rather than hiring a trailer to do it myself. During the two weeks they called to let me know the order had been dispatched, the order had arrived and then arranged delivery where they also called the morning of to let me know they were leaving the warehouse and were on their way. At no time do I wonder as to the status of my order and everything unfolded as per their communications with me.

The second company, let’s call it Company Y also told me that they had to order my furniture in and that it would arrive within 5 working days. They charged a $75 delivery fee which included delivery and nothing else. No unpacking or rubbish removal, just a straight delivery with no extras and for $10 more than the previous company. This did not sound reasonable and at this point I went out of my way to arrange my own pick up. I asked if it would be available to pick up on Saturday which they assured me it would be. On Saturday I turned up to find my furniture hadn’t arrived because they truck was missing a pallet and had to be turned around without being unloaded. There was no phone call or communication to tell me of this error which meant my arrangements for the day now had to be cancelled. Company Y told me the truck was due back on Wednesday and to try again then. This time, instead of making arrangements I made sure I called ahead which resulted in a long wait time on the phone for information. This time the company did inform me once it had arrived so I could make new arrangements. After picking up the furniture I kept repeating that even though loading it onto the trailer, spending my own time, my own petrol, moving and unpacking it myself, I still considered my own effort worth more than the $75 dollars I would have spent.

Cost vs Value

Why is this? Why was I prepared to pay $65 with one company and not be concerned with the amount, yet with the other company I was adamant that I wasn’t going to spend one dollar more with them. I think it comes down to the perception of value.

With Company X, I perceived the spend to be of adequate value for cost. I was paying for delivery but I was getting so much more than just that. At the end of the entire experience with everything having gone so smoothly, the $65 was considered as money well spent. With Company Y, I perceived the spend to be less than adequate value for cost. At the end of this experience I felt justified in my decision because the process had been rather bumpy with expectations not being met. I found myself thinking I was lucky I didn’t pay for or get the delivery as they probably would have mucked that up as well.

Communication

At the core of these two experiences is communication and this is where I bring these examples back into our day to day interactions with other people. As part of a team, you are usually providing some type service to someone else while also receiving services from other people whether that be your manager, team members, customers, support people or anyone you have interactions with.

It’s easy to become frustrated when we feel our expectations aren’t being met and there are two sides to this.

Firstly, if you are the one receiving some kind of service, did you communicate what your expectations were or ask what you could expect? Was there some kind of negotiation to make sure you were both happy with the agreement, is it reasonable to expect updates at the end of each day or would this be some service level that couldn’t be met because of other circumstances.

Now, what if you are the person providing the service, is the onus on the person receiving the service to ask questions? I would say no and there are a few reasons for this. As the person providing the service, you know more about the process, activities, results and time frames and by knowing more you can provide information about questions the other person never even thought to ask.

Being open about providing information is also seen as helpful as this helps to build trust and provide clarity.

However all of this is meaningless without integrity of the follow through. If you say you will do ‘X’, make sure you do ‘X’ or provide an update as to why ‘X’ cannot be completed as expected. We all make mistakes or overestimate what we can achieve, when this happens it’s important to communicate and reset expectations if there is going to be an impact. The goal is to make sure the other person is never asking themselves:

  • What? 
  • Why?
  • Who?
  • When?
  • How?

Being proactive about answering these questions before they are asked also helps to keep expectations in check as well as putting doubts at ease. To do this we have to have empathy for the other person and think about what they might be expecting or check in with that person with an update covering the above questions. This also provides the opportunity for them to ask any additional questions.

I always feel more comfortable and more at ease with a little bit of light rather than complete darkness.

Meeting and managing expectations can add integrity to your interactions with other people and help to build trusted relationships. It can also create a mutual respect as it means we are being considerate of others time and emotional investment in a given situation. I also find this technique helpful in team leadership, setting goals and performance improvement.

How did you feel the last time your expectations weren’t met? How do you set and manage expectations?

Building a Community

A few months ago we had the idea to try and build a Community of Practice for one of our teams. After a short trial I wanted to reflect on how we got started, how things went and a few things I learnt along the way.

Have a plan

Setting expectations helps people to feel at ease with something new, different or generally unknown. For those of us setting this up, this was also a new experience for us so it was important to make sure we had some structure in place. To create our plan we discussed the following aspects:

What is a community of practice?

  • A self-selecting group with a common interest or purpose
  • Members can come and go and have different levels of participation at different times
  • The community only exists for as long as its members want it to exist
  • A community is a place to support each other

What was our  purpose?

  • To create something that was passion led, not role led
  • To give people explicit permission (time) to join and participate
  • To give individuals the space to discuss things that they cared about, not what management cared about

How would people be expected to participate?

  • Individuals put forward ideas for discussion that other individuals could join so everyone can see the levels of interest for each topic
  • People choose their involvement and move between levels of participation at any time depending on their own interests or motivations.
  • People who choose to be at the core of the community identified themselves as people who would be prepared to take on extra responsibilities
  • People who choose to be active members would attend events but not facilitate or be expected to prepare anything beforehand
  • People who choose to be on the peripheral had an interest in knowing what was going on but didn’t wanted to actively participate

What do we need to do as a group?

  • Set up a way to communicate with each other
  • Have rules of engagement
  • Agree on a time for these meetups to take place

Are there any other things of note?

  • The venue doesn’t have to be within the confines of the office, getting offsite is encouraged
  • We would have self-nominated support people to help people along the way with any questions or concerns
  • There is no right or wrong, experiment!

Having this defined and available for people to refer to allowed a foundation for us to start with. We also wanted to make it very clear that things can change to adapt to the needs of the group and that we would trial the idea for 4 weeks. This meant that if it wasn’t valuable we could throw it away early on without too much investment.

Be fearless and treat everything as an experiment.

People are complex and are emotionally driven. For this to be successful we had to appeal to our basic need of wanting to feel safe. This couldn’t be something that would be seen as a failure if it didn’t work. Right from the start we talked about giving things a go, being open to the possibility of failure and making sure that if that happened, it was ok.

We treated our community with as much autonomy as possible allowing people to make their own decisions about what topics they put forward and which topics they went to. If someone didn’t want to go to a topic, that was ok. If someone went to a topic and they found it wasn’t for them, leaving was perfectly acceptable too. We made these ideas explicit and set that expectation right from the start.   

By removing the idea of right or wrong people felt empowered to take action and try something new. This year we ended up having a Secret Santa morning tea off the back of one of our community topics which had never happened for our team before. At the end of it, people were grateful to just see each other and connect in a different way.

People will surprise you

Before we started, I had made a lot of the usual assumptions, some of which proved to be completely wrong. By giving our team explicit permission and time to attend our community topics I thought this would remove the ‘I’m too busy’ excuse. I thought, how could they be busy, we’ve received permission from our entire department to spend allocated time on this! It turns out that people can make themselves busy if they are not interested in the topic put forward, which was ok. By allocating agreed time, people started being more honest, time wasn’t really the issue, content was. On the other hand, other people were complaining about there being too much choice each week and feeling frustrated at missing out on topics because they were being held at the same time.

When we first started we apologized many times for the frequency of our allocated time being weekly, the ghost of meetings past singing that oh so familiar tune of ‘too many meetings’. At our final review we broached the subject of frequency of meetings and to my surprise everyone seemed fine with the weekly frequency. This seemed to work because people could pick and choose, knowing that if they missed this week or weren’t interested in a particular topic there was always next week.

Perhaps the most interesting observation, and this is something I have been noticing more and more often, is that the people who complain the most, don’t take advantage of the opportunity given to them. In our earlier discussions, there had been a number of people who complained about the lack of community, some of those people didn’t turn up to a single event or put a topic forward. Knowing who these people are is useful information and by making everything self-selecting, we avoided wasting energy on trying to help people who didn’t want to help themselves

Self selection takes time

Straight off the bat, we were explicit that this community was by the team, for the team. There would be no one telling anyone else what to do, everything was up for review and hierarchy didn’t exist. There was one person we called a moderator that took care of administration activities such as updating the ideas board, emailing people with general information and sending out reminders.

For topics to go forward, a ‘Champion’ had to self-select themselves to drive the discussion. This person had to care enough about the topic for it to go forward and then organise the venue, duration and document any artifacts that could be shared with the wider community.

My thoughts were that this would be easy because the people who put forward the topics would be willing to champion them, however this wasn’t the case. During our first week individuals were shoulder tapped to be champions as people weren’t putting themselves forward. This wasn’t our intent although we didn’t want things to fail in the first week! Realising that this wasn’t going to be sustainable and went against our original purpose, the second week we did nothing. And we waited. And waited. No one put their hand up to be a champion until the day when we announced that there would be no community this week due to a lack of champions. We also reiterated that if no one was going to make this happen, we wouldn’t make it happen as organisers. It seemed we had all gotten so used to ‘someone else’ making something succeed. When that didn’t happen, other people started to step up. The reality of something being taken away couldn’t be an idle threat, we had to stick to our values.

For people to self-select themselves, they have to be given the space in which to do so, even if that means things get very close to failing. By removing the safety net of ‘someone else will do it’, people who cared about the idea started to drive things forward.

Continually review and adapt as needed  

Even in our first meeting there were things that needed to change. There were areas of ambiguity that I hadn’t articulated such as how we were going to record topics or the function of the champion. Reviewing everything early on and allowing people to contribute to the solution rather than going straight in with everything sorted out, gave people space to contribute. It also avoided making this ‘my’ thing that I was just telling everyone about.

We had purposely provided a framework to be built upon that still had questions that needing answering and problems that needed solving. As future problems came up, such as the communication of meeting venues and times, people communicated and made changes themselves, without asking for permission and because it was in the interests of the group.

We’ve only done a short trial but the group has found value in what we’ve done so it will continue again next year where I hope it continues to evolve as it needs to.  

Starting a community of practice has brought people together and I’ve seen a change in our group. People have started to be thankful for each other and are more hopeful about the future and the positive changes that future could bring. Being able to connect with other people that care about what I care about has motivated me to keep going and not give up at the first hurdle because I know there’s someone else who wants to try as much as I do.

What is Quality?

The phrase ‘The team is responsible for quality’ seems to get thrown around quite often, especially when something goes wrong. It holds the team accountable rather than an individual and tries to avoid scenarios like this:

Fictional Manager: “Should we blame the person who has the word quality in their role title?”

Other Fictional Manager: “Seems legit, they’re the ones we made quality explicit with.”  

In previous roles, I have been responsible for essentially, asking questions and providing information. In no way was I ever responsible for sign off or for stopping anything going into production. Project managers were held accountable for final release but it was my job to ensure that they were making an informed decision and knew the risks, the likelihood and impact. My responsibility was to know as much as I could about how the system worked, how a user would interact with it, how other systems would interact with it. Testing was designed to provide information about how the system didn’t work as expected, how customers couldn’t interact with it as expected and how other systems couldn’t interact with it as expected, in addition to identifying other things we found out along the way because as we know more, we know more.

For the purpose of this blog, I want to focus on two phases, Analysis and Design and Build because they are most relevant to my day to day experience. Post Release is also a topic in itself!

Analysis and Design

During the analysis and design phase my focus would be on reducing ambiguity, “What do you mean by ‘most of the time’? When would there be a time when that didn’t happen?” and thinking about functions and interactions, “What happens if I refresh the page? Are any of the fields mandatory?”

The reason for asking these questions is so I can understand how the software behaves and how it will be used once it is complete. The questions I ask will be centered around what’s important to me based in my own experience and knowledge so it’s highly likely that a different person will ask different questions to me.

This is where the power of the team comes in. By having different perspectives and areas of importance being addressed in a group conversation, others can help to answer questions. Additional questions that you may not of thought of with your own line of thinking may come up and you’d be surprised at what others know or care about. Asking questions to understand is not a role based responsibility but rather an individual responsibility to give ourselves the best possible chance of success.  

This part of software creation is often glossed over in favour of something more tangible however time and time again I’ve seen projects derailed and deadlines blown out because a simple question wasn’t asked earlier on. Asking questions is easy. Asking the right questions is hard so it’s important to practice forward thinking and ask ourselves, ‘What’s really going to hurt me later on if I don’t have clarity on it now?’ Sometimes this is a best guess however past experience should be able to help guide us. Reducing ambiguity increases quality in this phase.

Build

‘The team is responsible for quality’ is heard quite often during this phase but what does it mean? Previously, Analysts analysed, Developers developed, Testers tested and Project Managers managed. Everyone had their own area of focus and expertise, they had mastery or were interested in getting better at what they did (hopefully). Did this mean that those individuals didn’t care about quality? No (most of the time).

Quality means different things to different people and it’s not because of their role or title. Beliefs about quality is directly related to the beliefs that you hold and what your values are. Quality can be defined at an individual level as well as a team level. One metric often used by managers is the bug count. But, does a high number of bugs indicate low quality? Without getting too far into this argument I want to say, not necessarily. It really depends on the context of the bugs, the severity, the likelihood of them occurring and the impact they have. I’ve been in meetings where a CEO would decide which bugs we could live with and which needed to be fixed. Decisions I didn’t agree with I had to explain and justify why I thought differently. Sometimes he changed his mind, sometimes he didn’t but at the end of the day he was accountable for the success of that product so the decision was his. In Agile, we push that decision down but we still need someone to be accountable and make those hard decisions when differing opinions are on the table.

Individual responsibility for quality within a team should exist. Regardless of your role, individuals should think about producing something of quality. My own litmus test for this is ‘Am I proud of what I’ve just produced?’ If I am, that’s as good as it gets at that moment for me. If I’m not, then why not, what could I have done better or differently? This is the space in which I learn and grow.  Other things I think of are:

  • ‘Is what I produced worthy of a high five?’
  • ‘Do I feel good having done what I just did?’
  • ‘Could I have done more?’
  • ‘Have I helped someone else out today?’
  • ‘Have I shared information with my team today?’

These are my own metrics for quality which are role or title agnostic. Anyone could ask these same questions and apply them to their own role. Individuals can and should have their own questions they ask themselves to define quality, a way for people to recognise their own contribution to a team. If everyone does their best and tries to get better, team quality can only go up. Mastery is important to individuals as it provides a feeling of achievement and value and many working parts make the engine run smoothly.

All too often, our focus on quality is also on the reduction of bugs but I would argue that a team responsibility for quality is much more than that. This is where I come to team quality and why I think some ways of thinking are diluting quality rather than increasing it.

By measuring team quality with a single metric, this then becomes the team focus. If this becomes the team focus, this becomes what people care about. “We measure what we care about and we care about what we measure” Having a single focus or quality measurement can be dangerous because this becomes the thing that matters and individual quality, individuals doing the best job that they can do can fall to the wayside.

If individuals get better at what they do and are given the time to focus on it, team quality can improve. We need to give people the space and time to understand what they are expected to do and also provide an environment for people to do their work to the best of their ability.

Leading without authority

At the recent WeTest 2016 conference (http://www.wetest.co.nz/), I had the opportunity to talk about leading without authority. Many companies are ditching the more traditional, hierarchical team structure in favour of autonomous, flat structures where big sticks of authority no longer exist. This can be a dramatic change for a lot of people in positions of leadership or management. Where previously people often did things because they were told to, in this new structure teams are empowered to say ‘no’ and think for themselves.

Leading without authority can be a massive hurdle for all of us, especially if we’ve never really had to think about who we are as leaders, because our titles gave us everything we needed. I had come from a place where I was familiar with telling people what to do rather than listening to what people needed. Still being a leader but having all the authority taken away was a very steep learning curve for me. Having spent the past 15 years in all types of leadership positions, I wanted to share some of the myths I had busted along the way.

Myth: People are born <leaders>, <successful>, <lucky>

Some of the time we can look at people who have ‘gotten ahead’ of us in some way and think that they don’t deserve it, that they may have gotten lucky in some way. It’s all too easy to sit back and feel sorry for ourselves, thinking that success isn’t something that will happen to us. I’ve been fortunate to have met a lot of successful people in all types of disciplines and they all have something in common. They’ve all worked for it. I feel it’s important to make a distinction here in that I’m referring to the people that are respected in their fields as people in a community as well as an organisation.

When we’re introduced to people who have already achieved success, we’re often only seeing the tip of the iceberg. What we haven’t seen is the hours of dedication, training, self reflection, learning and growing that person has been doing for years before. I can guarantee that they’ve had a few failures of their own but they made the choice to keep trying and move forward. It’s also important to recognise that these people do these things for themselves, not for other people.

People who perform well, usually do so because they have a supportive environment which allows them the time to work at getting better.

They also have the right tools, resources and opportunities to continue moving forward. It’s important to keep this in mind when building teams by asking ourselves if we’re creating the right environment for people to grow and improve. Change the environment and the people will also change.  

Myth: To be a leader, I have to know more and do more than everyone else

Like many people I’ve suffered from imposter syndrome. The thought that I was going to be found out in some way, that I didn’t know as much as people thought I knew. In my early 20’s I was given advice from an older colleague, ‘Once you accept that you’ll never know everything and that it’s ok, you’ll be much happier’. Turns out they were right. Being able to say ‘I don’t know but let’s find out’ is rather empowering. This is why we work in teams. To be able to share knowledge and collectively come to better decisions together.

A lot of my time spent in a position of leadership is listening and asking questions. Sometimes people just need a sounding board or a way to gain a different perspective of the issue or problem at hand. The other side of this is that if I know everything and do everything then I don’t give others the opportunity to learn and to grow. I am looking after myself at the expense of other people’s development.

Myth: Extroverts make the best leaders

Over the past few years there has been a shift towards classifying people as being either Introverted or Extroverted. On the face of it, we tend to classify people who speak up at meetings or at conferences, organise events, are good at networking and considered fun and loud as extroverts. Looking into this deeper, it appears this is just another way for us to classify or stereotype people. I believe that everyone is an individual and there are things that every person brings to what they are doing regardless of being introverted, extroverted or ambiverted.

No personality type makes a leader better or worse, instead we should be looking for the skills, qualities, values and behaviours a person exhibits when identifying leaders.

Human’s have an innate ability to do this. Leaders are the people we follow regardless of title. However, when it comes to job descriptions, we sometimes forget this and hire for an ‘outgoing, energetic, fun, enthusiastic person’ to lead our teams. These qualities, while inherently positive, are not always the things that make leaders great.  

Myth: If I fix all the problems people will respect me

This is a thought I believed for quite a while until I had the realisation that I needed to respect myself and my time first. I’ve worked in many offices where 10 hour days were expected and out of hours phone calls or email demanded an immediate response. I once got out of bed at 11 o’clock at night to head down to the office and check something for a senior. Talking about this to other people, I began to realise that this wasn’t healthy behaviour and that I wasn’t doing it because I cared, I did it because I was scared. Reflecting on this event, there was no reason why he couldn’t do it himself, or it could have waited until the following day.

Something happens when you become the person that fixes all the problems. You become the person that fixes all the problems. More and more often, people will continue to push boundaries and ask more of you until something breaks. The biggest lesson I learnt was to say ‘no’ and that I needed to respect myself first.

Myth: The team should do things my way

This is something I see people do quite often after a promotion or joining a new team and I am guilty of it myself. After being in a position where I was unable to make decisions and action my ideas, the excitement of being in a new role where I could make my mark was intoxicating. When joining a new team, I’ve since found the opposite to be more useful. Instead of jumping in, changing things and making a statement, it is better to relax, listen to others, gain trust and then help create an environment where people feel inspired to change.

When someone takes charge and makes decisions in isolation, teams can become apathetic, feeling as though their contribution or opinion isn’t valued.

Coming to the realisation that I am one person with my own thoughts, biases and fears, I can only do so much. Clones of myself really isn’t the best solution to anything. Utilising the creativity of the team by allowing people to do things their own way even if that includes making a mistake will foster a more harmonious team environment. Creating an environment where people feel safe to ask for help and share ideas so the team isn’t limited by their leader starts with giving trust and support to the team.  

Myth: If I had a different <title>, <team>, <workplace> things would be better

When things get hard, it’s easy to pack it all in and walk away. Unfortunately, if we walk away for the wrong reasons and don’t do the work to identify our own contribution to the situation, we can take our problems with us. It can be hard to be honest with ourselves, especially if we have been unkind or difficult in a situation when we had a choice to be kind and compassionate.

There are definitely reasons to want a new title, team or workplace like seeking a new challenge or opportunity to grow. I’ve rarely had success when I’ve made a change to get away from something. If stressful situations that are eerily familiar keep presenting themselves, the best thing to do is reflect and look at what was a common factor. Self reflection is not an easy thing to do and most people avoid it, choosing to deflect or blame something else outside of their control but it is the most valuable tool in my tool box. Being aware of my own contribution to an outcome, both positive and negative, allows me the space to grow and change.

Over the coming years, I’m sure other myths will be busted and I will learn new things about who I am as a person and a leader. I expect that I will change, evolve and grow but for now, my own truths about leadership are:

“It’s not about me”  

“Lead with empathy”