Mot - 30 days Challenge

Mot - 30 days Challenge

Just finished participating as a mentor for the New Zealand QA and testing community (Wetest) to do the Ministry of testing 30 days of testing challenge .

The objective of the challenge is to tick off as many of the 30 challenge tasks to learn about and experiment with one testing concept. The team talk online and share their learnings in the community slack at the end of each day. Some participants even blog about their daily discoveries.

The 30 days challenge has many different themes a team can undertake to learn more about including API, mobile and performance testing as examples. I have posted below the suggested challenges

I had over a decade of QA experience before 3 years ago changing over to security in my day job so was asked help the team who had elected to do security as their challenge theme this year along with some penetration testers and policy folk.

Posted below is this year security challenges.


It was an exceptionally fun and rewarding experience for everyone and a very good way to up-skill and learn new things supported by your community and peers.

I was so impressed with the discoveries made by our team I’ve encouraged some of my QA friends to come talk about what they have learned at sone of our meetups and the OWASP day conference next year.

I think while this is something the Ministry of testing runs every year about this time there is nothing stopping anyone from taking these lists and the format to run a challenge at their work.

This could work especially well in engineering teams where developers, ops/SRE and QA are all represented. Why not give this a try in your company in 2019?

Any questions the best place as always is to hit me up on twitter (SparkleOps)

Build and grow the culture together

Build and grow the culture together

I've been thinking recently about how teams build and defend a great workplace culture. 

Places where I have experienced a great culture I've noted the company's leaders have made a considered effort to talk frequently about what behaviours they value.

But more importantly they have also provided times for the teams to reflect on and talk about what they stand for, and understand they can be driving the values and behaviour to those ends too.

Your company culture is something everyone in your company should feel they can and want to contribute to. People will build and defend a great culture together if talking, sharing and teaching others about what the team and company values is a normal part of being in the team. 

So what are some of the things that help us do that? 

Make the time to talk about culture. 

No matter how fast you're moving taking the time to stop and examine the health of your workplace culture is really hard. One of the things very common with the people I work with is having all experienced a valuable and worthwhile culture being diminished or completely lost to growth and the pace of delivery at a previous company they worked for. Especially explosive growth in a flourishing start up. 

It takes teams being able to at anytime talk about the things they value and their aspirations for great workplace with anyone in the business. Leaders should encourage their teams to continue to examine if the evolutions in their practises stay consistent with their values.

I feel strongly there is no set time to do this like a special meeting or special retrospective but more an open policy of being able to stand up and say "I think we are drifting or doing something against what we value as a team" lets talk about that!

I love working for Pushpay because this is actively encouraged in our teams and we all have a shared responsibility in refining  and  building the kind of culture we value. We are building the place we want to work.

Everyone caring about workplace culture and being empowered to contribute is the only way to me it seems now it could ever work.

We took the time to meet as a entire product and engineering collective to talk about the things we value and consider the things we need to pay special attention to when hiring, welcoming new staff and getting the job done together. These thoughts and ideas we came up with are worth frequently revisiting.

When hiring, tell people about your culture.

When hiring in looking for new people to join your team I find it's very important to talk about values and culture with the candidate.

When talking about their experiences in other engineering teams I like to ask questions like 'What are the most positive things you have experienced working in other teams so far?' 'What do you think helps make a team build great software'. Fairly open ended but i'm digging to see what they value in a workplace culture that helps them enjoy working and delivering great software. 

In turn I like to talk about the things we value in our culture. We all want to work in an environment of high trust, autonomy and we are learning and growing because we have the freedom to change what we do. We value quality conversations with one another, we value transparency and empowering each other especially with our Devops culture. We want work in a blameless and just engineering culture where we hold the belief our fellow team mates act in our best interests with the information and skills they have available to them. 

This is a snapshot for them of the kind of things we value where I work and If a candidate smiles and nods and gets excited I gain confidence we want to welcome them to the team. It's exciting when I know we can have people join the team who are likely to care about and value the same things we do and grow our culture with us.

