Category: Culture First Engineering

Categories
Culture First Engineering Email List Family Justice and Politics Personal Software Engineering

What Culture First Has Looked Like For Me

I’ve been working at Culture Amp for over 8 years – 4 times longer than any other place I’ve worked. Clearly something here is working well for me.

When Didier Elzinga recently stepped down as CEO, it made me realise I want to share parts of my story here and why it’s been good, because it ties into the “Culture First” idea that’s the driving force behind the company he, Rod, Doug and Jon founded.

For me it’s really important to be working for an organisation with a positive mission. Culture Amp’s mission fits this: “to create a better world of work”. Full time workers spend a third of our time at our jobs – improving work is a way of improving lives. Culture Amp makes a software product to help companies be good to their people, to be “Culture First”. The idea isn’t vapid: there’s a firm belief, backed by research, that being good to your people is a path to high performance, positive impact, and business success.

The part of this mission that has resonated with me the most is not just making the product, but proving to the world that the idea is real. Culture Amp wants to be the example that proves the theory.

Here’s what “Culture First” has looked like for me in my 8 years here.

“We borrow our time at work from people and things much more important to us than the work”.
Didier Elzinga

Culture First: a beautiful reciprocity

There’s been a beautiful reciprocity in my experience working for Culture Amp. The company has been good for me personally, and I know I’ve provided my share of value to the growth of the business on its path from 150 employees to 900, and to over 10 times the annual recurring revenue.

Here are some concrete examples of what these mutually beneficial exchanges look like:

Respect in the interview process: The technical exercise was interesting, the people who interviewed me were friendly, curious, and were clearly great engineers. I am not naturally a strong negotiator, and I had given a conservative salary range when asked about my expectations. But they made me an offer above the salary range I’d asked, offering what they thought I was worth, even when I wasn’t confident to ask that for myself. I felt respected. That feeling of respect is why I said yes to their offer and was excited to join.

Regular performance and compensation reviews: 3 months after I joined, I was still happy with the extra pay compared to my last job. I had my first performance review, and they decided I was performing better than the level they had assigned me in my interview, and gave me a pay rise. I didn’t even ask for it. Since then there’s been a regular rhythm and trust – I know there will be reviews every 6 months, that they evaluate my performance against their levels, that they work hard to be fair and reduce bias, and that the salary bands are calibrated against market data. Pay negotiations don’t come naturally for me. The fact that I work somewhere with a consistent and fair process has made me feel confident I’m not being taken for granted, and has been a big part of my loyalty – and it motivates me to increase my impact, trusting it will be rewarded. Because it has been.

Supporting my tech community involvement: They encouraged me to use my interest in public speaking to submit talks to tech conferences. They allowed me to do some preparation on work time. And in return, more potential engineers heard about Culture Amp and at least a few ended up joining us and providing long term value to the company – without needing to pay commissions to recruiters! And I got to become a more visible member of the tech community and use my gifts there.

Going remote before Covid: When I interviewed in 2017, I was living in Melbourne but knew I would be moving to Perth. They said they would be open to remote work if I did my first few months in Melbourne – they had a small handful of remote engineers already. A few months in when I asked about the timing of the move – they put the question back to me using one of their values: “trust people to own decisions“. My manager asked me to think through the impact of being remote, and what would be required for it to be successful, and make a decision accordingly. I did, and it went well enough that I kept thriving. When the team lead role opened up, I wanted to try, but no one else was a remote team lead back then. They still encouraged me to apply. They trusted I could pull it off, and I became one of the first two remote product team leads in 2018. And this benefited them – two years later when Covid hit I was able to share what I knew and help the company quickly adapt to effective remote work. They took a chance on my leadership looking different, and with that experience I could then help them navigate one of the most abrupt work culture transitions of our time.

Management training: This was my first job where I got to lead a team. Culture Amp has been the ideal place to learn. I had great managers myself who I could learn from. (Thanks Kevin, Jordan and Eric!) They invested in manager training with Lifelabs right at the start of my journey. They encouraged using our own product to ensure we were getting feedback. We were given help to reduce our bias in hiring and performance decisions. Our People and Experience team helped me navigate both happy conversations and tough conversations. There was so much support available. I’ve been able to ask questions on Slack – from team trust dynamics to goal setting – and I’ve had replies from other team leads, from senior leaders, and even from people with PhDs in organisational psychology who specialise in those topics. It’s a phenomenal environment to learn to manage people. Because I’ve been equipped like this, I’ve been able to lead well. I’m proud to have seen plenty of my people promoted, and a few grow through a period of struggle and low impact and get back to a place where they’re thriving. And we’ve completed plenty of really high impact projects.

