skip navigation
skip mega-menu

Being an effective ally

By Andy Tebb, Director of FC BU Presales & Engineering Centre UK&I

Why we focus on diversity

In GlobalLogic we help our clients to build products. We don’t own any IP ourselves, everything we do is owned by those clients and as a result, you probably won’t know who we are. 

Despite that, I’m pretty confident that today you’ll have used one of the products we work on. Roughly a billion people a day use one of the maps that thousands of our colleagues curate and develop. If you’ve bought a plane ticket, used a mobile banking application, driven an electric car, or ordered fast food using a touch screen, there is a better than evens chance GlobalLogic work was involved in designing and building your interface [note: if you had a bad experience while doing it, that probably wasn’t us].

In the UK, our Product Engineering teams have a mission statement; developing products with teams that reflect the communities that use them. As a result, our Product Engineering Labs in the UK need to reflect the diversity that constitutes GlobalLogic around the world. We have been broadly successful, but have more to do. 

Right now, 1 in 3 of our developers are women and we want to go further.

We have learned many lessons along the way, and we want to share them. If you’re a manager of a team, you can implement these changes at any level and choose which ones will suit you. We believe that all and as broadly as possible is the right answer, but if you are looking for practical steps to be an effective ally, we think these 3 articles offer effective changes for a more inclusive workspace.

Core Hours

For most people in the UK, core hours are 9 to 5 or, in some cases, 10 to 4. This doesn’t really reflect external commitments, the most obvious being childcare.

For us, core hours are the hours that you can reasonably expect your colleagues to be available. The hours where it isn’t rude to schedule meetings or calls. We all have these concepts in our working etiquette. 

I might need to do a call at 6 am or 10 at night, but everyone knows and acknowledges that it’s inconvenient and not the norm.

In our Product Engineering Labs, we simply say that the core hours for meeting and collaboration are 10 to 3. Everyone still works 8 hours a day, but you know that 10 to 3 is when you should aim to collaborate.

This allows colleagues to commute to pick up their children, but it also allows developers to schedule blocks of coding time that they know won’t be interrupted. It makes colleagues think about whether they need a meeting. It forces managers to remember that work is more than meetings.

The instinctive reaction from other managers and team members is, “that wouldn’t work in my area because…”

There are a couple of key points here. Firstly, it won’t be suitable for everyone but it will for the vast majority of us who work in development. Don’t let the perfect be the enemy of progress.

Secondly, this makes a massive difference to all colleagues. Approach it with a focus on how to make it work, not whether you should do it. The hurdles are comparatively low and it really is worth it.


Much of the work that makes an office thrive is based on voluntary effort, things like organising a collection, being a fire marshal, speaking at an event, organising a social. Typically, this falls on a small group of women in an office.

In response, we have incorporated a contribution metric into the performance review process. Talking at event, being a first aider, writing a blog, joining a committee… any of these count as contribution and help you meet your annual objectives.

We’ve found that this change acknowledges the importance of this work, does not disadvantage those who embrace the need for these contributions, and makes for a more meaningful experience for everyone in the office, providing an aspect to their career that they would not otherwise have pursued.

Subscribe to our newsletter

Sign up here