Helping the newcomers when they arrive. 

While growing a great workplace culture look to your more established team members and seniors to include culture in the on boarding experience of the new hires. When new people join the team be alert to opportunities to work through and discuss your culture and values as part of their first projects at your company. 

A great example of this would be helping someone who has never written a blameless post mortem do so. I wrote a bit about understanding just engineering culture and post mortems here if that's a practise you've not heard of before. 

Besides conducting the post mortem to a high standard and showing them the process ensure you explain the value it brings to them, the team and your community of engineers. So it goes far beyond it being an exercise in documenting a engineering incident and writing mitigations.

Being able to understand that a just and blameless culture helps us all move faster free from fear of punishment puts all of us in position to take accountability, share deeper learning with each and grow stronger and better as team.

Explain also that blameless culture goes beyond dealing with engineering incidents and we are making a commitment to each other to work and learn together where we believe our peers are carrying out their work to the best of their abilities at all times.

Where we may disagree or see someone struggling we shun politics and finger pointing for having quality conversations and helping to teach one another. 

Teams can make a real difference spending the time with newcomers to show the culture in action and explaining why it's something we value. When we do this we can help ensure our new team member will want to defend these values as much as we do as we grow. They can then teach others in time. 

Teams often practise thinking about what they value.

One practise I've seen recently on a significant infrastructure project from one of our SRE team lead was during a project kick off asking the team to define the values the team would try to uphold in executing the work.

The team were given the freedom to all contribute the values they thought would make their project a success. They put forward values like 'We want to design our new system with production proven technologies' and 'We won't sacrifice the security of our platform for speed or convenience'.

I loved seeing this. The team are practising making a considered effort to talk about what they value and being open enough with each other they can reflect on and work to uphold them. 

While not as big as something like thinking about the overall engineering culture it makes it normal to look at how we work as a team and as a company and be able to work together on strengthening the kind of culture we value. 

Share learnings with others often.

Having a wiki page or slack channel dedicated to culture is a really great idea. Companies which I look up to like Slack, Etsy, and Google often share with the engineering community their practises and learnings that help their people create a great workplace culture. Being able to share that with your teams to ignite discussions is great.

Internal workshops and facilitated discussions are also great for this. Our practise guilds often bring up our culture and how we can maintain it together as a team. Team members have run sessions internally and at conferences on things like imposter syndrome giving everyone a chance to share their experiences and things that help them care for themselves and one another which is something we all value. 

I hope this post helps in starting some reflections and  conversations with your teams. See what they think about the culture you have and how you can look to build on and share the good things and work towards defending it as you grow together.  

I'm always keen to chat and hear your thoughts. Im pretty fond of twitter so why not say hi? @SparkleOps


The trouble with Unicorn Rentals - AWS Shine DevOps Day 2016

The trouble with Unicorn Rentals - AWS Shine DevOps Day 2016

Yesterday in the lead up to the AWS summit I got a chance to attend a day of fun and learnings participating in the Auckland AWS Shine Devops day.

We were in the business of renting Unicorns (imagine my glee) which unsurprisingly as the demand grew for Unicorns as a service so did the system load, unexpected deployments, security shenanigans and everything in between. There was carnage and lots of it. 

Unicorn Rentals was launched abruptly with a *ahem* "guys its live" heres a run book (of sorts) good luck! And before we had time to blink we were into game day mode with production traffic and customer transactions hitting us.

We had to scramble. Being paired with a few engineers who are total strangers with no shared ideas and values about how do a very very difficult job resulted in our team Magic Sparkles having our production environment unreachable or  on fire for hours on end throughout the day. 

The game was never meant to be easy. To be fair on us we were down a few key things from the get go. Let's talk about that ...

No established way of sharing information

My first comment to my team mates just seconds before we found out the site was live was "I think we need something like Slack or Hipchat, or even just google docs just to share information with each other?". There was a general agreement this was a good idea but was cast aside the second volumes of paying production customers started ordering their Unicorns. 

