A Discussion on Team Culture

Aidan Cunnion at UXDX Community: Dublin. Video: https://www.youtube.com/watch?v=DhN0M60ghSM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What HMH does

[00:00:11] It's really nice to be here. Before I get into the topic itself, I just want to give a little bit more context around what HMH do, and a little bit of context for the type of environment that our teams are operating in, before I talk about some of our experiences in trying to build that strong team culture. There we go.

[00:00:35] In terms of what HMH do: HMH is very much focused on the educational technology sector. Our primary market is in the US, where, through the solutions that we offer, we have a user base of over 50 million users, and that's focused on the K to 12 market, kindergarten to 12 years of age. So where does Dublin fit into this? Although our corporate headquarters are based out of Boston, and we have other engineering team spaces, our largest engineering function is actually based out of Dublin, where we have over 150 engineers working on the design and development of our flagship learning platform, called Ed, and also full responsibility for our data practice.

[00:01:16] Why is that important? Over the past couple of years we've been on something of a transformation. Under the guidance of our new CEO, Jack Lynch, we've been moving away from being a very traditional educational publishing company focused on great content, looking to move to a learning company that's focused on great outcomes. It was described to me as moving away from the thud factor. I didn't really understand that until somebody said, well, a number of years ago salespeople used to walk into the classroom and drop the books on the desk, and the louder the thud, the more impressive it was. That doesn't really scale when you look at the digital space.

[00:01:51] What we're trying to do is provide a more tailored experience, where we still build on that great content, but when we provide it we want to tailor it more towards supporting the teacher and the students in the classroom. Through their interaction with that content, we can pull data, we can provide some data insights back, we can provide things like recommendations, and all of that is building towards providing better student outcomes. With that strategy in place, that obviously filters its way right down through the organization, and I think that's where we look at it from a team culture point of view.

Recognizing a strong team culture

[00:02:23] Culture, I suppose, is one of those intangible things, but I think we would all say that we recognize a strong team culture when we see it. Typically, when we see a strong team culture, it's a team that's collaborating well. They're communicating, there are high-value social interactions, and I think most important of all, they're supporting each other. When I was thinking about how best to present our experiences around team culture, rather than go through a series of slides I decided to choose this graphic. I appreciate there's a lot going on here, so what we're going to do is spotlight a couple of these areas and focus in on those.

Leadership and peer-to-peer learning groups

[00:03:01] The first one that I want to go a little bit deeper on is the area of leadership. Before I start, I do want to give a shout out to my colleagues in UX design, who have managed to make me about 20 years younger. My seven-year-old son saw it at the weekend and said, "It doesn't look anything like you, Daddy." I said, "Why not?" He said, "There's no wrinkles." Seven-year-olds have no filter, so it just comes straight out.

[00:03:23] From a leadership point of view, myself and my leadership team are really trying to create the environment in which a strong team culture can thrive, where it can flourish and where we get engagement from employees. We can set up teams with a clear direction and sense of purpose, but then we also need to provide that encouragement and allow them to grow and really perform at their best. When you look at where the company is going, and the focus on technology and in turn engineering, we will be very much to the forefront in trying to create the future value and innovation that the company is striving for, that differentiation that we need to achieve.

[00:04:02] That's where getting the employees engaged is so critical, because engaged employees are more enthusiastic about their work and the workplace. They are psychologically owners of the work that they're involved in, and can really help drive performance and the overall organization forward. But from an overall leadership point of view, we're also conscious that yes, the management level is critically important, but we also want to look at how we get those leadership skills in at the team level.

[00:04:32] Last year we started a series of peer-to-peer leadership learning groups, and the goal of this is to try and provide the leadership skills that our teams need on a day-to-day basis. Typically it's a group of around eight people, and there's a set curriculum that they follow, where they look at different aspects of leadership, like leading the work, leading the team and leading the system. These cover topics such as types of communication, like nonviolent communication; team effectiveness, looking at different studies around that, like Hackman; and frameworks like SCARF, which is a framework for collaboration and influencing.

[00:05:13] What we found is that over the course of the year it's been really successful. We've got over 60 people now participating in these groups, and it's really helped instill a sense of leadership skills within the broader teams themselves. It's something that we're very conscious they can use in their day-to-day. With that in mind, we're looking to expand it further, and also to broaden it out beyond Dublin and have it in some of the other sites as well.

Team launches and ownership

[00:05:41] Moving on to the core piece of it here, the teams themselves. When we set up a team, we're looking to obviously give them a clear purpose, et cetera, but we also want to make sure that the skills and experience are right. Every team that we create will have a product owner, and they'll have somebody from our product design team assigned to them. This was very much following the Hackman school of thought, that team forming and team launching are a critical first step.