Parental leave: When my first child was born in 2018 Culture Amp offered 6 weeks paid parental leave, and dads were explicitly encouraged to take it. The company acknowledged the ways early parental leave can shift the ongoing balance of care between mums and dads, and lead to more equitable career outcomes for both parents. It also helps normalise a culture of employees putting their family first, which reduces bias against women who take their full parental leave entitlements. And of course, it gives you more time with your kids in those precious first few months, which you can’t put a price on. When my second child was born, the policy changed to 4 weeks for secondary carers, and 16 weeks for primary carers. (These days it’s 16 weeks for everyone.) Given my partner at the time was a stay-at-home mum, I applied for the secondary carer’s leave. But then, life turned out to be really hard. Having that second child was the start of prolonged sickness, mental health challenges, and an understanding of neurodiversity in our family. I needed to take a lot of time off to look after my family. I exhausted my parental leave, then my carer’s leave and annual leave. By this point my manager had been having conversations with HR and got approval for me to have the remaining 12 weeks of “primary” leave given the exceptional circumstances. They even offered to let me take it in a part time capacity to stretch it over the remainder of the year. This was an absolute lifeline. If I wasn’t offered it, I probably would have had to resign – the pressure at home was so huge. It took a few years for more support at home to be available, and for me to find a new and more sustainable “normal”. Getting through that time was incredibly difficult. The way my managers, senior leaders, and the HR team looked out for me, provided options, and trusted me even through a period of struggle and lower impact, earned them a huge degree of loyalty from me. They trusted me – and trusted in my future impact – and did what they could to help me through one of life’s toughest seasons. And in return, I’ve been able to give several more years back at a strong level of performance.

So you can see there has been a reciprocal trust and investment and benefit between me and the company.

Shared humanity

There’s another story of my time at Culture Amp that is far more human and can’t be quantified in growth rates for the company or career growth for me.

Early in my tenure someone new joined our team. They were a brilliantly sharp engineer who overlapped in a lot of the same technical interests and specialties as me, but whose ability to think about complex systems, both technical and social, allowed them to identify patterns others didn’t see. It was wonderful to watch their strategic thinking at work. I learned a lot from them and working with them was a highlight of my career.

They were also the first friend to openly talk to me about the experience of being autistic. We’d been working together for a few years, and my understanding of neurodiversity was pretty limited. I think when I noticed people struggling with sensory overwhelm in large group settings I would have put it down to an “extrovert / introvert” dynamic and not thought more about it.

Culture Amp has a company value “Have the courage to be vulnerable”, and one way of expressing that is sharing parts of your authentic identity at work. But doing so requires trust. That trust built up over a few years, and eventually there was enough for them to talk openly with me about being autistic.

It was a beautiful thing to have someone I respected so much, and who I counted as a friend not just a coworker, help me understand how their motivations at work play out, why many office environments are overwhelming, why restructures and team instability can be very destabilising, and why some software problems are really well suited to their brain, and others are not.

They’d take time to explain parts of their experience, like why you can struggle to focus on the task in work hours, only to struggle to stop in the evening – they explained the struggle isn’t the ability to focus, the struggle is the ability to regulate focus. And that includes struggling to stop even when hyper-focused at an inconvenient or unhealthy time.

Or they’d send links to articles like this that help reframe communication problems as an equal burden between someone neurotypical and someone neurodiverse1. Things like this helped me understand neurodiversity so much better, and removed any sense of stigma from it.

Just a couple of months after these conversations started, we had the first signs that my eldest son might be autistic. He was three, and his mum had interrupted a repetitive behaviour, and his response was an extreme meltdown. It started a conversation, and a family friend who is a school psychologist came and talked to us about it. After watching him play, she said we should definitely be seeking a diagnosis.

It was a big moment. Did my son have a disability? Would he grow up normal, or would this make everything different? I loved him and his quirks. I didn’t want to start seeing him differently. When I talked to friends about it – I’d well up with tears, I didn’t want the world to not appreciate him. I didn’t want to not appreciate him.

In that time, with all of the big questions that it brought up in me as a dad, the thing that gave me the most encouragement was my friend at work who was brilliant, kind, authentic, and generous. I had a picture of how beautiful an autistic life can be, and it gave me hope and reframed the diagnostic conversation for my son from one around a deficit to one around understanding him better. I’m incredibly grateful.

There’s also been that same reciprocity. Things like understanding the Interest Based Nervous System have made a huge difference to how I manage engineers, divide work, plan projects and line up growth opportunities. I’ve been a more effective manager, and it’s also helped me. My friend encouraged me that, with or without a diagnosis, if the strategies help, I can learn from them.

Someone at work also started a Slack channel for parents of neurodiverse kids. I literally cried when I found it. Parenting neurodiverse kids well as they’re adapting to a world that isn’t always friendly to their brain is no easy task. Realising I wasn’t alone, and that workmates I’d collaborated with had the same struggles was such a big moment of feeling seen and understood. They were here, sharing stories, providing mutual support.

My understanding of myself, my friend at work, my children, autistic people – and humans in general! – was made so much richer, because there was a “courage to be vulnerable” moment where someone opened up and shared so openly with me what their experience of being neurodiverse was like.

The value of Culture First

And here-in lies my point in writing this blog post. Culture Amp has tried to model a culture first approach and show other companies that it’s a good way to do business. And in my story – the ways the company has supported me has seen a return on investment – I’ve been more engaged and higher performing.

But it’s more than that transaction – some of the value created isn’t captured by the business. In my faith there’s this idea that “you shall not reap all the way to the edges of your field” – that you shouldn’t capture all of the value, and that it’s good if some of it is left for the community.