We moved to verbal communication because after all we were sitting next to each other. Im sure I don't need to explain this didn't end up working in our favour. I think the most common thing we said to each other as things got rapidly hotter were "What are you doing now?" or "Have you done x yet?". Under pressure it got harder and harder to remember what had be done and what had not.

The greatest thing about slack and ChatOps in general is when you or other engineers are in trouble everyone can what's happening and especially teams 'on the outside' can see a call for help.

When our load balancer was dropping traffic and none of us knew what do I can't really begin to describe the despair of watching transaction after transaction fail and have no way to track our troubleshooting progress  or call for help. 


We had access to metrics. AWS is rich with all the metrics, monitoring and options to trigger on alerts. Everything a Devops team could ever want. But they were not setup, that is what the Devops crew for Magic Sparkles had to do, and quick. 

It was not long before issues started to arise and we were reactively trying to figure out what do about it without the right information and we started actioning changes in production based on diagnostic theories. Once we found a live dashboard of customer transactions metrics pictured above I was at least able to speak to our relative health by saying we were up or down. Pretty dire.

Even then it was only once something had failed us and we were dropping transactions on the floor were we putting in our health checks. I'm mindful that this was all part of the of the game but It did make me reconsider how often we think about the metrics we actually need to stay standing let alone be proactively keeping our environment in good health and scaling appropriately. 

Transparency for our small team again was an issue. I'm used to having all these critical metrics pushed into Slack for everyone to see. All engineers not just the Devops (or SRE) team are able to see right away if a change has negatively impacted production in someway and we can start to fix it.  

Without this diagnosing the issues troubling us and taking appropriate action took 10x longer as no one was playing with a full deck of cards. What a nightmare. This needed to have been done well before we went live with anything. We were doing our best given the circumstances, in a 'this is fine' kind of way.

No leadership

One thing that really stuck out for me was the absence of direction or leadership. This is not something I'm framing blameful way or a reflection on myself or my team mates. 3 complete strangers who have never worked together were hurled into a game of keeping a cloud production system from burning down was never going to be easy. But no one was driving. 

I don't think anyone in my team felt comfortable on any level standing up and taking charge. Im a QA manager who has done some work for our SRE team on occasion and had my very first experiences with AWS on a tech essentials training course just days before. I can be a great contributor but I am not the guy you want leading a devops team on game day.

We did have experienced operations engineers in Magic Sparkles and we still struggled knowing if what we were going to do was the right thing. 

A team leader would have given us steering and helped us asking the right questions to empower us to make sound decisions and solve the problem ourselves. Instead in a leadership vacuum the uncertainty and lack of game plan and coordination, all the things we really needed to function as a performing team. We really suffered ... and lets not forget  our sad customers who couldn't rent Unicorns! If anything people retreated to the comfort of trying to be a good individual contributor. 

AWS staffers saw us on fire and while cautious to not give us an unfair advantage assisted us by getting us to ask the right questions and supported us making the moves we needed to in a way a great team lead or tech lead would have to get us back up and processing customer transactions.

Team leadership in its own right is something I will talk about at length in other postings. What I can say is having to watch production burn and feel helpless as to the next steps made me really think about the value of the amazing tech leads I work with. 

Poor run book and documentation.

Part of the game day challenge was inheriting a woefully inadequate set of technical documentation for Unicorn Rentals operations. 

Having to figure out how our application worked and was built in AWS while it was on fire was not much fun for us or our frustrated customers. We needed documentation on application design, our deployment process, our metrics and had no run books for when things went wrong. 

Many of the reactive infrastructure changes we made to try and put out the fires had no decision register, implementation / comms plan, back out plan or test support. 

This was a frightening world to operate in. Thinking of myself as a new engineer to this environment we were not setup for success and it's highlighted how important it is to create documentation this for you and your fellow engineers.

We have a practise of linking specific run books from past operational changes to alerts being pushed into Slack. When engineers do this they are setting up everyone around them to help fix an issue that's happened before even if they are not there. Magic Sparkles could have really used some of this sort of documentation and support on the day. 

