Measuring Psychological Safety in your Team

measuring psychological safety

We know psychological safety is crucial for high performance teams, and particularly so for technical delivery teams. Innovation is so critical for creating products that delight customers and serve critical business needs, and psychological safety is a fundamental enabler of innovation.

Below are ten questions that you can ask yourself or your teams to determine the level of psychological safety in your team. Rate agreement with the below statements on a scale of 1 – 5. 5 being “completely agree” and 1 being “completely disagree”.

When carrying this exercise out with your team, perform the survey anonymously – if it’s possible that your team are psychologically unsafe, they will be more likely to be honest if the survey is anonymous. If the team are very psychologically safe, then it won’t matter if the survey is anonymous or not.

It is also important to allow for qualitative, verbose feedback for each question as well, because that verbose feedback will facilitate and clarify some of the actions that you may need to take in order to improve these scores.

  1. On this team, I understand what is expected of me.
  2. We value outcomes more than outputs or inputs, and nobody needs to “look busy”.
  3. If I make a mistake on this team, it is never held against me.
  4. When something goes wrong, we work as a team to find the systemic cause.
  5. All members of this team feel able to bring up problems and tough issues.
  6. Members of this team never reject others for being different and nobody is left out.
  7. It is safe for me to take a risk on this team.
  8. It is easy for me to ask other members of this team for help.
  9. Nobody on this team would deliberately act in a way that undermines my efforts.
  10. Working with members of this team, my unique skills and talents are valued and utilised.

To explain the context behind each question:

1 – On this team, I understand what is expected of me.

It is essential that team members understand what is expected of them in terms of delivery (speed, quality, cost, and other factors) and behaviour (everything from dress code and punctuality to coding standards) to foster psychological safety. Ensure tasks are clear and well defined, behaviour expectations are explicit, and negative behaviours are dealt with.

2 – We value outcomes more than outputs or inputs, and nobody needs to “look busy”.

Outcomes (such as revenue generated or satisfied customers) matter more than outputs (emails sent, lines of code written, or meetings attended). If the team focus on what truly matters to the business, they are safe to make decisions that can improve outcomes, even if those decisions reduce output. The ideal is a team that possesses enough psychological safety to decide not to do something that could make them look good in the eyes of others, but doesn’t deliver outcomes for the business.

3 – If I make a mistake on this team, it is never held against me.

A psychologically safe team will never blame a member of the team for a genuine mistake if their intentions were good. Indeed, by enabling mistakes to be made without a fear of blame, you enable innovation and risk taking that can drive your organisation ahead of the competition. Utilise systems thinking and DevOps approaches to prevent mistakes before they happen or mitigate the impact of mistakes when they do.

4 – When something goes wrong, we work as a team to find the systemic cause.

Related to the previous point but important enough to warrant its own question, a system of discovering the root causes of mistakes and failures means that not only do team members feel able to take risks without being blamed, but every single “failure” is an opportunity for learning and improvement. By building psychological safety through these retrospective exercises, everyone on the team gets to learn from mistakes, meaning mistakes are a gift, not a threat.

5 – All members of this team feel able to bring up problems and tough issues.

In a psychologically safe team, all members of the team are able to bring up problems and tough issues, ranging from personal struggles to concerns about other (even senior) members of the team. This psychological safety is crucial for allowing both vulnerability to show when you’re struggling and need help, and courage to raise difficult topics.

6 – Members of this team never reject others for being different and nobody is left out.

Evidence shows that diversity in a team results in higher quality products and happier team members, but diversity in itself is not enough: it is crucial that team members are all included in decision making and delivering results. To facilitate psychological safety (and high performance) every member of the team needs to be invested in the decisions made and the outcomes generated. This is particularly crucial for remote and distributed teams, where it is more difficult to see if a team member is becoming disengaged.

7 – It is safe for me to take a risk on this team.

Mistakes happen unintentionally, but risks are about taking actions that might not work, or may have unintended consequences. Psychological safety provides the framework for positive risk-taking, enabling innovation and ultimately, competitive advantage.

8 – It is easy for me to ask other members of this team for help.

In psychologically unsafe teams, team members try to hide their perceived weaknesses or vulnerabilities, which prevents them from asking for help. In a psychologically safe team, members prioritise the team goals over individual goals. Helping others helps achieve the team goal, and because team members feel safe to ask for that help, psychologically safe teams achieve more of their goals than unsafe teams.

9 – Nobody on this team would deliberately act in a way that undermines my efforts. 

In an unsafe team, members compete with each other to achieve their individual goals, and may even undermine other team members if it could benefit them or it is perceived that doing so may elevate their “rank” within the team or organisation. In a psychologically safe team, that counter-productive competition doesn’t exist, and the success of the team is more important looking good in the eyes of others.

