Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Leaders Discuss How to Build Great Engineering Cultures

Leaders Discuss How to Build Great Engineering Cultures

This item in japanese

QCon London’s Building Great Engineering Cultures and Organisations track brought together a panel of leaders to take questions from an audience, featuring a common thread of growing and leading teams with a balance for effectiveness and humanism. Leaders from Google, Sky Betting and Gaming, ITV, Deliveroo and GlobalSign shared how they support and build great cultures for engineers, accommodating for individual growth, organisational need, a social conscience and a balanced life.

The panel consisted of five engineering leaders from across a range of industries:

The panel discussion placed the seven leaders of software organisations in front of a live audience.

Audience: What are the often overlooked elements of building an engineering culture?

Galu suggested that the "social aspect is the most overlooked, as people spend a lot of time in front of a screen, but the secret of working together really well is knowing more about the other people."

Goble described herself as an introvert with a balanced life, and said:

I find it very frustrating that a lot of decisions are made in the social sphere. It's the same for a lot of people in engineering. I don't want to go out to the pub after work. I have a life. A lot of people who are more senior and have families are the same. I find it very difficult when people say the social thing is a really important aspect of culture.

Belwood pointed out that "what's often overlooked about culture is transparency." Belwood explained that when information, such as "salary grading and pay," is freely available, "people would be a lot more open and be able to understand where they were against say, external and internal benchmarking."

Walker said that psychological safety was often overlooked. He explained that this came down to "Bringing your whole self to work and being yourself. Not feeling pressure to be part of a culture which does not come naturally to you."

Goble also observed that the industry often fails in the way it trains, supports and promotes engineering management:

One of the things we do badly is having good training for managers...your only progression is to become a manager. You go into management and you're dumped on your own with no advice and no training, and without any inclination to be a manager. It's just a way you assumed you'd progress your career. Therefore we have a really terrible situation where many people are managed by managers who don't have an idea how to do it.

Clark commented on the evolution of the technical manager, describing a "renaissance of technical people who do want to lead," and have a broader set of interpersonal competencies.

Audience: A lot of companies are looking at architectural change, enhancing systems and replatforming. How do you engage stakeholders and developers in architectural change, and govern that?

Walker talked about the problem with architectural change, being one of communicating and measuring the value it delivers. He suggested that the way around this was to progress in small increments:

Architectural change is really hard to measure, so it's hard for people to know it's the right thing to do. You can either do a two year big bang, which involves a lot of trusts, or you can figure out how you can break it into smaller milestones where you can demonstrate the efficacy of your approach by increments. That way people are able to buy into it sooner.

Citing his experience with getting buy-in to re-architect Google Maps, at the point where its complexity meant it "wasn't scaling at all," Walker then went on to explain the need for openness and transparency with the business:

You also need to be really, really open about why you are doing this. About the problems you are facing right now which can only be solved if you change architecture, or even the opportunities you won't get to pursue if you don't. In our industry, we do a lot of architectural change for the sake of architecture. Because engineers love playing with the latest stuff. Sometimes it can be a hard sell to the organisation.

Clark also recommended an incremental approach where teams "start small and prove it with data, and grow it out from there." He spoke of his own experience with ITV, five years ago, where DevOps practices were introduced as an experiment on a low-risk project by someone willing to champion them.

Galu also shared his experience from a 3.5-year journey of rearchitecting GlobalSign's core platform. He pointed out that in addition to transparency it was important to increment on a releasable product. He spoke of how his teams gained a valuable feedback loop by advocating "the new platform to prospective customers who have started utilising it in a beta."

Audience: On my team everyone sees it as a job, turning up and doing their 9-5. How can I get people to be more passionate, engaged and feeling it's more than a job?

Galu responded that it was the responsibility of technical leaders to "chop the work into bits and pieces that feel like fun." He felt that a good product would emerge from creating the right conditions:

Turn things around, rather than just working towards the product the business needs, make personal and team development the product, and the actual product becomes a byproduct of that."

Bellwood felt that it was not appropriate to measure based on working hours, but instead to understand how to motivate each individual:

What you probably need to do is recognise what they are motivated by. What are their passions and what are their aspirations? Understand the individuals on the team. It's not a one size fits all approach.

Citing Dan Pink's book, Drive, Clark pointed out that motivation was best achieved by focusing on creating a climate with "three factors: autonomy, mastery and purpose in the right proportion." He described autonomy by pointing out that micromanaging a bright team would "not be massively motivating." He explained aiding mastery in a team by providing "Goldilocks tasks, which are slightly beyond their abilities, and they might need to learn something new, meet someone new or make a connection."

Clark then explained "purpose" as getting teams "to feel that what you do matters." While acknowledging that for some the motivation comes from working with the "latest tech and with really, really smart people", he also explained that entertaining tens of millions provided a greater purpose to many at ITV.