Wrap up

What an excellent experience to be part of. A big thanks to the AWS AU/NZ team for putting it on for all of us. Besides the very key part in getting hands on time with AWS console and all the various products its given me a lot to think about in terms of what really matters in contributing to and running a great Devops / SRE team. 

Did you go too? How did your team get on? Keen to chat, best place to find me is usually on twitter  @SparkleOps

Lost in the Everfree - Self care and spotting burnout.

Lost in the Everfree - Self care and spotting burnout.

So you find yourself deep in the forest, everything around you seems to be magically thriving of its own accord. The whole remarkable sometimes dark and mysterious ecosystem just keeps on growing, changing and going through its natural cycles. Except you. Stuck in the middle of it all. You are worn out and you're no longer sure you are still in going in the right direction anymore (despite having a map). That or you are completely stopped, ground to a halt. You know you have to go on but you just feel like you can't.

What happened? You had a plan going in? Other smart Daring types have entered this forest before and have emerged victorious.

How it did come to this?

I am alluding to how some of you (and I) feel as tech people when we are burned out but failed to spot the warning signs we were heading towards it. 

Truth is though while we are always pushing to be building better and faster there is one part of the process we are sometimes forgetting to maintain and give attention to. Ourselves.

Be it your site reliability people, product team, testers or developers we are all running at a furious pace so we can perform our part for the team to keep the deploys rolling out.

You need to take care of yourself and have your own scheduled maintenance lest you wind up slipping into to bad habits, poor decision making and eventually burnout. 

I'm bad at this but i'm learning. It's my hope sharing my recent reflections will be of some benefit and or we can start a conversation together about this.  I know i'm not alone in my struggle with balance and self care by a long shot. So. 

First of all how often do you give yourself a regular health audit? There is a great 'how to' post by blue hackers  which I revisit often. Despite feeling like a savvy and organised person it never fails to amaze me through the pace of work / life how the basics of self care can slip.

When these things start to fall by the wayside it's time to rethink things. Being good at spotting deviations from your normal routines and practises of self care will really help avoid winding up in burnout territory. So what kind of things am I / the blue hackers post talking about? 

  1. Awareness of your work life balance and your schedule for both work and fun/relaxation.
  2. The home and work environments and how you keep them.
  3. Your diet. Getting the right food, hydration and watching the refined sugar, caffeine, wine and beer intake.
  4. Understanding your levels of stress, fatigue and knowing your triggers. 
  5. Exercise and quality sleep. 
  6. Seeing triggers fire or signs of brain buzz, being forgetful, moody, anxiety, over personalising things, imposter syndrome. Are there some obvious red flags already up you haven't noticed?

You are not weak or sub standard engineer if one or all of these things is starting to show up wanting. It really happens to us all. Ill say this much, some companies in our industry have taught us all some seriously unhealthy attitudes to work/life balance.

I grew up in a professional environment where output was sustained by insane amounts of coffee, red bull and weekend partying as a means to blow off steam. It took a talking too with a doctor to realise this isn't at all sustainable or normal and the productivity you think you have isn't quality and its using you as the fuel for the fire.

Things are much different now days. Im fortunate enough to work with and for people who care as much about me and my mental health and wellbeing as they do their results. They understand why it matters as I strongly suspect they too were a product of the same environment and expectations in which I started my career. 

So if you are noticing things start to slip take some time out and decide if you can fix the things that are giving you trouble or you want to reach out for some help. Its entirely personal and up to you. This is not a quiet moments reflecting over things between Halo ranked matches and a nice 10.30pm double shot espresso (Remember those days? Were they just last week?). This means actually taking time out over a weekend or a small holiday to really think this stuff through. 

Be ready to take some time to go for a walk with someone, maybe a coffee and just talk it through. It can be this kind of rubber duck debugging for people that can help you really realise its time for a check up or maybe even to talk to a mental health professional. By the time you have short list of small tweaks to any of the aspect of your own self care I guarantee you will already start to feel a ray of sunshine breaking through the tree line. 