10 – Working with members of this team, my unique skills and talents are valued and utilised.

We all bring our own unique experience, skills and knowledge to the teams that we’re in, but we also bring our own prejudices and biases. In a psychologically safe team where members are valued for being their true selves, biases are less likely to manifest. Indeed, team members may feel safe enough to identify, raise, and discuss their own biases or those of other team members. By doing so, we provide space for each individual to maximise their potential from utilising their own unique skills and talents.

Regularly Measuring Psychological Safety

By measuring the degree of psychological safety on your team, you can begin to build your own unique strategy for developing and maintaining it. For instance, this may involve running more regular retrospectives or by workshopping the team’s values and behaviours.

Measurement is only a tiny part of the process. Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

Remember to be patient: this is a journey, not a destination, and work on your own psychological safety too. You can’t effectively help others if you don’t look after yourself.

Take this survey for yourself.

Psychological Safety in Distributed and Remote Teams

In early 2020, due to the Covid 19 outbreak, many organisations around the world went through a sudden digital transformation and many people became home workers. With this near-instant operational pivot to distributed and remote teams, organisations and the people within them encountered new and difficult challenges such as poor internet connectivity, inadequate home offices, and trying to manage simultaneous family and work life.

One of the biggest challenges is the impact of being physically distant from our teammates on our psychological wellbeing. Distributed teams have fewer opportunities for spontaneous, casual conversation; team members have more difficulty picking up non-verbal cues in conversation, and people are more likely to feel alone, anxious, unsure of what to do, and may even experience self-doubt or imposter syndrome.

Psychological safety is the number one requirement for high performing teams. Without it, a team will never achieve high performance and the members of that team will not be able to realise their full potential. Now that many of our teams are distributed and remote, psychological safety is even more difficult to build and maintain.

Here are ten things you can do, whether you’re a leader or a member of your team, to help foster and build psychological safety, and increase the performance and happiness of your team and yourself

1. Set the stage.

We’re all going through difficult times, whether it’s financial concerns, supporting vulnerable friends and relatives or just dealing with the mental load of what’s happening in the world. Be honest about this with your team. Be explicit about the challenges ahead, and show your vulnerability. Without you showing vulnerability, your team will be unlikely to, and it’s a key part of building psychological safety. Be positive and enthusiastic about facing these challenges. 

management and leadership

2. Make sure everyone knows what to do.

Knowing what to do, when to do it, and what good looks like is crucial for remote team members. It’s far more difficult to ask for advice or assistance when remote, and self-doubt will creep in quickly. So make sure team members know what is expected of them, and ensure that workloads and deliverables are realistic. 

3. Focus on outcomes, not outputs. 

Outcomes matter more than anything else. Whether your desired outcome is satisfied customers, revenue generated, uptime, or something else, focus on that, and ensure the team remain focussed on it. Resist the temptation to revert to more traditional, “lazy” styles of management by measuring outputs, lines of code written, story points completed or meetings attended. And certainly avoid falling back to input-driven management by logging hours worked – we already know that is a route to reduction of psychological safety and it’s the last thing a distributed team needs. 

By keeping the team focussed on what really matters to the business, psychological safety will be improved, because team members will know that their hard work makes a difference, and they can contribute to the success of the organisation.

outcomes vs outputs

4. Build a culture of appreciation.

When we’re all in the same place, appreciation and thanks are much easier to communicate and tend to be passive or automatic. With distributed teams, much more effort needs to be made to ensure team members feel valued and appreciated. This means being much more explicit with appreciation, and communicating it in multiple ways such as through video calls, emails, and instant messaging. It’s very easy to forget how often we thank each other when we’re co-located, and without that culture of appreciation, psychological safety will suffer.

5. Embrace routine and ritual.

The dramatic shift in ways of working has resulted in disruption to our routines – our start and finish times, any regular meetings, and lunch breaks have all been disrupted. Routines help us as humans feel more comfortable and psychologically safe when the world around us is changing and there is so much uncertainty elsewhere. 

Ritual also plays an important role in team cohesion, particularly so with distributed and remote teams. Every team will have its own rituals and ceremonies, from ringing a bell at a sprint kickoff, to having end-of-week drinks on a video call. Whatever the rituals are, keep them up in order to build psychological safety.

ringing a bell

6. Establish work boundaries.

Work has invaded our homes and our personal space and time. It’s very easy to allow work to spread out, particularly if strict boundaries are not set. Help your team set these boundaries, and enforce and model them. This may be ensuring that team members can turn off their phones after 6pm without worrying about missing important messages, or purchasing home office equipment so they don’t need to work from their kitchen table. 

