Q and A with Neil Millard - 26 March 2025 - Collaboration

Session summary: a live Q&A on why collaboration is foundational to both DevOps and open-source success — tech is built by more than one person, and the practices (code review, shared documentation, breaking down silos between roles) that make open-source projects work are the same ones that make an internal engineering team effective.

Good afternoon — it's Wednesday, it's lunchtime, which means only one thing: I'm here doing the Wednesday Q&A, for all your tech questions, consultancy questions, contractor questions, and anything else you want to go off topic on. Let's dig in. Today we're going to start by talking about collaboration — because tech is built by more than one person. Even the mighty Linus Torvalds, when he wrote Linux, it was a collaborative effort — even though it's got his name on it, everyone needs a leader to get behind, and it's still a collaborative effort.

Why it matters

Tech is a team game — there's usually more than one person in a tech team, and the best products come from sharing different ideologies and viewpoints. By collaborating effectively, we bring those ideas together. Companies like Google and Spotify foster collaboration and succeed because of it — studies have shown companies with strong collaboration are five times more likely to be high performing.

Barriers to effective collaboration

• Silos — teams, or individuals, working in isolation cause problems.
• Lack of communication — if you're scared to, or can't, talk to somebody about something, you end up making assumptions ("maybe that person just doesn't like me").
• Competing priorities — if you're not talking to each other and you've been given different goals, not everyone ends up pulling in the same direction.
• Tool overload — lots of tools, or worse, a choice of tools that do the same thing, creates confusion.
• Remote and hybrid challenges — a lot of us work remotely, so we need intentional collaboration just to see what each other are doing, saying, or thinking.

How to foster better collaboration

We need to adopt a shared mindset — shift from "my work, my output" to "our work, our success." Cross-functional alignment means we can check in with other teams — in some of the most successful projects I've worked on, we had a small scrum team of six or eight, but we were part of a larger team of maybe 50 people, and we regularly caught up with what the other teams were doing, so we didn't break each other's stuff and could see where we were collectively heading.

Leveraging the right tools helps too — collaboration tools have existed for a while: Slack for chatting, Miro for presenting, Notion for knowledge storage, and by sharing these, teams can collaborate more easily.

We need to create a safe space — encourage open, judgment-free discussion. We all started somewhere, we don't know everything — you might ask me a question and I'll say "I don't know, but I'll find out and come back to you," and you need the strength and safety to say that too. That inspires more conversation, because you've obviously got a gap there, and that's fine — talking to people closes that gap a lot faster than searching online. It's part of why ChatGPT does a good job for a lot of people — it does the searching for you — though the trouble is, if it doesn't find an answer, it just makes something up, which is really bad. You want somebody, human or otherwise, to say "I don't know" if they don't know.

And build a feedback-driven culture. On the most successful projects I've been on, when something goes right, we run a retro and ask what was good, what was bad, and what was so atrociously rubbish we should never do it again. When something goes badly, we ask the same kind of questions — why did it go badly, what were the contributing factors, what could we have done better, and what did we do well despite it not working. Regular retrospectives like that help us grow faster.

Where collaboration matters in DevOps

My specialist subject is DevOps — development and operations — and collaboration is key across several areas:

• Agile development — sprint planning, daily standups, and retrospectives.
• Incident management — when something goes wrong, development, operations, and security all work together to resolve it as quickly as possible.
• Scaling infrastructure — making sure we're building resilient, cloud-based systems together.
• Feature rollouts and testing — QA needs to collaborate with developers, both so developers know how to make things easy to test, and so QA feedback gets back to developers quickly. Pairing with QA while you write code, getting instant feedback, lets you move really fast.
• Customer-centric development — talking to customers, or to support and sales teams who talk to customers, and to the analytics teams, so that feedback actually reaches you.

DevOps itself exists to bridge the gap between development and operations, remove silos, and support collaboration — it promotes shared responsibility, "you build it, you run it." It also brought us CI/CD pipelines, automating faster and safer releases, with a self-service framework for creating, testing, building, and deploying. And monitoring and observability give real-time insight to foresee and prevent system failures, so you can act proactively.

Summary of fixes for common problems

• Lack of shared goals — align objectives across teams with regular meetings; quarterly is probably the bare minimum, more often is better.
• Poor communication — structured meetings, clear documentation people will actually read because it's easy to understand, and asynchronous updates that don't constantly interrupt people.
• Tool overload — reduce the number of tools available; have a group discussion and let a leader decide on the definitive tool list, which makes future decisions simpler.
• Resistance to change — foster a culture of continuous learning and improvement, and reward people who improve and want to learn.
• Remote team disconnect — schedule something low-stakes, like a virtual coffee chat or 30 minutes a day where a demo might happen ("look what I've done, tell me if it could be better") — or team-building activities, in person if you can, that aren't directly work related. Getting to know each other outside of work builds familiarity and friendship, which aids collaboration.

Key takeaways

Tech moves fast, so the only way to keep up is by working together — you cannot know everything, you need to rely on colleagues for coverage. Great products come from teams that collaborate well, and they deliver quicker. Ask yourself: how can we collaborate better, what silos can I see, and how can we break them down? At the weekend I went to Product Camp, a group of product managers who get together to discuss how to be better and share knowledge — in that spirit, how can we share, learn, and innovate together?

If you've got any private questions, DM me — LinkedIn's probably easiest, or comment on YouTube. Otherwise, let's get to your questions for today.