A culture first approach to business makes sense through an economic lens – more than enough of the value you invest in your people is returned to the business – it’s a smart strategy. But there’s a whole world of value that isn’t captured by the business, but enriches the lives of your employees, and their families, and our communities. It might not show up in your company performance dashboards, but this is the impact I most care about.

And I suspect it’s the impact Didier most cared about when he, Doug, Rod and Jon founded the company. For having the courage to start something and try to do it “Culture First” – and for the impact it’s had on me and my family and my community – I’m grateful.

—

  1. This was fascinating – in one study participants played the game “Telephone” – where each person passes a message down the line and you see how different it is at the end – with autistic groups, with non-autistic groups, and with mixed groups. You’d think that because part of an autism diagnosis is having communication deficits that the autistic group performs poorly. It’s actually the mixed group that suffers. ↩︎

Categories
AI Blogmarks Culture First Engineering Software Engineering

AI articles and reading

I want to start capturing my notes from important articles I’m reading about the impact of AI.

AI Doesn’t Reduce Work—It Intensifies It

by Aruna Ranganathan and Xingqi Maggie Ye

While this may sound like a dream come true for leaders, the changes brought about by enthusiastic AI adoption can be unsustainable, causing problems down the line. Once the excitement of experimenting fades, workers can find that their workload has quietly grown and feel stretched from juggling everything that’s suddenly on their plate. That workload creep can in turn lead to cognitive fatigue, burnout, and weakened decision-making.

They named 3 ways it intensifies

  • “Task expansion” – things that wouldn’t have been in their role scope before they might try now. Eg engineers drafting communication, or designers writing code. This leads to more work for yourself, but also more work for those who have to assist or review the out-of-scope thing you’re doing.
    • “Engineers increasingly found themselves coaching colleagues who were “vibe-coding” and finishing partially complete pull requests. This oversight often surfaced informally—in Slack threads or quick desk-side consultations—adding to engineers’ workloads.”
  • “Blurred boundaries between work and non-work” – “Many prompted AI during lunch, in meetings, or while waiting for a file to load. Some described sending a “quick last prompt” right before leaving their desk so that the AI could work while they stepped away.” Being able to direct an agent from your phone blurs the lines significantly. 100% people can now work from their toilet breaks 😂😭
  • “More multitasking” – you’re more tempted to start several tasks and switch between them, giving you a sense of powering through your backlog. But the extreme context switching has a cost.
    • “While this sense of having a ‘partner’ enabled a feeling of momentum, the reality was a continual switching of attention, frequent checking of AI outputs, and a growing number of open tasks. This created cognitive load and a sense of always juggling, even as the work felt productive.”
    • The words felt productive remind me of this study. I suspect there is more of an AI speedup now, but the mind blowing thing here was that engineers predicted they’d be more productive, and reported that they were more productive, even when the observed results were that they were less productive. Our “feeling” of productivity isn’t a good one to trust.

For Culture Amp especially, we care about these kinds of problems. A lot of our research is into how to have both a “high performance” and a “high engagement” culture (with wellbeing and sustainability being a key part of the engagement measure). If you get both right it’s incredible for the company. If AI helps you be high performing, but not in a sustainable way, then you become strained, and it’s not a good long term win for the company.

How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt

By Margaret-Anne Storey

Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.

Side by side comparison. Technical debt - legacy code, quick fixes, buggy logic - messy code & complexity. Cognitive debt - lost understanding, knowledge gaps, team confusion. Overwhelmed developers

She gives a simple example from a student team losing understanding of what they’ve built:

But by weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected. When I met with them, the team initially blamed technical debt: messy code, poor architecture, hurried implementations. But as we dug deeper, the real problem emerged: no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together. The code might have been messy, but the bigger issue was that the theory of the system, their shared understanding, had fragmented or disappeared entirely. They had accumulated cognitive debt faster than technical debt, and it paralyzed them.

Our team has talked about how architectural decisions made when vibe coding are usually not good long term decisions. We talked about a playbook that looks like:

  • Vibe code a v1 to learn as much as we can (about the problem, technical approach, UX issues etc)
  • Don’t waste time polishing the v1 and making the code nice, we’ll throw it out
  • For v2, plan your architecture and abstractions really carefully based on what you learned in the vibe-coded v1.
  • Write out key types and function signatures yourself
  • Document edge cases, business logic decisions, things we want tests for.
  • Get review from another engineer on this plan
  • Then get an agent to help build out v2
  • And this time do the work to clean the code up and make it nice. But it’ll be building within the abstractions you planned.

One other idea that comes to mind is keeping a documented understanding of the project in the README (or elsewhere in the repo) that includes:

  • What it is and what it does
  • The problems and constraints it solves for
  • The architecture and key abstractions chosen
  • The approach to automated testing, and what manual testing is required

You could then make your agent coding process include reading this context at the start of a session, and writing it up at the end of a session.

Anyway – they’re ideas at solutions, but I think this article is interesting for naming the problem: Cognitive Debt, when it doesn’t even matter if the source code is in good shape or not because there’s no understanding of what the thing is, or how it’s supposed to work.

Harness Engineering

Birgitta Böckeler