To maintain psychological safety, team members need to be able to remove themselves from work and maintain their own personal, home and family space.

7. Use the many species of video call.

Video calls aren’t just for meetings. To bring back the feeling of cohesion and togetherness that is so important for psychological safety, try out different kinds of video call, such as “good morning” meetings to start the day, or by having an “always-on” watercooler style meeting where people can drop in and out as desired. Feeling more connected to team mates will build psychological safety and improve communication.

8. Be actively inclusive, or risk being passively exclusive.

In an office setting, it’s easy to see if someone is not engaged or is pulling away from the team. With a distributed team, this is far more difficult even on video calls. 

A critical stage of psychological safety is “contributor safety” – everyone needs to contribute if the team is to achieve high performance, and in distributed and remote teams, if you’re not being actively inclusive, you’re risking being passively exclusive. To build psychological safety, invite participation, ask questions, and always ensure that everyone has spoken at least once before ending a meeting.

one person withdrawn from the group

9. Adopt Hanlon’s razor.

First published in German in 1774, Johann Wolfgang von Goethe wrote in The Sorrows of Young Werther: “Misunderstandings and lethargy perhaps produce more wrong in the world than deceit and malice do. At least the latter two are certainly rarer.” A sentiment later attributed to Robert J. Hanlon, hence “Hanlon’s razor”.

That is to say, it is important to assume the best intentions. If an email or message comes across as rude, blunt, or offensive, assume it was a miscommunication or misunderstanding. If in doubt, ask for clarification, ideally via video or voice.

To avoid others falling into the same trap, embrace emojis and gifs in your communications, even if they’re not your usual style. Emojis and gifs can help build and maintain psychological safety by ensuring that your communication is received in the most positive way possible.

smiley emoji helps to reassure intention

10. Put your own oxygen mask on first.

If you’re struggling with your own psychological safety, you will not be as effective in helping others with theirs. Find a mentor to advise and help you, eat healthily (but remember to treat yourself), exercise, meditate, and take time away from work; essentially, do whatever you know helps you maintain a happy and healthy approach and pace of work. As leaders of teams, many of us get so focused on caring for our team members that we minimise or neglect our own needs, but if you don’t look after yourself, you can’t look after others.

Finally, be patient. These are difficult times, and it’s to be expected that we will all experience challenges that impact our psychological safety and that of our team members. Utilising the ten behaviours above will help you and your team maintain psychological safety and improve not just team performance, but happiness too. Remember, happy teams aren’t happy because they’re high performing: they’re high performing because they’re happy.

Check out information about how to measure psychological safety in your teams here.

Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

For more information about building psychologically safe teams, read more about DevOps and psychological safety, read about high performing teams and psychological safety, or get in touch if you’d like me to speak or work with you.

Psychological Safety in High Performing and Effective Teams

This is a recording of a webinar I did for the meetup group Digital Lincoln on the 28th April 2020.

Psychological Safety in High Performing and Distributed Teams

Safety isn’t just necessary in order to prevent disasters, it’s also crucial to building and maintaining high performance teams and organisations.

Building high performing software requires high performing teams, in which team members need to feel able to express their creativity, talents and skills without self-censoring, self-silencing, or fear of failure. In this talk, Tom introduces the latest research in high performance technology teams, and provides actionable concepts to help you build and elevate your team, whether co-located or distributed and remote.

Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

Tom is an expert in transforming team performance. A “veteran technology team builder” according to Computing Magazine, Over his 15 years as a technology leader, he has come to believe that culture trumps strategy, and happiness precedes success.

Tom is currently the Head of Technology at MoreNiche in Nottingham, CTO of Ydentity, an identity protection startup, and a management consultant for Q5. Outside of work, Tom is a yoga teacher and mountain biker.

https://www.crowdcast.io/e/missile-destroyers

Compliance in DevOps and public cloud.

As a DevOps engineer, you’ve achieved greatness. You’ve containerised everything, built your infrastructure and systems in the cloud and you’re deploying every day, with full test coverage and hardly any outages. You’re even starting to think you might really enjoy your job.

Then why are your compliance teams so upset?

Let’s take a step back. You know how to build secure applications, create back ups, control access to the data and document everything, and in general you’re pretty good at it. You’d do this stuff whether there were rules in place or not, right?

Not always. Back in the late 90’s, a bunch of guys in suits decided they could get rich by making up numbers in their accounts. Then in 2001 Enron filed for bankruptcy and the suits went to jail for fraud. That resulted in the Sarbanes-Oxley Act, legislation which forced publicly listed firms in the US to enforce controls to prevent fraud and enable effective audits.