The other critical thing I have had to learn and re learn again and again is the importance of actually having leave booked and having plans for it. If you do not have a scheduled break to look forward to there is nothing but forest in front of you. You may not have made it through yet but time out is as good as checking our map against a GPS. 

When you look at your GPS you can check up your idea of where you are at, where you are headed and indeed if you are still taking the smartest route to get there. My own personal goal this weekend is to project the amount of leave I have have this year and break it into pockets of small holidays and events I will have charted as way points. 

Burnout is a terrible place to be. Love and respect yourself enough regularly check up on  routines of self care and balance. 

I hope this post finds you well and your spending your weekend dreaming up your next adventure when you get to other side of the forest. 

Mental health is a huge subject and largely one that should ideally be talked about with your support network of close friends, doctors and or mental health professionals. If you are in a bad place be it burn out, anxiety, depression and find yourself in crisis do not ever hesitate to ask for help.

In New Zealand we have Lifeline if you have an immediate need to reach out. Contact by phone Auckland (09 5222 999) or elsewhere in New Zealand (0800 543 354).




Sharing with Slack <3

Sharing with Slack <3

I've been looking at some of the Slack teams I participate in recently and been observing the various channels which promote positive information sharing in a culturally significant way. 

Slack has changed the way we work significantly for the better with more transparency, speed of communication and less meetings.

Project teams have a specific place to organise thoughts and talk through project matters (especially great if you have remote workers or 3rd party suppliers).

From  a DevOps culture perspective a vast amount of metrics and alerting can also be piped into specific channels. Great for unlocking that information for all to see and allow anyone in the business to take note and begin collaboration. 

These are the more obvious uses of slack. What I wanted to share were just a few of the nice channel additions I've seen in teams which promote a culture of information sharing and positive collaboration / learning in maybe less obvious ways. 

1. #TIL (Today I learned).

Having a channel where everyone can share anything they learned today is great for engineering and product teams. Odds are if you learned something today about a nuisance or improvement that can be made, other people in your team will benefit from a headsup.

2. #Thanks 

This came to mind specifically after talking with @lady_nerd from in where her team had created a #thanks channel to call out great things done by or help given to their peers.

Think about this for a moment. When someone gives you a high five publicly it's a massive lift right? Are we going so fast now we don't have time to write the odd little love note to the awesome people around us? I hope not.

Its also means if you get some love from customers via customer support, Twitter or other channels from users drop it in your #thanks channel. Its awesome when you're in the thick of it to know your team's work is hitting its mark with the users and customers out there in production. 

Letting people know they value each other's input is important!

3. #Guilds

Testing guild, UX guild, and front end guild? Do you have channels like these? I really enjoy having a space thats not dedicated to the day to day or project specific discussions but instead to a general channel where you can talk about improving your craft as a team or community. Its up to you what goes in here but simply making such a space available will hopefully encourage contribution and collaboration. 

4. #Readings #blogs #RSSfeeds

Now I get there are many ways to skin the cat on keeping up to date  on your favourite tech blogs and news sites. There are many things like Feedly just for this. Why is this even a culture thing?

Well if you value sharing sources of learning with everyone it's better to do this as a community in a topic specific slack channel. You can invite other members with a common interest in and share your sources of good reads and in turn have them do the same for you.

I started channels for topics I'm interested in devops and security. In particular for security I post in NIST NVD / US CERT digest alerts to surface specific vulnerabilities I need to know about.

When I started surfacing these people began to ask where I found this information. I invited them to the channel and now they are eyes on the same material. Since i've been given many great additions to the list of things to pipe into my readings channels from other members. 

I use IFTTT to watch the RSS feeds I care about and have a recipe slack post when a new article lands. 

Now one word of caution here sharing information is great but be careful how you do it. Your company slack contains sensitive information so you need to be very careful about the bots and external services you elect to integrate with it and what access they have. Before connecting anything to slack make sure you know what your giving it the keys to!

