Before we get into it properly, let me say upfront: this advice isn’t just for leaders. It’s not about finding the “perfect” group of people or rolling out shiny new policies (though, yeah, there’s a bit of that later). This is really about creating a culture of trust, support, friendliness, and actual human empathy.

Yes, leadership can and should drive this stuff, but literally anyone can start fostering a great culture.

Quick bit of background so you know I’m not just making this up after reading two Medium posts: I’ve been a developer since 1998, contracting since 2013. I’ve been on more teams than I care to count and I’ve done the rounds from fresh-faced junior to department head. I didn’t really figure out that I could influence team culture until my mid 30s, but once I did, I started applying these ideas everywhere. It works. I've had a near perfect success rate so far.

One small word of warning though: If you’re in a toxic workplace: be careful. Some of this stuff involves vulnerability and may backfire in certain cultures. Weigh it up sensibly - you know your environment better than I do.

Step 1: Don’t take life too seriously - you’ll never get out alive

Corporations love formality and small companies love pretending they are corporations. Everyone’s terrified of looking “unprofessional.” But no one wants to work with a LinkedIn post in human form, they want to work with real people and people are kooky and unique. A truly great team should be a team of people, not corporate drones - at least not until AI has truly taken over.

When I join a new team, I’ll usually set my display name in the team chat app to “Foxy” (my nickname) if I can get away with it, and I pick a profile picture that - which definitely blurs the line between ‘professional headshot’ and ‘this was taken after too many beers’ but really reflects the sort of person I enjoy being. It’s also my LinkedIn photo - for better or for worse. I’m a bit thinner and a LOT greyer than this 10 year old photo makes me out to be now though so maybe it’s time for an update - if you know me personally, I'll let you be the judge 😀.

I make a point to chat in Slack/Teams about more than just work and I like to throw jokey and playful responses to other peoples posts from time-to-time too.

Now, let’s be realistic here: you do have to read the room. Don’t just flood the channel with GIFs if everyone else is still doing “good morning” every day and only posting stilted work updates. Wait it out. Ease in. Find your allies. You’ll usually spot them quickly enough.

On that note, I also tend not to join in with the “Good morning” messages, this isn’t because I don’t care enough to wish other people a good morning, it’s because I see these messages as a sneaky way for a company to implement a time card system and I don’t agree that clocking in and clocking out is a good way to measure somebody’s value in a team.

Also, when I say “talk about more than just work” I don’t mean that I start waffling on about my cat or how cool [insert latest hyper-fixation here] is, I mean that I occasionally might drop a comment about something interesting that happened on the news or make a funny (In my opinion) joke about something that’s going on in the world - remember that humour is subjective but provided you keep it clean and don’t make jokes at the expense of others (unless you have that sort of banter-in-public relationship already) then you’re probably fine although if you’re consistently not getting a positive reaction, you may have to accept the fact that you’re not as funny as you hope you are.

© Copyright Touchstone pictures

The point here isn’t to “make work fun” (that is just hopefully a side-effect). It’s to help people loosen the corporate choke collar a bit and start showing up as themselves.

Step 2: Pobody’s Nerfect

© Copyright NBC

There’s this weird developer culture where everyone pretends they’re infallible, and at the same time loves to jump on other people’s mistakes like it’s some kind of blood sport, I’ve seen it countless times and I believe that this behaviour is absolutely vile and hugely disingenuous.

We’re all capable of making mistakes, even the best developers I know have blind-spots and even if you do generally do everything right, we all have our off-days. There is no such thing as a perfect record.

The trouble is that this attitude destroys teams, it makes people stay quiet when they have suggestions as they fear being shot down, it makes people scared of (or even hostile to) feedback and above all else, it’s hugely demotivating. Nobody wants to feel ‘less than’ their co-workers and yet SO MANY of us do, impostor syndrome is practically a pandemic in our industry.

The sad thing is that it’s actually not a complicated issue to fix, all a team has to do is own their weaknesses and accept them in others.

Accepting others’ weaknesses

This part’s not that hard. Give constructive feedback, not snarky jabs. Watch your tone - written feedback is a minefield for accidentally coming off as passive-aggressive.

When someone admits a mistake, support them. Say “yeah, easy to overlook” or “we’ve all been there.” Then help fix it, don’t just throw it back at them, a being on a team means being collaborative, not combative.

Google’s Site Reliability Engineering teams famously do “blameless post-mortems” - the focus is on what broke and how to fix it, not who to shame. That’s a solid model to aim for.

Owning your own weaknesses

This is the scary bit. You’ve got to be willing to say “Yep, that was me. My bad.”