Sarbanes-Oxley isn’t the only law that makes us techies do things certain ways though. Other compliance rules include HIPAA, ensuring that firms who handle clinical data do so properly; GDPR, which ensures adequate protection of EU citizens’ personal data; and PCI-DSS, which governs the use of payment card data in order to prevent fraud (and isn’t a law, but a common industry standard). Then there are countless other region and industry specific rules, regulations, accreditations and standards such as ISO 27001 and Cyber Essentials.

Aside from being good practice, the main reason you’d want to abide by these rules is to avoid losing your job and/or going to jail. It’s also worth recognising that demonstrating compliance can provide a competitive advantage over organisations that don’t comply, so it makes business sense too.

The trouble is, compliance is an old idea applied to new technology. HIPAA was enacted in 1996, Sarbanes-Oxley in 2002 and PCI DSS in 2004 (though it is frequently updated). In contrast the AWS EC2 service only went out of beta in late 2008, and the cloud has we know it has been around for just a few years. Compliance rules are rarely written with cloud technology in mind, and compliance teams sometimes fail to keep up to date with these platforms or modern DevOps-style practices. This can make complying with those rules tricky, if not downright impossible at times. How do you tell an auditor exactly where your data resides, if the only thing you know is that it’s in Availability Zone A in region EU-West-1? (And don’t even mention to them that one customer’s Zone A isn’t the same as another’s).

As any tech in a regulated industry will appreciate, compliance with these rules is checked by regular, painful and disruptive audits. Invariably, audits result in compliance levels looking something like a sine wave:

This is because when an audit is announced, the pressure is suddenly on to patch the systems, resolve vulnerabilities, update documents and check procedures. Once the audit is passed, everyone relaxes a bit, patching lags behind again, documentation falls out of date and the compliance state drifts away from 100%. This begs the question, if we only become non-compliant between audits, is the answer to have really, really frequent audits?

In a sense, yes. However, we can no longer accept that audits with spreadsheet tick box exercises, and infosec sign-off at deployment approval stage actually work. Traditional change management and compliance practices deliberately slow us down, with the intention of reducing the risk of mistakes.

This runs counter to modern DevOps approaches. We move fast, making rapid changes and allowing teams to be autonomous in their decision making. Cloud technology confuses matters even further. For example, how can you easily define how many servers you have and what state they’re in, if your autoscaling groups are constantly killing old ones and creating new ones?

From a traditional compliance perspective, this sounds like a recipe for disaster. But we know that making smaller, more frequent changes will result in lower overall risk than large, periodic changes. What’s more, we take humans out of the process wherever possible, implementing continuous integration and using automated tests to ensure quality standards are met.

From a DevOps perspective, let’s consider compliance in three core stages. The first pillar represents achieving compliance. That’s the technical process of ensuring workloads and data are secure, everything is up to date, controlled and backed up. This bit’s relatively easy for competent techs like us.

The second pillar is about demonstrating that you’re compliant. How do you show someone else, without too much effort, that your data is secure and your backups actually work? This is a little more difficult, and far less fun.

The third pillar stands for maintaining compliance. This is a real challenge.  How do you ensure that with rapid change, new technology, and multiple teams’ involvement, the system you built a year ago is still compliant now? This comes down to process and culture, and it’s the most difficult of the three pillars to achieve.

But it can be done. In DevOps and Agile culture, we shift left. We shorten feedback loops, decrease batch size, and improve quality through automated tests. This approach is now applied to security too, by embedding security tests into the development process and ensuring that it’s automated, codified, frictionless and fast. It’s not a great leap from there towards shifting compliance left too, codifying the compliance rules and embedding them within development and build cycles.

First we had Infrastructure as Code. Now we’re doing Compliance as Code. After all, what is a Standard Operating Procedure, if not a script for humans? If we can “code” humans to carry out a task in exactly the same way every time, we should be able to do it for machines.

Technologies such as AWS Config or Inspec allow us to constantly monitor our environment for divergence from a “compliant” state. For example, if a compliance rule deems that all data at rest is encrypted, we can define that rule in the system and ensure we don’t diverge from it – if something, human or machine, creates some unencrypted storage, it will be either be flagged for immediate attention or automatically encrypted.

One of the great benefits of this approach is that the “proof” of compliance is baked into your system itself. When asked by an auditor whether data is encrypted at rest, you can reassure them that it’s so by showing them your rule set. Since the rules are written as code, the documentation (the proof) is the control itself.

If you really want your compliance teams to love you (or at least quit hassling you), this automation approach can be extended to documentation. Since the entire environment can be described in code at any point in time, you can provide point-in-time documentation of what exists in that environment to an auditor, or indeed at any point in time previously, if it’s been recorded.

