Context is Queen

Want to improve your workplace communication skills, especially when working with other teams?

Give context.

Why give context?

Context helps your colleagues:

  1. Understand where you’re coming from / viewing things from.
  2. Understand who you are, and what you’re trying to achieve (your overall project, not this specific request)
  3. Helps remove assumptions. Teams often have their own dialects, and your request may mean something entirely different to them. Giving context helps them understand if there might be other dialects in play.
  4. Saves them time in “back and forth” clarifying questions, which, if the teams are remote, can take days.

Context helps you too:

  1. It saves you time in the long run – you’ll reduce the amount of “back and forth” while the receiving party tries to figure out exactly what you need.
  2. You might not actually need the thing, or need to do the thing. The team you’re asking may already have done something that can help you. But if you just ask for “$thing” you’ll never know, because they don’t know your project/goal!

A worked example

Here’s an example I used on Twitter recently:

Bad: “I need $thing”

Good: “I’m from $group. I’m trying to help $team with $companyGoal, to do $workItem, and need help with $thing”

This difference this makes can be stark, and it usually only takes a few minutes more:


I need a new SSL certificate


I’m from the web applications team. Our SSL certificate will run out soon (we’re trying to automate renewals but we’re not there yet), and I need the new cert to prevent our web app from going offline next week. Can you help please?

If I received the first request. I give them the cert.

If I receive the second request, I can tell them all about the solution our team developed to help developers with certificate management and auto renewals!


So please, do yourself, and your colleagues a favour – give context! 🙂

It’s not what you say, it’s how you say it.

Something came up today that made me think about the importance of framing, and how it can be used to influence/persuade to meet your desired outcomes.

It’s not what you say, it’s how you say it.

It’s very easy to forget this – I do it all the time – but delivery is important. It can mean the difference between your idea being thrown out, or openly embraced. Sometimes, it’s the difference between burning bridges and maintaining relationships and partnerships.

Take this as an example:

You’ve been approached by a company to come and work for them. This company happens to be a very close partner with your current company. You want the new job, but you don’t want to jeopardise the partnership the companies have, or the relationship.

You might start your email off like this:

$partnerCompany has approached me to work for them, and I’d really like to persue this.

It gets the message across, and it is factually correct. That’s what happened.

But that might not be as well received as:

I’ve been dealing a lot with $partnerCompany recently as part of $project and an opportunity has come up that I’d really like to persue

There’s some, subtle, deliberate differences here:

  1. The first example is framed in a way that suggests that $partnerCompany has poached you.
  2. The second example is framed in a way that suggests that from working closely with them, an opportunity has come up, and it’s your decision to leave.

Why do these subtleties matter? Because you don’t want the partner companies to end up falling out. In both examples, you’re still announcing your intention to leave, but the second example may be less damaging to the partner relationship and thus, achieves your goal of getting the new job, and not damaging the partnership. Winner.

Ways to make your team better by making them feel safe

I’ll get right to the point: Teams work better when they feel safe. And this one-page PDF from the Re:work team at Google gives clear and actionable things you can do and think about that will help to make your team feel safe. It doesn’t matter if you’re a manager or a team-member; check them out.

Now, on to the waffle.

I’m fascinated by team dynamics – what makes them work (or not work), what makes a team excel, and ways in which I can improve, or actions I can take, to get the most out of myself and my colleagues. People are social animals – and I feel that’s often forgotten about in a business setting.

Recently, I stumbled upon Re:work, from Google. The site itself is a veritible trove of information for anyone wanting to improve themselves and their teams, but one of the most important things for me when it comes to fostering teamwork is to ensure that your team feels safe. that might sound “cute”, but if your team don’t feel safe, bad things happen, because thanks to biology, they don’t cooperate as well.

So I was super-chuffed when I found the Re:work site – and more so when I discovered this Actions for Psychological Safety PDF which gives clear and actionable things you can do (as a leader or as a team member) to help your team feel psychologically safe. I think it’s well worth checking out. I can already spot a number of things I could do more of.

I’d love to know what you do to help make your teams feel safe. Let me know in the comments 🙂

Read the source page: Fostering Psychological Safety

Understanding the human animal: The importance of packs, feeling safe, and good leadership

I love understanding human nature, and why I feel the way I do in certain situations.

One of my favourite videos on this, which touches on human teams, the important of feeling safe, and leadership responsibility, is Simon Sinek’s “Why leaders eat last” talk. At 45 minutes, it’s a good lunchtime video.

For those who prefer to read, I’ll try to summarise the themes and my main takeaways, including what we can all do to make each other feel safe and valued.

How do you know if IT is meeting your company’s needs?

As part of a series of posts on moving IT from Reactive to Proactive, I share my thoughts on how to ensure that IT is meeting your company’s needs through regular meetings with group managers.

How do you know if IT is meeting your company’s needs?

The short answer is, unless you are talking to your non-IT colleagues and managers regularly, you probably have no idea.