One example: I once built a search component that broke in a pre-release build. I said that it was probably a weird data mismatch (our test and prod data were about wildly out of sync) but that I could not rule out a programatic issue. Indeed a few weeks later a teammate investigated the issue and correctly diagnosed that it was actually a race condition. This was flagged during a stand-up and someone else on the team questioned it as they believed my original assessment will have been accurate, however as soon as ‘race conditions’ were mentioned, I put my hand up and said “Actually, it’s entirely likely that it’s a race-condition, they can be a bit of a blind spot for me at times”.

Now, if I hadn’t already shown my strengths, that could have backfired. You want to have enough credibility banked before you start flagging your own weaknesses, otherwise people might just see you as the “mistake dev.” Thankfully the entire project had been single-handedly built by me in the weeks prior to the new developers starting, so a few bugs in an otherwise well architected and very well-liked codebase was not enough to tank my solid reputation.

If you’re junior? Absolutely own your weaknesses. That’s how you grow. If you’re senior? You still need to own them - but make sure people have already seen your strengths. The important thing to remember is that if you’re not being challenged about anything, you’re not growing. There’s also a good chance that that lack of challenge isn’t because you are perfect, it’s because people don’t feel like they are allowed to challenge you. That’s not a good thing.

I often tell colleagues that they will never offend me by highlighting something I was wrong about or missed and then usually throw out the famously mis-attributed quote “If you're the smartest person in the room, you're in the wrong room.” Mainly so I sound magnanimous and wise.

Beware the 'super chickens!'

Don't worry, I've not gone insane (citation needed). A super-chicken is a phrase coined by Margaret Heffernam and describes people who rise so far above their team in terms of skill that the actually make other developers feel inferior and struggle to 'compete' with the super-chickens.

© Copyright Fox

She's not advocating not being brilliant, she's simply saying that if you turn your team into a team of people who are all competing with each other to be 'the best', you'll end up with a dysfunctional team who will struggle to work well together. Whereas if you foster an environment of collaboration and connection where everyone lifts each other up rather than just putting the best developer on a pedestal and letting them talk down to the others, you'll create a team that really has a lot of value.

You can watch her excellent TED Talk about this here:

https://www.youtube.com/watch?v=Vyn_xLrtZaY

Step 3: Praise in public, critique in private

We’re wired as a society to focus on the negative. People will happily spend an hour picking apart a mistake but won’t spend ten seconds saying “Nice work.”

Flip that. When someone does a great job - maybe they wrote a really useful helper function, unblocked you fast, or just did solid, dependable work - call it out in public. Use retros, standups, Slack shout-outs. Make them feel appreciated.

I’ve had so many teammates with raging imposter syndrome who genuinely believed they were about to get fired every day. A bit of public praise is sometimes enough to stop them spiralling for at least a week.

When it comes to critique? Do it one-on-one. Always. Unless someone is actively burning the office down, there’s no reason to shame them publicly. If you absolutely must call something out publicly (like if it’s harming the team or the product immediately), be respectful and precise. But seriously, keep it rare.

Step 4: Always try to be nice, but never fail to be kind

© Copyright BBC

Right, you got me, that’s a quote from Doctor Who but it’s also probably the best advice I’ve ever heard in my life. (I’m seriously contemplating getting it tattooed on my body!)

“Nice” isn’t always possible; sometimes you have to do something to someone that isn’t a wonderful thing to do (e.g. give negative feedback, fire someone, make them do backlog grooming etc…) but just because you can’t be nice, doesn’t mean you can’t be kind.

Always try to add empathy to the mix, how would you want to be given the news/task that you were about to give to someone else, frame it in a positive way (without crossing the line into being disingenuous) and make it clear that this is something you take no pleasure in doing.

Step 5: Bring order to the chaos

Right, the unsexy part. Standardisation.

© Copyright BBC

I have ADHD and Autism, and if the rules in which I operate are ambiguous, I can feel deeply uncomfortable. It’s actually one of the reasons I find myself more drawn to leadership roles; I get the autonomy to close those ambiguity gaps so that others don’t have to feel that same discomfort.

It’s not just a neurodivergent thing though. If you don’t have clear guidelines and standards to follow, you can’t have an ordered team. Everyone ends up working slightly differently, second-guessing what “done” even means, and generally spending way too much mental energy on nonsense that shouldn’t even be a question.

Here’s a small example:

I was recently part of an entirely remote team that had a daily standup over Microsoft Teams. Every day, the UX designer would open the Jira board and we’d all take turns giving our updates.

Now, this team was distributed worldwide. Combine slight language and cultural barriers with the audio lag you get from a many-thousand-mile distance - plus the fact that at least half the team were a bit shy - and you ended up with these long, awkward silences. Everyone was basically playing a daily game of chicken, waiting for someone to say “Ok, I’ll go next.”