By involving your compliance teams in developing and designing your compliance tools and systems, asking what’s important to them, and building in features that help them to do their jobs, you can enable your compliance teams to serve themselves. In a well designed system, they will be able to find the answers to their own questions, and have confidence that high-trust control mechanisms are in place.

Compliance as Code means that your environment, code, documentation and processes are continuously audited, and that third, difficult pillar of maintaining compliance becomes far easier:

This is what continuous compliance looks like. Achieve this, and you’ll see what a happy compliance team looks like too.

 

Re:Develop.io History of DevOps talk

I recently gave a talk at Re:Develop.io about the history of DevOps, and this page is where you can find the slide deck and other relevant resources.

Video of the talk

Re:develop.io DevOps Evolution Slide deck

The Theory of constraints

Agile 2008 presentation by Patrick DuBois

10+Deploys per day, Dev and Ops at Flickr – Youtube

10+deploys a day at Flickr – slide deck

DORA 

Nicole Forsgren research paper

2018 State of DevOps Report

My “Three Ways” slide deck

Safety culture

Amazon DevOps Book list

Deming’s 14 points of management

Lean management

The Toyota Way

The Agile Manifesto

Beyond the phoenix project (audio)

Netflix – simian army

My Continuous Lifecycle London talk about compliance in DevOps and the cloud

 

 

 

 

The OSI model for the cloud

While I was putting together a talk for an introduction to AWS, I was considering how to structure it and thought about the “layers” of cloud technology. I realised that the more time I spend talking about “cloud” technology and how to best exploit it, manage it, develop with it and build business operations using it, the more some of our traditional terminologies and models don’t apply in the same way.

Take the OSI model, for example:

 

When we’re managing our own datacentres, servers, SANS, switches and firewalls, we need to understand this. We need to know what we’re doing at each layer, who’s responsible for physical connectivity, who manages layer three routing and control, and who has access to the upper layers. We use the terms “layer 3” to describe IP-based routing or “layer 7” to describe functions interacting at a software level, and crucially, we all know what each other means when we use these terms.

With virtualisation, we began to abstract layers 3 and above (layer 2? Maybe?) into software defined networks, but we were still in control of the underlying layers, just a little less “concerned” about them.

Now, with cloud tech such as AWS and Azure, even this doesn’t apply any longer. We have different layers of control and access, and it’s not always helpful to try to use the OSI model terms.

We pay AWS or Azure, or someone else, to manage the dull stuff – the cables, the internet connections, power, cooling, disks, redundancy, and physical security. Everything we see is abstract, virtual, and exists only as code. However, we still possess layers of control and management. We may create multiple AWS accounts to separate environments from each other, we’ll create different VPCs for different applications, multiple subnets for different functions, and instances, services, storage units and more. Then we might hand off access to these to developers and testers, to deploy and test applications.

The point is that it seems we don’t yet have a common language, similar to the OSI model, for cloud architecture. Below is a first stab at what this might be. It’s almost certainly wrong, and certainly can be improved.

Let’s start with layer 1 – the physical infrastructure. This is entirely in the hands of the cloud provider such as AWS. Much of the time, we don’t even know where this is, let alone have any visibility of what it looks like or how it works. This is analagous to layer 1 of the OSI model too, but more complex. It’s the physical machines, cabling, cooling, power and utilities present in the various datacentres used by the cloud providers.

Layer 2 is the hypervisor. The software that allows the underlying hardware to be utilised – this is the abstraction between the true hardware and the virtualised “hardware” that we see. AWS uses Xen, Azure uses a modified Hyper-V, and others use KVM. Again, we don’t have access to this layer, but a GUI or CLI layered on top. For those of us who started our IT careers managing physical machines, then adopted virtualisation, we’ll be familiar with how layer 2 allowed us to create and modify servers far quicker and easier than ever before.

Layer 3 is where we get our hands dirty. The Software Defined Data Centre(SDDC). From here, we create our cloud accounts and start building stuff. This is accessed via a web GUI, command line tools, APIs or other platforms and integrations. This is essentially a management layer, not a workload layer, in that it allows us to govern our resources, control access, manage costs, security, scale, redundancy and availability. It is here that “infrastructure as code” becomes a reality.

Layer 4. The Native Service (such as S3, Lambda, or RDS) or machine instance (such as EC2) layer. This is where we create actual workloads, store data, process information and make things happen. At this level, we could create an instance inside a VPC, set up the security groups and NACLs, and provide access to a developer or administrator via RDP, SSH, or other protocol. At this layer, humans that require access don’t need Layer 3 (SDDC) access in order to do their job. In many ways, this is the actual IaaS (Infrastructure as a Service) layer.