Im keen to hear some of the channels you guys have in your slack teams which open up information sharing and collaboration.

Lets chat? I'm usually found on twitter @SparkleOps

Making standups a meaningful experience.

Making standups a meaningful experience.

I have been thinking about team and company standups recently and what purpose they serve in both cases. I used to think both were simply a ritual for keeping everyone updated, reporting and finding out if further offline discussions needs to happen.

Having experienced a different culture and way of doing things where I work now at @Pushpay I figured it was worth sharing the simple few tweaks we have introduced to our standups.

We have a few objectives we aim to satisfy in our standups so they give us real value in both our team's daily standups and the larger product and engineering standup. For both daily and weekly we speak to:

1. What we did yesterday/last week.

A progress update makes sense for any standup. That hasn't changed. Teams share thier progress.

2. What is our mission for the day/week.

Teams set themselves a list of things they want to achieve or ship during the week and each daily update becomes our check that we stay focused on achievable things we can continuously deliver towards a weekly mission.

When we are at weekly standups everyone gets a turn sharing their teams update with the wider group. When we do that together we all get a better sense of contributing a piece of the larger puzzle we are solving as a whole engineering/product team for us and our customers.

3. What I learned 

Not so much in a daily sense (we have a today I learned Slack channel for this) but we really encourage teams to share a learning experiences every week with everyone.

Especially if the team has had a blameless post-mortem incident. Its important to note talking about incidents isn't an occasion to dread. 

4. Celebrate your successes and failures.

It's very very easy in tech no matter what you're doing to feel like you're playing tetris. As soon as one line is built, it ships and your focus is back on the falling blocks. Take some time to acknowledge what you have achieved together and what you and your teams have learned together. 

We are genuine when clap and cheer on the other teams when they ship features. It's exceptionally positive. 

We do the same thing in celebrating a blameless post-mortem. If your team has captured significant learnings and is on the road to improving as a result. That's not failure that's a success. 

5. Be brief. 

Short and to the point is good. 

These values that shape our standups created a for us daily and weekly sessions that give a real sense of purpose and motion. Stuff is happening in my team and the teams around me. At the pace at which we deliver (multiple drops to production daily) it gives me immense satisfaction to hear about the things we are building even if I'm not currently with that particular team. 

We know internally this is working well for us as a few people who now work here who have attended our company meetups on their hiring day saw it as a significant indicator of what it's like to work here and what we as a team of engineers and product people value. 

These are such small tweaks but are culturally significant in thier benefits. 

I'm genuinely keen to hear what you think about these values and what is working for your engineering teams. Say hi on twitter maybe ? @SparkleOps

Understanding a Restorative Just Engineering Culture

Understanding a Restorative Just Engineering Culture

I recently as part of a facilitated discussion (The Codemania Conversations unconference) where I stood with my peers @joshrob@petegoo and @kiwipom from Pushpay and in discussing blameless post-mortems and just engineering culture talked about my own difficulties I had experienced understanding how to be an effective participant in our blameless post-mortems. 

The entire concept of running a post-mortem after an incident was a new thing to me, I had learned about post-mortems when joining Pushpay in 2014. I had some exposure and been part of many discussions around this blog post by John Allspaw. Initially it seemed like a ritual, a good one but I certainly didn't understand how beneficial it was and is such a key part of being able to move fast, experiment as an engineer and not fear change. 

I had come from a background where the attitude to incidents and finding a remedy was entrenched in ideas we must hunt for the the single root cause of an issue, weeding out the careless bad apples and corrective measures being dealt down to those 'responsible'

When something would go wrong a lot of the behaviour surrounding the remediation was driven by fear of punishment and resulted in highly political and often combative meetings. The output from which would be mitigations that didn't catch all the problems and usually the addition of process being layered on so 'this can never happen again'. Usually from a management view while those involved awaited another meeting to find out what was to be done. 