Why do I say this?

  • For many departments, IT is so invisible that it doesn’t even cross their mind when a new project is kicked off.
  • Often non-IT staff feel that their problems either can’t be, or won’t be solved by the IT department.
  • Sometimes there’s also a feeling that the problem is “only a niggle” and that they don’t want to tie up IT with it.

You need to get your colleagues out of this mindset, and get IT involved into the fabric of the company.

It is your job to make sure that IT is meeting your company’s needs. IT is an asset to your company, make sure your colleagues know it. Go out there, mingle and build rapport. I cannot stress this enough. The benefits are often intangible, but in my experience are absolutely essential to making sure IT don’t get blindsided by urgent IT issues in non-IT projects.

If you’re not making sure that IT meets your company’s needs, your non-IT colleagues may start to explore IT’s version of hell: “Shadow IT services“.

Meet regularly

So how do you stop this? How do you make sure you’re meeting your company’s needs?

My advice, no matter how big or small your company is, is to meet regularly with the department leads/managers and discuss:

  • Ongoing IT issues and progress (client to IT)
  • New projects/initiatives/issues (client to IT)
  • Updates from IT (IT to client)

The idea here is to create a flow of information in both directions. Build a relationship. Build a rapport.

Reaping the benefits

A lot of the benefits of meeting regularly as intangible, but very worthwhile in my opinion.

Meeting regularly:

  • Ensures IT  gain greater visibility of the company’s overall goals, as well as individual group goals.
    • The more you know, the more you can help, and the more IT becomes an asset and seen as an enabler.
  • Helps to keep IT visible, in the forefront of the group managers’ minds
    • Rather than IT being invisible
  • Provides a conduit for information and issues.
    • Helps IT to catch and fix issues before they become a problem for your company.

In case you’re curious how you go about this, here’s how I tend to do it:

Finding whom to speak with

Generally, you need to be meeting with a decision maker and the head of the department or group. If your company is large, you may want to strategically pick a group leader rather than a department leader as the group leader is closer “to the ground” so to speak and may have a better idea of what IT issues their staff are seeing daily. Often a company will have a project or programme manager. Meet with them too. Project-wise, no one knows more about what’s going on than a project manager.

Don’t kill yourself with meetings, though. If you have identified a lot of group managers, either pick the groups that you feel you’ll have the most impact on, or divide up the meetings with other IT colleagues.

Initial meeting

Book your initial meeting 2 weeks in advance. As part of the booking, ask the manager you’re meeting with to speak with their colleagues/reports to gather feedback on IT. 2 weeks gives them enough time to gather that feedback. Book it for 1-hour, but let the manager know that future meetings will only be 30 minutes. (These are busy people, and they’ll appreciate the brevity of the meetings)

The initial meeting is mostly a lot of information gathering, so tends to take an hour. If you’ve never spoken before, you have a lot of catching up to do. You should:

  • Ask what their department is responsible for
    • Knowing what a group does, and their priorities, is important if you’re going to be supporting them
  • Let them know why you’re having these meetings. Sell the benefits to them.
    • Let the manager know that IT is here to help.
    • You want to fix things.
    • You want to help the company succeed.

After your first meeting, you’ll probably have a lot of action points or things to chase up. Don’t let this drag you down; it’s just a consequence of having not met very often. It won’t be like this every meeting 🙂

Regular Meetings

Regular meetings should be monthly, and roughly 30 minutes in length. Book the first one a month after your initial meeting. In the meeting you should provide feedback on any issues that were raised in your previous meeting, and see if anything new is upcoming. It’s also a good idea to check both sides are happy with the style, format and length of the meeting.

I tend to dub these meetings “<Department> Catch-up”, as that’s all you’re doing. If any projects or key issues spring up out of these meetings, you should be working on those issues outside of the catch up.

My regular meeting formats look like:

  • IT progress update on previous issues
  • Client update on current/new projects
  • Any new issues?

Some notes on my experiences with this approach

I have used this approach at my previous company and my current company for the last 3 years. Over that time, I’ve learned a few things:

You’re being tested

Neither side is probably aware of this but, after the first meeting, you are being tested. If you walk out of that initial meeting with a list of stuff that’s wrong with IT from a group’s perspective, and you can’t come back with any plans, feedback, or answers to some of those issues, you’re going to have a hard time going forward. If you fail to act, the group managers will feed that back, and their colleagues and reports will see IT exactly the same as they did before: a blocker. You have a month to get answers or solutions; make that time count 🙂

Set expectations

IT is under-resourced in many companies. Don’t promise the world to the people you’re meeting with, but do let them know you’ll do everything you can given your resources. Generally, they’ll understand.

Use the catch-up to sell IT

If you work in IT, you know you do great stuff every day. Use the regular meetings to demonstrate to the group managers that IT are making a difference. Make your IT updates relevant to the group you’re meeting with. If you’re meeting with Finance, they probably don’t care that you’ve upgraded the Git servers for the Software team, but they probably do care that you’ve improved the performance of their accounts reporting tools.


Let me know what you think about this article. Does it make sense? Do you agree or disagree with my approach? Feedback is gratefully received, especially if it’s constructive! 🙂