Layer 5. I’m not convinced this is all that different to layer 4, but it’s useful to distinguish it for the purpose of defining *who* has access. This layer is analogous to layer 7 of the OSI, that is, it’s end-user-facing, such as the front end of a web application, the interactions taking place on a mobile app, or the connectivity to IoT devices. Potentially, this is also analogous to SaaS (Software as a Service), if you consider it from the user’s perspective. Layer 5 applications exist as a function of the full stack underneath it – the physical resources in datacentres, the hypervisor, the management layer, virtual machines and services, and the code that runs on or interacts with the services.

Whether something like an OSI model for cloud becomes adopted or not, we’re beginning to transition into a new realm of terminology, and the old definitions no longer apply.

I hope you found this useful, and I’d love to hear your feedback and improvements on this model. Take a look at ISO/IEC 17788 if you’d like to read more about cloud computing terms and definitions.

Finally, if you’d like me to speak and present at your event or your business, or provide consultation and advice, please get in touch. 

tom@ec2-34-242-84-40.eu-west-1.compute.amazonaws.com

@tomgeraghty

https://www.linkedin.com/in/geraghtytom/

The Three Ways

The three ways are one of the underlying principles of what some people call DevOps (and what other people call “doing stuff right”). Read on for a description of each approach, which when combined, will help you drive performance improvements, higher quality services, and reduce operational costs.

1. Systems thinking.

Systems thinking involves taking into account the entire flow of a system. This means that when you’re establishing requirements or designing improvements to a structure, process, or function, you don’t focus on a single silo, department, or element. This principle is reflected in the “Toyota way” and in the excellent book “The Goal” by Eliyahu M. Goldratt and Jeff Cox. By utilising systems thinking, you should never pass a defect downstream, or increase the speed of a non-bottleneck function. In order to properly utilise this principle, you need to seek to achieve a profound understanding of the complete system.

It is also necessary to avoid 100% utilisation of any role in a process; in fact it’s important to bring utilisation below 80% in order to keep wait times acceptable. See the graph below.

2. Amplification of feedback loops.

Any (good) process has feedback loops – loops that allow corrections to be made, improvements to be identified and implemented, and those improvements to be measured, checked and re-iterated. For example, in a busy restaurant kitchen, delivering meatballs and pasta, if the guy making the tomato sauce has added too much salt, it’ll be picked up by someone tasting the dish before it gets taken away by the waiter, but by then the dish is ruined. Maybe it should be picked up by the chef making the meatballs, before it’s added to the pasta? Maybe it should be picked up at hand-off between the two chefs? How about checking it before it even leaves the tomato sauce-guy’s station? By shortening the feedback loop, mistakes are found faster, rectified easier, and the impact on the whole system – and the product – is lower.

3. Continuous Improvement.

A culture of continual experimentation, improvement, taking risks and learning from failure will trump a culture of tradition and safety every time. It is only by mastering skills and taking ownership of mistakes that we can take those risks without incurring costly failures.

Repetition and practice is the key to mastery, and by considering every process as an evolutionary stage rather than a defined method, it is possible to continuously improve and adapt to even very dramatic change.

It is important to allocate time to improvement, which could be a function of the 20% “idle” time of resources if you’ve properly managed the utilisation of a role. Without allocating time to actually focus on improvement, inefficiencies and flaws will continue and amplify well beyond the “impact” of reducing utilisation of said resource.

By utilising the three ways as above, by introducing faults into systems to increase resilience, and by fostering a culture that rewards risk taking while owning mistakes, you’ll drive higher quality outcomes, higher performance, lower costs and lower stress!

For my presentation on the Three Ways, click here. Feel free to use, adapt, and feed back to me 🙂