[00:06:05] One of the small things that we do, which works really well, is that when the team is formed, we sit down in a session of typically about two to four hours, facilitated by somebody outside of the team. We sit down and try to get to grips with what they're there to do, what their vision and their focus is, and then start to look at establishing their working arrangements, their working norms, their ways of working. That would cover everything from definition of done, to unit test coverage, to even their pull request process. So we really start getting into the guts of it and getting a full understanding across the team.

[00:06:40] What we found is that by giving that ownership to the teams themselves, even though we set the targets and some direction at the management level, the teams own it. We say to them: from conception through to production, you own it, you build it, you support it. What we found is that teams are much more likely to come forward with, here's how we want to work together, here's the bar that we're setting for ourselves. That's been really important in instilling that sense of ownership and getting the type of behaviors that we want to see within the team.

[00:07:11] As they talk about things like their ways of working and the release process and all of that, what we're very conscious of is that with that sense of autonomy, and with those behaviors established, we would see other team members align to that, and other teams actually respond to that as well.

The environment shapes behavior

[00:07:31] A few months ago there was a series of podcasts done by Newstalk, and they featured Stuart Lancaster. For those that don't know Stuart Lancaster, he's the former English rugby union coach, and he's now a member of the Leinster rugby coaching team. He's very passionate about the areas of leadership. Each week there were different topics, but one week they were talking about team dynamics and performance, and the use of performance psychologists. One of the things that stuck with me was that when they pulled the different research together, they found that 70% of a person's behavior is influenced by the environment that they're in at that time. I think that really speaks to what we try to do: set up the right conditions for our teams, be aware of what's going on, and the teams themselves will respond to that. So it's about getting the right conditions in place.

Being a trusted partner to product

[00:08:16] What we're building towards is engineering teams being seen as really effective partners for our product teams: building that trust, being a trusted partner in the work that we're taking on. With the work that's happened over the last couple of years, I think we're seeing some of it come to fruition in terms of the partnership between ourselves and the product team. A couple of recent examples: we're actually going through a major redesign of one of the key functions, and we're at the early ideation stage around the design.

[00:08:54] Again, it's one of these small things, but the product design team invited a number of our engineers to take part in this early-stage workshop, and it was a real vote of confidence, I think, for the engineering team. Coming back from that, what struck me was the engineers' enthusiasm around what was being done. They identified some short-term wins for what we call our back-to-school period, for September of this year, and also longer term, and were very much buying in to what was being done. That commitment was there and that engagement was happening. Again, it just speaks to the timing of when that conversation happened. The timing of that invite helped infuse the team with a clear sense of direction.

[00:09:35] Another area: we're fortunate in Dublin that we have a number of our product owners sitting with the development teams, but we also have other product owners based in the US. We had them all over in Dublin a couple of weeks ago, and it was a really good week, with workshops across multiple different areas. One of the areas that we were very conscious of focusing on was how we get the balance right between new feature development and technical debt maintenance. On a new platform there's obviously a huge push to get new features on, whether it's trying to gain parity with the competition, or indeed trying to create some sort of differentiation.

[00:10:17] What we said was, look, that's great, we want to do that, but we also want to make sure that we're not ignoring the technical debt maintenance. We didn't want it to be a conversation where we're just making a rule: it's 30% capacity, and we do what we need to for technical debt. We wanted it to be a joint decision, where we as an engineering function can articulate the value and purpose of it, and the product team understand that and are bought into it, so that it's very much a joint decision, a conversation around moving it forward.

[00:10:52] Coming out of that: typically, in our release planning cycle, we'll have the different lines of business feeding in their prioritized requirements, and now we have engineering as another line of business, in which initiatives like platform maturity, which can be cross-cutting across teams, will now be part of our prioritization exercise. I think that again speaks to the work that's been done, but also to establishing a really good relationship with our product team.

Communication and transparency

[00:11:19] A lot of that, I think, comes down to the next item, which is communication. Communication is key: being open and transparent around what we're doing and why we're doing it. Six months ago we started a monthly project review meeting, and this was an open invite to anybody in the company, whether executives or the sales function, wherever they might be, to come along and hear what's happening within the engineering function. We spend typically a Thursday afternoon working our way through all the different projects that are underway: what's happened in the last month, what's happening in the following month, where we stand, what's the current status, what's going well and what's not.

