Viewing entries tagged

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


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.