I now understand how it was both toxic and expensive use of our energy and didn't even give us the kind of mitigations we as leaders would hope for. If anything in some cases it was making us go SLOWER. But that is just how things are? Right?

So a blameless culture of trust and accountability seemed great, but was it actually real? One of my peers insisted 'You want people to know something went wrong, that way we can fix it and probably whole bunch of other things all together!'. 

So what was it that really got me to understanding blameless post-mortems and restorative just engineering culture?

Well  it was watching these small video talks by Sidney Dekker on his site here. There is just four sessions and they run about ten to fifteen minutes long. 

Module 1 — Introduction
Module 2 — Retributive Just Culture
Module 3 — Restorative Just Culture
Module 4 — Second Victims

I really feel these videos are a critical first step for anyone seeking to understand why we should strive in our teams and companies to build a culture that embraces restorative justice by contrasting them with systems that employ a system of retributive justice.

A retributive justice culture needs people and particular systems be at fault and be the root cause. We had a incident and something is to blame!

It then follows there must be some process or decision tree that is gone through to decide what corrective actions are going to be taken and against who. During this process it's very likely as we determine who is to blame the finer detail around the incident and its time line become obscured be it through fear and or political behaviour.

This loss of the finer detail is one of the most critical reasons why blame is so harmful and toxic. Its likely some or all of the learnings a community or team may learn from an incident will become obscured or silenced through fear of punishment. Especially from the people who were involved who are the ones best able to tell the story of what happened. After all they were there!

Restorative justice culture on the other hand is one based on trust and accountability. A honest timeline of events produced by those involved with the assumption that they acted in everyone's best interest to the best of thier abilities with the information they had at hand. The exposure to all sort of things that contributed to an incident will become apparent if people are not afraid to share thier story with their team.

When the story is told with all the finer detail out for all to see we start to see other failures in our systems which also contributed to an incident. Its almost never just a single thing or root cause that triggered the incident.

Here is where we get some of the richest mitigations and learnings as a team and community of engineers.  We often find a bunch of mitigations we can do as a team to reduce our peers being in a risky position in the future. And that is a really great place to be let me tell you. 

Restorative justice culture enables us to come together as a community of engineers and learn from failure and really improve. 

So ask yourself honestly ... which world would you rather live in?

I plan to talk a lot more about Blameless post-mortems in future posts but I hope the Sidney Decker videos helped contribute to your thinking about the kind of engineering culture you wish to build in your team or company. 

Hello there ! Starting to talk about engineering culture.

Hello there ! Starting to talk about engineering culture.

When I decided I wanted to start writing I had a great many things I thought I wanted to talk about, share and discuss. Once I left all these topics and ideas to tumble dry in my head for some days one of the most important things to me was engineering and company culture in tech. But why?

Culture is (in part) the beliefs and values which shapes how and what drives us to do our craft with our peers. What values and beliefs are going to enable us operate a happy motivated and successful team? How do we uphold them? All worth talking about! 

Heres something that really stood out as an example of why culture really really matters.

I was recently talking specifically about devops practises and culture with @petegoo, in which  he introduced me to this O'Rielly Velocity conference talk '10+ Deploys Per Day: Dev and Ops Cooperation at Flickr' by John Allspaw and John Hammond.

Its very easy to get lost in the weeds of the specific development techniques or operations processes that fused to gave light to the devops culture at Flickr. But if you watch through this talk there is a strong emphasis on the culture of trust, mutual respect, lowering risk and fear around change. Without which its hard to image the developers and operations people creating such a great set of tools, systems and collaborative processes to build Flickr.

You can have the most eloquent continuous integration implementation, funky slackbots chirping away all the key metrics and alerts and your own version of Etys morgue for your post-mortems ... whatever. If the right culture is not behind it driving all your people its going to be hit and miss. 

Im on a quest to learn and chat with others tech people to get a better understanding of what makes a great engineering culture. Anywhere in tech, be it QA, Security, Product I want to see what is working and what is not and why.

This is my place to share those learnings and talk with you about your thoughts and findings too.