When I first joined, I tried to avoid being part of the problem by jumping in quickly to fill the gaps with my update. But obviously, I can only do that once per standup, so it didn’t actually fix the core issue.

After a few weeks of doing step 1 (building rapport, finding my footing), I felt confident enough to speak up and say: “The Jira board has all of our names in a row at the top of the page, and that order never changes. Why don’t we just always give our updates in that order?”

This was accepted immediately. I could actually see the relief on some faces. Every standup since then has been smoother, with hardly any dead air. As a nice side-effect, they also became way more efficient - we rarely went past the allotted time after that, whereas before it was a regular occurrence.

And it’s not just meetings or standups that benefit from this sense of order… it absolutely extends to the tooling around writing code. Remember, developer experience is just as important as user experience. Developers are also users of your application in a weirdly meta, behind-the-scenes way; they just happen to see all the guts as well as the shiny bits.

In codebases, I push for:

• Prettier
• ESLint
• Husky
• Storybook
• TypeScript

I would actually really hope that most (if not all) of these tools were already installed - but you’d be surprised how often they’re not. Setting up the linting and formatting tools (the top three) is usually an easier sell than Storybook and TypeScript, but eventually I almost always get my way. And you know what? The team is always happier about it in the long run.

I also make it a point to set up Pull Request and Issue templates wherever possible. In fact, I’ve got a whole article about PRs in the pipeline, which I’ll link to once it’s done. For now though, here's a link to a gist where I keep my PR template. Feel free to use it yourself.

I’m not going to dictate specific rules to add to these tools here - that’s not really the point of this article, and honestly, those rules should come out of proper team discussions anyway. If the majority of the team disagrees with your implementation, they’re either not going to follow it or they’re going to resent it (or both).

The actual rules aren’t the point - having some rules is. Simply putting structure in place gives everyone a shared sense of order. PR templates, for example, transform that terrifying blank box into a friendly little checklist, which almost always results in higher-quality submissions.

Basically, anything that removes cognitive load and reduces friction is going to make your team happier and more productive. It really is that simple.

Architecture Decision Records (ADRs) are a biggie too. Keep them in your repo. Not in Confluence. Confluence is where documentation goes to die.

ADRs don’t have to capture every micro-decision. Just the big stuff: frameworks, major abstractions, big third-party libraries, database choices. Michael Nygard wrote the definitive piece on this, so I won’t go into any more detail here, I highly recommend you check it out: Documenting Architecture Decisions.

Step 6: Profit!

All of this stuff is a lot easier to do if you’re in charge of the team and/or you can get buy-in from those in charge (and the team itself). But you should still be able to implement at least a few parts of this advice at any level. At the very least, some of it is just an internal attitude shift you can adopt - it’ll make you a better colleague, and hopefully others will want to follow your example.

You’ll know you’ve been successful when you start seeing people doing things like owning mistakes, praising colleagues, having a bit of fun on Slack, pointing out ways the team or product can be improved, engaging more in retrospectives and standups, and generally just…

BEING MORE PRODUCTIVE!

Aye, now the stakeholders reading this article are paying attention. I purposefully left this part until the very end because this should not be about making money. If you’ve read this far, I’d like to think you’re here because you actually care about your co-workers and want them to be happier in their daily lives - if that’s true, brilliant!

However… even if it’s not true and you’re only here thinking, “What’s in it for me?” then a) shame on you, and b) I’ve got good news! Happier workers who have a solid structure, feel appreciated, and are challenged in ways that help them grow (rather than shrink) are naturally a LOT more productive.

There are countless studies (see the end of the article for the list) showing that happy workers are more productive workers. Hell, most modern working practices exist because we eventually realised during the Industrial Age that having a miserable, exhausted workforce was maybe not the best idea if you wanted to actually get stuff done.

If you follow all the advice in this list, your team will become more confident, more motivated, and they’ll feel genuinely invested in what they’re building. ALL of that will improve your bottom line - as well as just being a much kinder, more human way to live and work.

A great dev team isn’t just the fastest or the one with the fewest bugs. It’s the one people remember as “the best team I ever worked on.” Where they felt safe, respected, challenged (in a good way), and maybe even had a laugh or two.

Those teams don’t just enjoy work more, they collaborate more, are more passionate and are more productive. It’s the ultimate win:win.

So what are you waiting for? Go build it!

• https://rework.withgoogle.com/en/guides/understanding-team-effectiveness#introduction
• https://www.gallup.com/workplace/236927/employee-engagement-drives-growth.aspx
• https://www.ox.ac.uk/news/2019-10-24-happy-workers-are-13-more-productive