It was very interesting to read OpenAI’s recent write-up on “Harness engineering” which describes how a team used “no manually typed code at all” as a forcing function to build a harness for maintaining a large application with AI agents. After 5 months, they’ve built a real product that’s now over 1 million lines of code.

I hear about people doing this more, and I think it’s going to require a fair bit of supporting structure (a “harness” they’re calling it) to make sure the agent builds in a sustainable way and can stay useful even as it grows.

The categories she pulls from their post are interesting:

The OpenAI team’s harness components mix deterministic and LLM-based approaches across 3 categories (grouping based on my interpretation):

  1. Context engineering: Continuously enhanced knowledge base in the codebase, plus agent access to dynamic context like observability data and browser navigation
  2. Architectural constraints: Monitored not only by the LLM-based agents, but also deterministic custom linters and structural tests
  3. “Garbage collection”: Agents that run periodically to find inconsistencies in documentation or violations of architectural constraints, fighting entropy and decay

I’ve put most of my AI thinking into context engineering so far, and have started pondering what architectures are going to be more successful. For example, offering abstractions that help keep code modularised so agents can navigate it effectively within their context windows, or providing better feedback loops so it can iterate towards a solution rather than write code and hope. The third one – “garbage collection”, I’ve hardly started to consider.

Categories
Blogmarks Blogmarks Culture First Engineering Microblog Software Engineering

“Workslop”

This post on HBR defines “Workslop” – AI-Generated “Workslop” Is Destroying Productivity. I like the term and definitely have felt the pointy end of it:

On social media, which is increasingly clogged with low-quality AI-generated posts, this content is often referred to as “AI slop.” In the context of work, we refer to this phenomenon as “workslop.” We define workslop as AI generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task.

…

The insidious effect of workslop is that it shifts the burden of the work downstream, requiring the receiver to interpret, correct, or redo the work. In other words, it transfers the effort from creator to receiver.

Kate Niederhoffer, Gabriella Rosen Kellerman, Angela Lee, Alex Liebscher, Kristina Rapuano and Jeffrey T. Hancock in AI-Generated “Workslop” Is Destroying Productivity

From their survey some of the interesting bits they pull out about the cost:

  • The reported time spent dealing with workslop is 1 hour 56 minutes per instance.
  • “When we asked participants in our study how it feels to receive workslop, 53% report being annoyed, 38% confused, and 22% offended.”
  • “Approximately half of the people we surveyed viewed colleagues who sent workslop as less creative, capable, and reliable than they did before receiving the output. 42% saw them as less trustworthy, and 37% saw that colleague as less intelligent.”
  • “One third of people (32%) who have received workslop report being less likely to want to work with the sender again in the future.”

Ouch! 😬

I think I’ll be pointing to this article in future when I need to help some realise that lazy communication is unfair to the person who has to receive what you’ve communicated and make sense of it.

Categories
Culture First Engineering Software Engineering Speaking

Paths Beyond Senior (resources and links)

I’m presenting at DDD Perth 2025 today. It’s a great event, promoted as “A one day, fully inclusive, approachable and affordable tech conference for everyone.”

My talk is “Paths Beyond Senior“, and here’s the links in my talk and slides. I’ll post the slides and recording when I can.

Links and Resources

Books

Slide showing photo of the book Radical Candor by Kim Scott
Radical Candor by Kim Scott. Great book about being a manager. The tagline is “Be a kick ass boss without losing your humanity”. The “3 conversations” I mentioned are from this book.
Slide showing photo of the book Good Strategy Bad Strategy by Richard P Rumelt
Good Strategy Bad Strategy by Richard P Rumelt. Booktopia Link. There’s also a great blog post by Dave Kellogg summarising it.
Slide showing photo of the book Continuous Discovery Habits by Teresa Torres
Continuous Discovery Habits by Teresa Torres. Great book about how designers, engineers and product managers can work together to lead a team with great product discovery.

Categories
Blogmarks Culture First Engineering Microblog Personal Quotes Software Engineering

Drew Breunig on human connection in an AI age

Drew Breunig has great technical posts about utilising AI, but this commentary on how it first breaks – and then promises to fix – sales and hiring processes stands out.

Is there a fix for all of this? Will it normalize? I don’t know. I do know that both the examples above have created a bit of an ironic situation: the growth of AI has dramatically increased the value of human connection.

In both the job market and sales, knowing someone at your destination is perhaps the one tool to cut through the crap.

AI Creates the Problems it Solves by Drew Breunig
Categories
Blogmarks Culture First Engineering Software Engineering

Endorsing and regretting technical decisions

This post from Jack Lindamood has a format I loved. The decisions and his reflections are interesting, but I think less interesting than the format itself. What I love:

  • You keep track of all the big decisions you’ve made during your tenure in a particular company / role
  • You engage in self reflection on if they were good or bad choices, after you’ve had time and benefit from hindsight
  • You share knowledge with the community (I was exposed to tech I’ve never heard of, and had new takes on tech I use every week)
  • If we had one of these for Culture Amp, it would go a long way to clarifying not just why we use a certain tech, but if we still like it, separate from the decision of if we’re still using it.

At Culture Amp we do use a tech radar that mimic’s the format from Thoughtworks. But the “radar” UI doesn’t lend itself to reading as a whole.