[00:12:04] What's interesting is that initially there was some reluctance to that. It was seen as maybe a little bit of oversight: how is this going to go, we're going to be scrutinized around this. Well, what's come out of it is actually more credit for the engineering organization: you're laying your cards on the table, you're taking us through all the work that you're doing and what's happening, and that transparency is really refreshing. Even though it's a lot of work every month to stand up and get it all prepared, what we're seeing is feedback from other sections within the company, which again builds a partnership and that trust element with the other stakeholders that we're working with.

None of us is as smart as all of us

[00:12:49] Bringing this all back together: many different other aspects could be looked at, but for me it really comes back down to the team itself. A couple of years ago there was an article in Wired magazine that featured an individual called Bob Taylor, who, to be honest, I hadn't heard of. The headline was something like: Bob Taylor, the tech legend you've never heard of, but who invented almost everything. What was interesting about Bob Taylor was that he was at the forefront of some of the things that underpin a lot of modern computing today. He worked on ARPANET, he worked at Xerox PARC, and was involved in all of these initiatives.

[00:13:26] But his key passion was bringing together the best and the brightest and getting them to work as a team, because he really felt that what could be achieved as a team far surpassed even the best individual. Harnessing that energy, that team dynamic, was of critical importance to him. He had a motto, which I think was an old Japanese proverb, in his office: "None of us is as smart as all of us." I thought that was a really nice way of thinking about how you want to set your teams up, and the type of culture that you're striving for.

[00:14:01] All the work that we're doing around the openness and the transparency, the communication side, building that trust, standing up the teams, getting them focused, giving them a clear sense of direction: everything that we do, day to day, week on week, month on month, is intended to put in place the foundations that allow a strong team culture to thrive, and ultimately achieve the kind of great outcomes that the company is looking for. But most importantly, it's also to achieve the great outcomes that our students are looking for as well. Thank you for listening.

Q&A

[00:15:11] Aidan: Yep, it is. Can I just say, that's an internal one. The reason I wanted to share it was that it was something that the teams had put together around how they view how we operate day to day, and what we're striving for. It wasn't something that I'd put out as maybe a customer-facing piece. It's a little bit rough, so that's why. I was conscious of it, but I felt it was genuine in terms of how they see how they operate day to day. It's not necessarily something that we would use from a marketing point of view; it would need to be slimmed down a little.

[00:15:45] Audience: I just have one question, about how you measure the success of all the things you're doing to improve culture. Are there specific metrics? Are you looking at happiness, productivity? What are the sorts of things you're looking at?

[00:15:58] Aidan: It's a combination of things. Unfortunately there isn't just that one KPI that you can go to all the time. Even this morning I got an employee engagement survey, a follow-up to one that was done a number of months back. There was a major one done around August of last year, and coming out of that there were a number of different actions. The follow-on from that was a shortened one, but with each department now being able to put in specific questions around their function. From an engineering point of view, I think there were nine questions in total, three of which were engineering specific. What we were looking for there was, rate us, but also tell us where we can be better. What are the one or two things that are really stopping you from being effective in your day-to-day job? So we use that survey at the company level.

[00:16:44] At the engineering level, what we're doing with each team on a quarterly basis is a touch point where they fill out their adherence to agile practices, and how they feel about how they're working, whether they feel the autonomy that they need is there, and all of that. We're using that as guidance, to say some teams may be performing quite well, but due to certain circumstances we're seeing that tail off a little bit. It's a nice way of getting some insight into what's happening, not just doing it on a yearly basis but every quarter, like a heartbeat check with the teams. Then there are all the things that we do, obviously, as you can appreciate, from a metrics point of view in terms of our development. But in terms of trying to get into the heads of our engineers, that's what we've found to be most effective.

[00:17:40] Aidan: On the user testing, there are a couple of things that we do. We run a series of field tests. When you look at the educational market, it's interesting that the people who actually buy it aren't necessarily the people that use it. You end up with district administrators making purchasing decisions on behalf of the teachers, and then obviously there are the students who use it as well. You can appreciate that with kindergarten to 12 years of age, trying to customize your UI to cater for that age range is actually quite challenging. In many cases you've actually got a situation where the students in the classroom are more tech savvy than the teachers themselves, which is a whole other challenge.

[00:18:20] What we do is a number of field tests, where from a teacher's point of view we have our teacher flows and the various functions, and then likewise from the student side. We go in, we get a sample panel, we go through it, we video record all of that, and from that there are questionnaires, and that then feeds back into the nature of the changes that we want to see. Part of what we're trying to do with the revamp of one of the major areas, around discovering content, is again listening to the feedback from those field tests to understand where the pain points are, what we can address quickly ahead of back to school, and what the longer-term ones are that we need to take on.