10 elements of managing a successful IT team

  • Give time to your team
    • 1-1’s, development reviews, PDR’s, working together on projects, or just time for a coffee and a chat. Whatever you call it, it’s important to regularly spend time with each of the team members. Rarely, if ever, will you find that one of these sessions wasn’t worthwhile. Just don’t rush it.
  • Make sure everyone has a role.
    • Every single member of your team is important, and everyone needs to feel that their efforts are worthwhile, whether it’s setting up new servers, systems, and infrastructure, or manning the telephones and taking calls. Nobody likes to feel like the spare wheel, and it’s unproductive, but it can easily happen.
  • Take them with you.
    • Going to a conference, seminar, networking event or similar? Take one of the team with you, and prioritise the junior members. It’s a great learning experience for them, and a good bonding exercise for the both of you. You don’t need to do this every time, but depending on the size of the team, it should at least be possible to do this once a year per team member.
  • Put the team first.
    • Your team get things done. Without them, you’re nothing. Put them first, and make sure they know you’re fighting their corner. Even if it means you taking the hit for something, or to the detriment of your reputation in the business, ultimately if your team see you working hard for them, they’ll work hard for you. In the long run, this is what matters more.
  • Be a good role model
    • Demonstrate a good work / life balance. This isn’t easy, and particularly in IT, where the servers don’t sleep just because you do, but if you can show that you work when you need to, and relax when you can by making the most of your free time, it’ll set an example that will help prevent burn-out and make for a more productive, enjoyable work environment.
    • Don’t be late. Set standards that the rest of the team can abide by. Get to work on time, be prompt for meetings. Don’t be a “Do as I say, not as I do” boss.
    • Be tidy. If you want your team to keep a tidy workspace, it’s going to be a lot easier if you set a good example.
    • Put in the extra hours when you need to, but make sure you take those holidays that you earn. Don’t make your team feel guilty if they ask for time off.
    • Customer service – put the customer first. In internal IT departments, the customer is the end-user, and the old stereotype of IT helpdesk staff disliking end users still holds true in many cases. Make sure your team know that while half of their job is technical, in some ways the most important half is good old customer service. Set an example by providing excellent service to your customers.
    • Respect your colleagues – set a good example by not complaining about your colleagues in the business. Even if you’ve been terribly disappointed or let down by one of your peers, don’t pass that down to your team. It’s demotivating for them to hear, and can damage relationships between departments and teams. Be open, but not negative.
    • Enjoy your job and be positive! If you don’t enjoy what you do, it’ll be clear to your team, but if you enjoy what you do, that positivity will spread.
  • Ask for feedback
    • Don’t be afraid to ask for feedback from your team. This can be intimidating, especially in person, but it’s absolutely invaluable. Asking “is there anything I could be doing that I’m currently not doing?” or “What could I be doing better?” will provide you with superb information to help you develop and improve as a manager, and help to identify any issues that could be hindering the team’s productivity. If the answer to both of these questions is “nothing”, then well done – however make sure you ask it regularly and phrase it differently each time to tease out any issues.
  • Keep up to date.
    • Ask for regular updates on performance, tasks, challenges, difficulties and successes. Whether you do this via email, phone, in person, or some other way will depend on your particular circumstances. Personally, I like the “15/five” style of weekly report via email, meaning it should take them 15 minutes to write, and you 5 minutes to read, but use whatever works for you.
  • Focus on development.
    • IT careers are all about what you know, and what experience you have. If you let your staff development fall behind, not only will they become less productive, but they’ll be thinking about moving on to somewhere else to continue to learn and develop their skills and knowledge.
    • Engender a culture of learning and knowledge sharing. In our team, we share “discoveries” every Friday via group emails, demonstrating what we’ve learned or discovered that week, from how to create a new maintenance task in SQL Server, what the new features of the iPhone 6 will be, or even facts about dinosaurs, particle accelerators, or IT industry figures…
  • Follow through on what you say.
    • This should go without saying, but you see it all the time. If you say you’ll do something, do it. Or, if it turns out that you can’t, don’t have time, or the situation changes, inform your team and explain why.
  • Be the best that you can be.
    • No pressure, right? Always strive to be as good as you can possibly be. Don’t burn yourself out, but be constantly looking for ways to improve yourself, the team, the environment, your business and your role. Be awesome.

 

Have I missed anything? I’m sure I have, so let me know by commenting.

Work in IT? Here’s how to ask for a pay rise.

Either ask for a review or 1-1 with your manager, or wait until the next scheduled one. I’d prefer one of my team to ask me for a chat about salaries rather than ambush me with a request, but whatever works with your company culture.