I also like that he’s captured the decisions he’s been accountable for as an engineering leader. That’s fascinating when thinking about recruiting – how do you convince a new company that you’re going to be a leader with good judgement? And how does the new company evaluate if the way you make decisions – and learn from mistakes – is the right fit for them?

(Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup · Jack’s home on the web

Categories
Culture First Engineering Front End Development Personal

Li Juen Chang

3 weeks ago I heard the incredibly sad news that my friend Li had passed away. I was his manager for a few years at Culture Amp, and to remember him, I want to share a few stories of conversations we had during out time working together that I think speak to the quality of his character.

Talented, but humble

Li was a remarkable front end engineer. He was quietly productive, building high quality user interfaces faster that almost anyone else around. It wasn’t uncommon to hear feedback that he’d finished building out an entire interface on his own while a whole team of back end engineers were still working on making the data available for it. Eventually people started to notice, and Kevin Yank, our Director of Front End Engineering, asked: how do you do it? Is there some secret the rest of us could learn too?

His answer still makes me laugh. “I’ve got my code editor set up really well.”

To this day I don’t know if he was just trying to deflect the compliment, or if he really thought that was his secret advantage. Tool sharpening is definitely a thing in our industry – we like to quote the proverb “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

Li’s editor setup was simple, it wasn’t something he wasted time tweaking over and over, but it was effective. When I watched him work he spent his time thinking about the problem at hand, not trying to remember where a file was saved or trying to remember what a keyboard shortcut was.

Remembering it, I love the humility of his response – he didn’t boast, he wasn’t proud. He knew he was good at what he did, and was happy to share the things he found helpful.

Learning, to share

I remember a point where Culture Amp had just acquired a smaller company, and we were looking for some senior engineers to transfer in and join the team we’d just acquired to help them integrate their product into ours.

At first Li was interested in exploring the opportunity, but then backed out when he realized the move would be permanent, not a secondment from his current team.

We had some conversations to explore the opportunity, and he surprised me with his biggest motivation not being the desire for a lead role, or a high visibility project, or the desire to work with a team based in the US, but instead the chance for mutual learning. He wanted to work with an established team, see what he could learn from them, see what he could teach them, and bring that back to his existing team and work, sharing what he had learned. Which explained why he was interested if it was a secondment, but not permanent.

Throughout our time working together I was always impressed at his willingness to learn, be curious, do deep dives into a problem, and then to bring what he’d learned and share it back to the team around him so we would all benefit.

Contentment

I remember wanting to understand some of Li’s long term career aspirations, and I asked a question I learned from Kim Scott’s book Radical Candor: “At the peak of your career, what sort of work do you want to be doing?”

Most people have a few different answers to this, sometimes its a job title (“director of X”) or a specific role (“I want to be focused in Application Security”) or an ambition outside the industry entirely (“I want to run a small business, maybe a food truck”) or a personal goal (“financial independence, then volunteering”).

It was hard to get a picture from Li of a specific goal he was working towards, and the reason I eventually learned, is that he was content. He really liked the kind of work he did, and found it meaningful. He really liked the people he worked with. “I’m actually really happy in my current role” was something he’d say if I kept asking.

Contentment is rare. Especially in the high-growth software industry. When I think about Li’s good-hearted approach to work and life and his ability to actually enjoy the place he’s at, without longing for more, I think of this quote from the bible:

godliness with contentment is great gain.

Li found contentment, and I admire him for it.

There was a whole lot more about Li I never got to know that well – perhaps because of the manager/employee relationship dynamics, perhaps because we worked from different cities, we didn’t share much of our personal worlds with each other. There was a little bit – I’d hear about an upcoming dance congress he was excited about. Or how a lunch we shared reminded him of Sunday lunches after church with his family when he was growing up. Or about the ups and downs of buying, owning, renting out, and selling an apartment. I had no idea he could speak Spanish. I wish I’d had more time with him, and asked more questions, and shared more of myself too. But even without that, I’m grateful for having crossed paths, worked with, learned and laughed together.

I’ll miss you friend.

Categories
Culture First Engineering

Adapt your facilitation skills for video meetings [remote work inspiration]

Hi 👋 I’m Jason. I’ve been a remote worker since 2016. Full time remote since 2017, and managing a team remotely since 2018. With people across the world suddenly finding both themselves and their teams homebound, I thought it might be a good opportunity to share some of the things I’ve found helpful as a remote team lead. I work at Culture Amp, a software platform that helps organisations take action to develop their people and their culture. We have a collection of “inspirations” – ideas you can copy in your organisation to improve its culture. I’ve followed the basic format here.

Facilitating good meetings requires having a bunch of tools in the toolkit to make sure everyone gets a chance to speak, people are understood, and it is a valuable use of people’s time. The tools you’ll use for video meetings are slightly different, so it’s worth getting familiar with them.

Why?

Video meetings present slightly different challenges: there can be poor connection quality, non-verbal communication is limited, it’s more likely people will attempt to multitask, and less likely you’ll know if they are, and there’s no obvious “clockwise” direction to go around the room when seeking everyone’s input.

Instructions:

Here are some tools to add to your toolkit:

  • Recreate “going around the room” to let everyone have a chance to share. You can do this by having the first person to share choose who goes next. As each person shares, they choose who goes after them. This is a good technique for “stand-ups” and other similar status update meetings.
  • Use hand gestures to signify you would like to speak next. Because of the slight delay on video calls, when multiple people want to speak up it’s hard to not speak over each other. Rather than wait for a gap in conversation and jump in, signify you would like to speak next by raising your hand with one finger up – you’re first in line to speak. If a second person also wants to speak, they can raise their hand with two fingers up. Usually a group learns this system quickly but it’s important the facilitator respects the order.
  • If people have noisy surroundings, ask them to mute unless speaking. If someone on the call is in an open plan office, is working from a cafe, has children nearby or even noisy animals outside, these can all make it harder to hear the person speaking. Encouraging people to mute by default makes it easier for everyone to hear.
  • Encourage everyone to have video turned on. It helps with non-verbal communication, and for someone speaking to see if they are being understood. Exaggerated head nodding, thumbs up, and silent clapping are all great ways to give feedback even while muted, but only work if the video is turned on. Exceptions can be made if the connection quality is poor, or if it is a presentation rather than a meeting.
  • Consider screen sharing a document that serves as both the agenda and the minutes, and editing it live. Adding a visual medium alongside the conversation helps participants keep focused and can give extra context. Taking notes and recording actions in the moment is a great way to ensure people are aligned and there aren’t misunderstandings.
  • Be conscious of how screen-sharing impacts non-verbal communication. Often when you start screen sharing, the other participant’s screen is now dominated by the screen share, and the faces of their colleagues are reduced to thumbnail size. This reduces the bandwidth of non-verbal communication like facial gestures and body language, and can make it easier to have your tone misinterpreted. For sensitive conversations, consider turning screen sharing off.

    If you have a dual monitor setup, some products like Zoom have settings that allow the screen sharing to take up one full screen while still seeing participant faces in full size on the other screen. This is worth setting up if you can!
  • Use “speedy meetings” to allow time for breathing and bathroom breaks. When someone has back-to-back meetings in an office, they usually have breathing space as they move from one room to another or wait for the next group to arrive. When video calls are scheduled back-to-back the calendar can be a cruel task-master. Scheduling you meetings to run for 25 or 50 minutes (rather than 30 or 60) gives everyone a chance to breathe and can drastically reduce the stressfulness of a day. Important: if you schedule a speedy meeting, respect everyone by finishing on time.
  • Make space for “water cooler” talk on the agenda. Make sure the first five minutes or last five minutes of the meeting have space for the people to chat casually and catch up. In an office this often happens on the way to a meeting room, or on the way out, or around an actual water cooler. When it’s a video call, you have to be more deliberate. Make sure the agenda leaves enough space for this, and start a conversation that’s not just about work.
Categories
Culture First Engineering

Video hangouts with no agenda [remote work inspiration]

Hi 👋 I’m Jason. I’ve been a remote worker since 2016. Full time remote since 2017, and managing a team remotely since 2018. With people across the world suddenly finding both themselves and their teams homebound, I thought it might be a good opportunity to share some of the things I’ve found helpful as a remote team lead. I work at Culture Amp, a software platform that helps organisations take action to develop their people and their culture. We have a collection of “inspirations” – ideas you can copy in your organisation to improve its culture. I’ve followed the basic format here.

Basic idea:
Book in recurring video “hangouts” where a group of people have a chance to catch up with no set agenda.

Examples:

  • A team “wind down” each Friday afternoon.
  • A monthly “remote workers lunch”.
  • A fortnightly “engineer hangout” for engineers from across the organisation.

These hangouts should be optional to attend.

Why?

When teams aren’t in the same physical location, a common trap is only talking to people during set meeting times, and to only talk about the current project. Having a time to chat about anything, whether or not it’s work related – like you might in an office lunch room – is a chance to build better relationships and foster a sense of belonging.

Instructions:

  • Pick a group of people who would benefit from a stronger sense of community and belonging. It might be a team, a demographic, or a group with a particular role.
  • Find the appetite for how often people would like to meet, and for how long. In general, a range between once a week and once a month works for most groups, meeting more often the more important the relationships are. Meeting times can vary between 30 minutes and 2 hours, depending on how much of a “drop in / drop out” vibe you want.
  • Schedule a time! Try to find a time that is unlikely to be interrupted by other meetings, and unlikely to be highly focused time. Make sure it is within regular office hours to show that you value this type of connection enough to dedicate company time to it. For some groups it may be appropriate to book over lunch
  • Send an invite! Make sure attendance is optional.
  • During the hangout:
    • As the facilitator, make sure you’re online the entire time.
    • Greet people as they join, and introduce people who might not know each other.
    • It’s okay if people talk about work. It’s okay if people talk about life outside of work. It’s okay if people don’t talk and seem to be doing work on their laptops. 
    • Ensure there is only one conversation going on at a time. If people want to start a splinter-conversation, they can start a separate video call.

Categories
Culture First Engineering

Design systems and team culture

Slide: Design Systems and Team Culture. Jason O'Neil @jasonaoneil

Slide: Design Systems & Team Culture. Jason O'Neil @jasonaoneil

Design Systems and Team Culture

This week at the UX Perth meetup I shared this talk about the human side of building design systems – how your team culture affects the design system you are building, and how the design system can affect the team culture you are building.

Slide: The diagram illustrating the cross-functional team-of-team's structure at Culture Amp - we have many teams, each with their own designers, front end engineers, back end engineers, product managers, testers, etc

At Culture Amp, we operate on a “team of teams” model. We currently have about 200 staff, with about half of those contributing to the product as engineers, designers, product managers, QAs etc. Each product feature has a team responsible for it, and this team is “cross-functional” – so rather than a single infrastructure team, each team should have its own infrastructure specialist. Rather than there being a single design team, each team should have a designer.

The idea is that each team should be able to move to its own priorities without being blocked by other teams. But as you can imagine, this can lead to people being out of sync.

Slide: The diagram illustrating the cross-functional team-of-team's structure at Culture Amp, with the front end engineers from across all teams highlighted.

Designers on different teams might be making simultaneous decisions about the styling of a button, and reach two different conclusions, resulting in two button styles.

In other disciplines, like Front End Engineering, you have people from across different teams working on different products with different code-styles (and even different languages!) How do we make sure that people on different teams can produce work that is consistent, high quality, fast to build and easy to maintain?

Slide: The diagram illustrating the cross-functional team-of-team's structure at Culture Amp, with the Survey Design team highlighted.

And then within a team, how can we make sure designers, engineers, product managers and everyone else is speaking the same language, and making decisions from the same framework?

Can we avoid designers saying things like “Use Ideal Sans, size 12px, line height 18px, all caps, and maybe some tighter letter-spacing?” and instead say “Use the Label style”.

Establishing sensible defaults, and giving names to them, enables your team members to talk to each other with less confusion and ambiguity – and that clear communication helps lead to less mistakes and faster work. It also helps product managers know which styles already exist and can be used, and which ones the team needs to invest in creating from scratch.

Slide: The diagram illustrating the cross-functional team-of-team's structure at Culture Amp, with everyone on every team highlighted.

Across the business, we want to align everyone, so that our product looks and feels consistent, no matter which team built it. And we want to speed up people in all roles on all teams, so that they can spend less effort recreating yet-another-button-component, and focus more on delivering real features that benefit our customers.

This is where design systems really shine: they give a common language that designers, PMs and engineers can use to all be on the same page. They help bring consistency in fonts, colors, styles and components to people on different teams who don’t interact often. And they give us a platform to build common, re-usable designs that can be shared across teams, enabling all the teams to build things faster and with more consistency.

How our company values interplay with our style guide efforts

So building a design system was the right call for us at Culture Amp. But how does that play out with the actual people, each with a specific role on a specific team? How does it affect our approach to work, and more importantly, to team work? How does the design system interplay with our team culture?

At Culture Amp we spend a lot of time talking about our company values, because our aim is to be “Culture First“, to focus on having an amazing work culture, working and living according to a shared set of values, and to let achievement and success arise from that culture.

So we have four values:

  1. Have the courage to be vulnerable
  2. Trust people to make decisions
  3. Learn faster through feedback
  4. Amplify others

How do these values impact our implementation of the design system? And how does our design system feed back into these values? Let’s take a look.

Slide: Value #2 Trust others to make decisions

Trusting people to make decisions can be hard. There is a reason micro-managing is such a problem in so many workplaces. And when it comes to design systems, you often hear companies talk about introducing them precisely because they don’t trust people to make decisions. They don’t trust them to use the logo correctly, they don’t trust them to choose an appropriate header type style – so they codify the “correct” way in the style guide and make sure everyone follows it.

Dictatorial decision making doesn’t leave any space for creativity and innovation. I personally believe the most inventive things happen on the edge of a group – not in the center – and you don’t want to squash that by rigid enforcement of a system that takes away a team member’s ability to make a decision.

But more importantly – if you remove all freedom from your team, limiting the ability of your designers to design, and of your engineers to engineer better components, never allowing them to build anything new and better – they’re going to resent it, they won’t enjoy their jobs, and you won’t see their best work – their talents will be wasted.

So how do we balance the desire for consistency with the desire for freedom? Let’s take a look at some examples.

Slide: a screenshot of the color palette page used at Culture Amp
We ask everyone to trust us and stick to the palette. Meanwhile we trust them to make good decisions with how to use that palette, and don’t try to micro-manage through design reviews.

With our brand colors, we have a predefined palette of 3 primary colors (“Coral”, “Paper” and “Ink”), 6 secondary colors (“Ocean”, “Seedling”, “Wisteria”, “Yuzu”, “Lapis” and “Peach”) as well as a small number of tertiary special use colors. These base colors were decided on by designers from across the organisation coming together – it wasn’t an edict from on-high, it was a collaborative effort to unearth the color patterns already in use, and choose and standardise on those that most identified with our brand.

From those colors, we tint them (add white) and shade them (add black) to come up with nearly 300 variations you can use and still be on brand.

(Read more about that in my post How a design system can encourage accessible, on-brand colors.)

With defining this palette, the designers are asking us to trust them – for any text or button or border on the site, we should be able to use one of these colors.

And trust is a two way street.

In return, they can trust us engineers to make sensible choices within the palette. I know the system suggests we use “Ocean” blue for links, and I can choose the appropriate shade of Ocean depending on accessibility requirements, and make the decision myself, without needing to consult a designer.

We trust them to define a palette, they trust us to use it wisely.

A screenshot of the type styles used at Culture Amp
We ask people to trust us and stick to these type styles wherever possible. We trust them if they say they need to deviate.

We did a similar thing for type styles, defining a range of headers, paragraph styles, labels and more that could cover most of the usages on a page. (Click here to see our type styles).

While I was giving this talk on Tuesday night I had Slack messages coming in from designers and product managers on one team talking to designers and product managers from our team – how much freedom would their team have to do what they needed for the visualisation they were designing – would they be free to explore or would they be limited to only a small palette of avialable styles?

Again, it comes down to trust. Those building the design system need to trust teams to know when and how to use it, and to know when to step outside it and try something new. If you trust that they share the same goal of great design and consistent design, then you can trust them to make the right call about when to experiment outside of the system. The work this team does may well bubble back up into the design system and become a standard for other teams to share.

Slide: Value #1 Have the courage to be vulnerable

One of our other values is “Have the courage to be vulnerable”.

(If you have not watched Brené Brown’s exceptional Ted Talk “The power of vulnerability”, you should do so now).

One way this shows up in building a design system is fighting any tendancy towards perfectionism, which is common for many designers and engineers – we want it to be perfect before we share it with the world. We want it to be just right before other teams start using it.

But sometimes sharing it early, even when you still aren’t proud of it yet, or are maybe even ashamed of how it looks or how it’s built, is still a good thing, and can help someone else, even in the early and rough state.

Slide: a screenshot from our style guide showing a dropdown component demo, but the demo user interface has ugly buttons, select boxes, and weird font weights.
We have a really great mock-up for our design system website with a very pretty way to demo components. But we have to be okay with sharing the ugly version so people can start using it now.

This showed up with launching our design system website, www.cultureamp.design. Parts of it look nice, but no where near as nice as the mock ups. There are designs so beautiful and so on-brand that we really wanted to share them with the world. But perfect can be the enemy of good, and at the end of the day, we had to share this with out team rather than keep it a private secret. We got over our insecurity, and started sharing it, and people have found it useful, even if there’s so much we wish we could improve.

A screenshot of our changelog including many small changes, some of them breaking changes
Moving fast and not waiting for perfection means making mistakes, like me needing to make a breaking API change because of a spelling mistake.

This has applied to the components we build as well as the website we use to showcase them. In the interest of moving faster and being less precious, I got excited and shipped a new dropdown component, including the ability to add a “seperator” to the menu. Not a “separator”. Yes I shipped a version of our design system with a spelling mistake, and fixing that was a breaking change, immortalised forever as a version bump in our CHANGELOG.

Putting yourself out there isn’t only about sharing your work early. It’s also about opening up the possibility for them to criticise the work you’ve done. Sometimes asking for feedback gives you feedback you didn’t want to hear.

We did this when our team, who are the main drivers of the design system, asked designers and front-end engineers from across the company for feedback on how we’re going.

Slide: a bubble-chart visualisation showing the number of positive and negative comments about some topics related to our team
A visualization of the comments we received when we asked for feedback on how our team was going

Often we talk about user experience and user centered design, but with design systems, we have two classes of users: the end users of our product, and our colleagues who use the design system to build the product. Taking the time to listen to this second group, our colleagues and team-mates, is crucial.

And it ties into one of our other company values: Learn faster through feedback.

Slide: Value #3 Learn faster through feedback

One key thing we learned through this survey was that we’d been over-investing in the base level styles (typography, color, icons) and underinvesting in the mid-level components (for example drop down menus, tabs, and select boxes).

Slide: Styles (atoms), Components (Molecules) Patterns (Organisms). Components is in bold.
We spent all our time on Styles, but the feedback showed we would be more helpful if we built more ready-to-use components.

Our team had been focusing on bringing consistency at the low level – changing typefaces and background colors and icons across the app, which was an enormous amount of effort on our part. But what would have helped the other teams more is if we built components that helped them deliver their designs faster. It might mean it would take longer to bring consistency to some of these fundamental styles, but it would mean that these teams are delivering valuable features to customers sooner.

That message came through our survey, loud and clear.

And at the end of the day, that ties into our fourth value:

Slide: Value #4 Amplify Others

Amplifying others. That’s the reason we’re building a design system in the first place – it allows us to amplify each of the product teams in our company, allowing them to move faster, stay in sync, spend less time sweating the fine details – and deliver a higher quality and more consistent experience to our customers.

That’s what it’s all about – and if we keep this in mind while we build out our system, it can help keep the work grounded, practical, and more likely to make an impact.

It isn’t about having the prettiest showcase of components. It isn’t about the elegance of your solutions, or the way you ship new components to your teams. At the end of the day, it’s about the people in your teams, and how you can amplify them, so they can build better products, faster, and with less stress.

And if amplifying your workmates does not motivate you, then you might have bigger team culture issues that a design system is not going to fix!

Have any questions? Feedback? Other observations on how team culture and design systems interplay? I’d love to hear them!