Walker shared that he had worked with a team which wasn't interacting, "working on their tasks and going home." He said, "they were never feeling a sense of belonging and one of the fundamental human requirements is feeling you belong to something." The issue was addressed by acknowledging it and intentionally introducing greater collaboration:

We came up with a rule, that no one works alone. No one is given a project on their own. You are split into teams with people because of the face-to-face interaction you have with people and the rapport you build when doing so, and the collaboration you show actually becomes the glue which binds people together.

Audience: What does the panel think about making employees work 9-5 so they can go home and get some rest? How much importance does this play in building a culture of healthy teams?

Walker stressed that it was "about what you're doing, not the hours you're keeping." He went on to point out the importance to mental health of maintaining balance outside of work:

Be clear to people that it's important to have a life outside of work. No matter how amazing your employer is, they are just a corporation. And if you burn out working for a corporation, they will say "thanks for playing," and move on with their lives while you remain broken. So, the first duty of care you have is to yourself, if you don't take care of yourself, nothing else matters.

Goble said that a pressure to work "hard and long" ran the risk of worsening the problem of "getting people who are more senior and more diverse." She said:

There is a problem with getting more senior women in our team, at management and staff levels. That's because we try to get them to work hard and work long. At Deliveroo, we're changing from being a delivery focused, long-hour working business, to one which says it's OK to employ people to work flexible hours, work remotely, work from home, or even, radically, work part-time. Changing that culture from one of being very delivery focused to one which says it's OK for someone to work four days a week, means that you can massively improve the quality and depth of your engineering team.

Audience: How have you dealt with cultural values of millenials? Such as differences with what is viewed as a healthy culture, life outside work not involving work, social media and charity as part of life.

Clark shared that one of his teams was experimenting with "not just being able to work anywhere remotely, but anywhen." They had successfully demonstrated that a team member could still be effective if substituting his Monday for a Sunday, in order to have common working hours with his partner.

"Volunteering is a corporate responsibility, where it's not just all about the bottom line," said Clark. He shared that ITV allows him to use three paid days a year for volunteering, saying it was important to do "things which are good for the individual and the human, and not necessarily about the bottom line."

Audience: How do you know you're not a bad manager?

Walker shared that it's a good sign "people feel able to tell you that you are wrong and they aren't just blindly nodding." This means that "you have cultivated an environment where people are willing to have opinions, back them up and feel it's safe to do so."

Clark talked of the value in seeking feedback, and having regular digital and face-to-face communication with his teams. He described how he seeks 360 feedback from his reports so that he has metrics to track against.

Audience: Can you share your experiences on open vs anonymous feedback?

Goble shared a personal anecdote from a time she'd received reprimanding but valuable feedback from a developer. The panel felt that honest feedback from one's reports was a key factor to improvement. She said:

That's the best feedback you can ever get as a manager. Someone making it very clear to you, how they want your relationship with them to be...You have to admit that as a manager, you are human too and make mistakes as well.

Walker added:

The first time one of your reports comes across to you and says, 'I'm uncomfortable with what you're doing,' is a massive inflexion point for them. They are taking an extraordinary personal risk in going to their manager and saying 'I think what you're doing is wrong.' How you handle that situation is going to govern the rest of your relationship with that person and bleed into the psychological safety of your team.

Clark shared how his teams' 360 reviews allow peers to share, optionally anonymous but trackable, feedback which assesses how well individuals perform their role and collaborate with others. He also spoke of the value which individuals got from being able to trace and measure such feedback.

Audience: When it comes to recruitment and bringing new people in, should we be hiring at the team or organisation level?

Walker said that Google had learned that bringing people onboard and just allocating them to a team had not been effective. After ensuring a suitable engineering hiring-bar, he spoke of the importance of candidates meeting with and finding a good fit within the hiring team.

Adding to this, Walker also talked about the importance of injecting a suitable diversity of perspectives into a team and preventing a monoculture from forming:

I also look at the skills and backgrounds within a team. If there is a somebody with a slightly odd set of skills or background, I might add that to a team to prevent a monoculture from being formed in there. For example, in a team of really hardcore Java programmers, add in someone with more of a DevOps focus to give them a different perspective to solve problems. It's worth looking at team composition and fit.

Walker and Goble spoke of the necessity to consider an individual's adaptability to organisation needs. Goble felt it important to have "flexibility to move engineers around the company if they are required." Walker explained that Google has a hiring bar of "generalist software engineer," which places candidates on a "trainer curve" defining their level of competence. He said, "as long as they are above the bar, they should be able to adapt to any other team."

Walker also explained how Google ensures internal mobility:

We have a strong policy on internal mobility. As a hiring manager, your job is to help them find the right role for themselves. You may hire somebody, but every 12 months they are entitled to apply for a transfer. You are obligated to support any transfer they wish to pursue. That's one of the best checks and balances for managers going rogue because people can just move teams.

Other topics included the effectiveness of dedicated people leads, building trust, flexible working and feedback systems. A full video of the panel discussion will be made available on InfoQ within the coming weeks.

Rate this Article