In terms of negotiating, use the following:

  • What have you achieved in your role in the business, and what benefit has that returned? Ignore your standard duties – that’s what you’re employed for anyway. If you do something that clearly makes/saves the business £100k pa, a few k raise is an easy decision.
  • What’s the pay grade for your job across your industry? If you’re good, I don’t want to lose you just because I didn’t pay you enough. Equally, be careful of earning over industry average – you’ll be stuck in a job.
  • Be aware of any mistakes or failures you’ve had. It’s no good shouting about the £100k project you managed if you also ran one that lost £150k.
  • Look at the financial status of the business. If the business is doing well and has turned a sizeable profit, highlight it. This not only shows that the business could afford to give you the raise, but that you’re savvy enough to understand the commercial world you operate in. If the business turned a loss, be very wary of asking for a raise.
  • Have a backup plan. Could you ask for an additional training course? A performance-related bonus instead of a flat raise? If times are hard for the business, could you suggest a post-dated raise, or extra holiday in lieu of pay?
  • Be aware that with a raise comes extra responsibility. Don’t make your manager regret their decision to invest extra money in you. If taking that raise means working an extra few hours a week and extra pressure to hit targets, do you still want it?
  • Play the long game. Don’t suddenly start putting in a few extra hours here and there a few days before you ask. Be consistently excellent long-term.
  • Be aware of the rest of your team. It’s potentially worth suggesting not just a raise for yourself, but a blanket raise for the team, or certain members. Do you want to be the one on £10k more than your team-mate?
  • Ultimately, make the decision easy to make for your manager. They’re going to have to justify it in their budget, and potentially go to ask their boss for the money to pay you anyway. They don’t want to regret their decision.
  • Finally. Don’t forget to actually ask for the pay rise.

The ten principles of IT Management (and probably a lot of other jobs).

1. Work your way out of a job.

If there’s any procedure, task, or process that you have to carry out or manage more than once, you should consider automating it. What’s the point in you doing it, if a machine can? Of course, some things have to be done by a human, but can you streamline the task? For example, can you stop searching through event logs every week, and instead set up a monitoring system that will alert you by email and/or sms to certain types of errors?

2. Make life easier for users

Your users are customers. They pay your wages and are essentially the only reason you’re in the job. By making their life easier, you’re enabling them to make money for the business, instead of working the system. You’ll also be making them happier, and that’s a good thing.

3. Constantly evaluate costs, and try to reduce them.

Costs creep up. They always do, and forever will do. Keep an eye on them, and constantly try to think of ways that you can reduce them: do you need that old server, or can it be virtualised? Do you need all your mobile connections, or can you cancel some? Do you have any old printers that aren’t utilised enough? Get rid of them. Is your hardware vendor giving you the best deals? Are you out of contract with your telecoms firm, support firm, leased lines, printers, or anything else? If so, look for a better deal and/or renegotiate.

4. Constantly evaluate the business, and try to increase productivity.

Don’t take your eye off the ball with what the business is up to. It’s easy to focus on the day to day stresses of the IT function, and your pet projects, while the business starts running in a different direction, and before you know it, you’re off doing something that is hard work, and provides no benefit to the business, or you’ve missed an opportunity. Get involved in the different functions, like marketing, and strategy (even if your directors don’t actively involve you – just get in there anyway.)

5. Consolidate

One contract is better than two. Vendors fight harder for bigger contracts, and there are big efficiency savings to be made by consolidating. Multiple contracts for a similar service just wastes money, administrative effort, and doesn’t make the supplier work as hard for you.

Consolidation applies also to IT systems and infrastructure, of course, but only where sensible. One server can carry out multiple roles, but not at the expense of reliability, or necessary performance.

6. Be a pessimist – plan for disaster.

Shit does happen, and it will happen in ways that you didn’t predict. When setting up and supporting systems, ask yourself:

“How could this fail?”

“What’s the impact if it does fail?”

“How can i recover from failure?”

and

“How can I reduce the likelihood of it failing?”

Note that you can never completely prevent something from failing, but you can make it so unlikely that you don’t have to worry. Ideally, everything should have a redundant partner, ready to failover, but if that’s not possible, make sure to be ready to recover from failure, and mitigate the impact.

7. Be an optimist – plan for expansion and success.

As important as planning for failure, is planning for success. If you have 2000 users now, don’t spec a mailserver with just enough capacity to serve all of them just enough. Spec a server with enough capacity for 3000, or 4000, or 10000. Don’t spend more than you need to, but you can guarantee that if you only spec just enough now, it won’t be enough in a year or two.

8. Don’t be afraid to make mistakes.

Try new things, and accept that not all your endeavours will work out well. Some may turn out to be awful, but some may turn out great. Try out new technologies, new systems, or even old systems that you haven’t tried before. If you don’t know how to do something, ask. And if there’s nobody to ask, do it anyway, and work it out.

9. Stay on top of technological progress.

Go to seminars, webinars, workshops, training events, trade shows, and new product demonstrations. It’s easy to get behind in IT, and you don’t know the things you don’t know. You can’t do many of the things before this item if you don’t know about the newest technology, systems, products, or services. Also, by keeping really up to date, you can help your business keep ahead of their competitors.

10. Network

And I don’t mean with ethernet cables. Networking is especially important if you work in a small IT team, partly because you learn best from others. You’ll learn what other people are doing, how they’re doing it, why, and who with. You’ll find out how to do a better job for your business, and make a better career for yourself.