A Discussion on Team Culture

A discussion on Team Culture

Speaker: Aidan Cunnion

Good afternoon, everyone. It's really nice to be here and before I get into talk about the topic itself, I’ll just go through the point Kathryn made, just to get a little bit more context around what HMH do and just set a little bit of context for the type of environment that our teams are operating in before I get in to talk about some of our experiences in trying to build that strong team culture. So in terms of what HMH does? HMH is very much focused on the educational team technology sector and 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, the kindergarten to 12 years of age. So where does Dublin fit into this?
Well, although our corporate headquarters are based out of Boston and we have engineering teams based there. 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 a data practice. Now, why is that important? Well, over the past couple of years, we've been on something of a transformation. So under the guidance of our new CEO, Jack Lynch, we've been moving away from what is a very traditional sort of educational publishing company, focused on great content, looking to move to a learning company that's focused on great outcomes. Now it was described to me as moving away from what was the thought effect. I didn't really understand that until somebody said, "Well, a number of years ago, salespeople used to walk into the classroom and when they drop the books on the desk the louder the ‘thud’ the more impressive it was." Now that doesn't really scale when you look at the digital space.
And what we're trying to do is provide a more tailored experience where we still want that great content. But when we provide it, we want to tailor it more towards supporting the teacher in the student, in the classroom and through their interaction with that content, we can pull data from that. We can provide some data insights back. We can provide things like recommendations and all of that is sort of building towards providing better student outcomes. So with that sort of strategy in place that obviously filters its way right down through the organisation and I think that's when we'd look at it from a team culture point of view. So culture, I suppose is one of those intangible things but I think we would all say that we recognise a strong team culture when we see it. So typically when we see a strong team culture, it's a team that's collaborating well or communicating high-value social interactions. And I think most important of all they are supporting each other. So when I was saying about how best to sort of present our experiences around team culture rather than go through with a series of slides, I decided to use this graphic. Now 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 on those. So the first one that I want to look at in terms of going a little bit deeper is in the area of leadership. Now, before I start, I do want to give a shout-out to my colleagues in UX design that have managed to make me about 20 years younger. I really appreciate it. My son saw it. My seven year old son saw it on the weekend and said it doesn't look anything like you dad. And when I said why not? He said there are no wrinkles. Seven year old, no filter, so it just comes straight out.
In terms of where from a leadership point of view myself and my leadership team are, we're 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 because we can set up teams with a clear direction and a sense of purpose but also then we need to provide that encouragement and allow them to grow and really perform at their best. And I think when you look at where the company is going, the focus on technology and in turn engineering, will be very much to the forefront in trying to create that future value innovation, that the company is very much striving for: that differentiation that we need to achieve.
And that's where getting the employees engaged is so critical because engaged employees are more enthusiastic about their work and their workplace. They are psychologically owners of the work that they're involved in and can really sort of help drive performance and the overall organisation forward. But we're also conscious I suppose from an overall leadership point of view that yes at the management level is critically important but we also want to look at how do we get those leadership skills in at the team level. So last year, what we started was a series of P to P leadership learning groups and the goal of this is to try to provide the leadership skills that our teams need on a day-to-day basis.
So typically it's a team or a group of around eight people, and there's a set curriculum that they follow where they look at different aspects of leadership and things like leading work, leading the team, leading the system. And these will be topics such as things like types of communication, like nonviolent communication, team effectiveness, looking at different studies around like Hackman and also then looking at things like frameworks, which like SCARF, are there for collaboration and influencing. What we found is that over the course of the year, it's been a real success. We've got over 60 people now participating in these groups. It's really helped instill a sense of some leadership skills within the broader teams themselves and it's something that we were very conscious that they can use in their day to day. So with that in mind, we were looking to expand that out further but also what we're looking to do, I suppose, is broaden it out beyond Dublin and actually have it in some of the other sites as well.
Moving on, as well to the core piece of it here, the teams themselves, so when we set up a team, we're looking to obviously give them a clear purpose, et cetera. We also want to make sure that the skills and experience are right. So every team that we create will have a product owner, they'll have somebody from our product design team assigned to them. I suppose very much following along the Hackman school of thought that team forming and the team launching are a critical first step that we do and it's one of these small things but it works really well. When the team is formed, we sit down typically a session of about two to four hours where it'll be facilitated by somebody outside of the team. What they do is, we sit down and try to get to grips with what they are there to do, what their focus is?
And then start to look at establishing their working arrangements, their working norms and their ways of working. That would cover everything from the Definition of Dome, to unit test coverage, to their even pull request process. So again, really getting to inthe guts about and getting a full understanding across the team and what we found is that by giving that ownership to the teams themselves, even though we can set up targets and directors at the management level but the teams only that and saying to them from conception through to production you own it, you build it and you support it. What we found is that teams are much more likely to come forward with here's how we want to really sort of work together. Here's the bar that we're selling for ourselves and that's been really important in sort of instilling that sense of ownership and getting the type of behaviors that we want to see within the team.
So as they talk about things such as we mentioned, as 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 that we'll see other team members sort of aligned to that and other teams actually respond to that as well. A few months ago, there was a series of podcasts that was done by news talk and they featured Stuart Lancaster for those that don't know, Stuart Lancaster is the former English rugby union coach. He's now a member of the Leinster rugby coaching team but he's very passionate about the areas of leadership and each week they had different topics. There was one week they were talking about team, dynamics and performance and the use of performance psychologists but one of the things that stuck with me was that when they talked about the different research, what they found is when they pulled it together is that 70% of a person's behavior is influenced by the environment that they're in at that time.
And I think that really speaks to us, trying to set up the right conditions for our teams being aware of what's going on and then the teams themselves looking build response to that, so getting the right conditions in place. So all of this, what we're looking to do is engineering teams being seen as really effective partners for our product teams, so building that trust being a trusted partner in the work that we're taking on. So the work that's happened over the last couple of years, I think what we're seeing is some of that sort of counter fruition in terms of the sort of partnership between ourselves and the product team. So a couple of recent examples we're going through with Ed actually a major redesign of one of the key functions and we're at sort of at that sort of early ideation stage around the design but what was, again that one of these small things that happened was that 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 but coming back from that, what struck me was the engineers was the enthusiasm around what was being done that identified some kind of short term wins for what we call our back to school period for September of this year and also longer term but very much sort of buying into what was being done, that commitment was there and that engagement was happening. I think it just speaks to the timing of when that conversation happened and the timing of that invite helped infuse the team there with that clear sense of direction. Another area we're fortunate in, in Dublin is that we have a number of our product owners sitting with the development teams in Dublin 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. It was a workshop across multiple different areas. But one of the areas that we were very conscious of folk focusing on was about how we get the balance right between new feature developments. So on technical debt and maintenance, on a new platform I get, there's obviously a huge push to get new features on whether it's from try and gain party with the competition or indeed trying to create some sort of differentiation. So what we said, "Look, that's great. We want to do that but we also want to make sure is that we're not ignoring where we need to be focused around the technical debt maintenance but we didn't want it to be a conversation where we're just making a rule. It's 30% capacity we'll do it of what we need to from technical debt."
We wanted to be a joint decision where we as an engineering function can articulate the value of why the purpose of it is and that the product team understands that and is bought into that. So that it's very much, again, a joint decision or a conversation around how we're moving it forward. So coming out of that for typically what we do in our three-month release planning cycle, we'll have the different lines of business feeding in their prioritized requirements. Now, all we have is engineering is another line of business in which initiatives like I mentioned, platform maturity that can be cross cutting across teams, et cetera, will now be part of that prioritization exercise. I think that's been, again, just speaking to the work that's been done but also just establishing a really good relationship with our product team.
And a lot of that I think can come down to the next item which is around that communication part of it and communication being the key, being open and transparent around what we're doing and why we're doing it. So it's six monthly project review meetings and this was an open invitation to anybody in the company whether executives and sales function, wherever they might be to come along and hear what's happening within the engineering function. So we spend typically a Thursday afternoon and we start and we work 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, what's not and what's interesting is that even though initially there was some reluctance into that. It was seen as maybe a little bit of oversight and how is this going to, we're going to be kind of scrutinised around this but what's come out of it is actually more as with credit for the engineering organisation about you're laying all 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. So even though it's a lot of work every month to stand up and get all of this prepared, what we're seeing is that I suppose feedback from other sections within the company that again looking to build that partnership and that trust element with the other stakeholders that we're working with. So I think in terms of then bringing this all back together, again, so 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 a wired magazine and it featured an individual called Bob Taylor, who had to be honest. I hadn't heard of but the headline was Bob Taylor something along the lines of the tech legend you've never heard of but who has invented almost everything. And what was interesting about Bob Taylor was that he was at the forefront of some of the suppose the things that underpin a lot of modern computing today. He worked on ARPANET. He worked in Xerox park and was involved in all of these initiatives but his key passion was around bringing together the best and the brightest and then getting them together to work as a team because he really felt that what could be achieved as a team far surpassed that if even the best individual and harnessing that energy within the team dynamic was of critical importance to him. He had a motto, which I think was an old Japanese proverb, which used to say in his office was, "None of us is as smart as all of us."
And 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 because for us I suppose in HMH, the work that we're doing around that thing of the openness and the transparency, the communication side of it, building that trust and standing up the teams, getting them focused, getting a clear sense of direction. Everything that we do on the day to day, week on week, month on month is intended to put in place the foundations that'll allow a strong team culture to thrive and ultimately achieve the kind of great outcomes that the company is looking for. But I think most importantly also achieve the great outcomes that most of our students are looking for as well. Thank you for listening.
Host
So has anyone a question?
Question
Thank you so much. I just have a question about your recruitment process because most companies [try] to get alignment from the candidates to those values.
Answer
Let's just say that's an internal one. So the reason I wanted to share it was something that the teams have put together around how they view, how we operate day to day and what we're striving for. So it was, it wasn't something that I'd put out on, maybe a customer facing it is a little bit dousing. So that's why I was conscious of it but I felt it was genuine in terms of how they see the operation, how they operate day to day, not necessarily something that we would use from a marketing point of view, it would need to be slimmed down a little.
Question
I just have one question about how you sort of measure the success of all the things you're doing to improve culture. Are there specific metrics you're looking at: happiness, productivity? What is the sort of thing you're looking at?
Answer
Yeah, so there is a combination of things. Unfortunately, the other isn't just that one KPI that you can kind of go to all the time. So there are things that even this morning, I just got an employee engagement survey, a follow up to one that was actually done and a number of months back and one we did. So there was a major one that was done, I think, around August of last year and coming out of that, there was a number of different actions but the follow on from that was a shortened one but actually with each department now being able to put in specific questions around their function. So from an engineering point of view, I think there were nine questions in total, three of which were now engineering specific. So what we were looking for there was, well, let's 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 one at the sort of the company level and at the engineering level, what we're doing with each team on a quarterly basis is sort of that touch point where they fill out a sort of their are adherence to agile practices. How they feel about how they're working, whether they feel the autonomy that they need is there and all of that. So we're using that as a sort of guidance to say, well, some teams may be performing quite well but due to certain circumstances we were seeing maybe that tail off a little bit. So it's a nice sort of way of just getting some insight into what's happening but not just doing it on yearly biases but doing it every quarter and sort of like that heartbeat check with the teams, so there are other things that we do as well, obviously, as you can appreciate from a metrics point of view in terms of our development side but in terms of just trying to get in inside the head of our engineers basically, that's sort of what we're found to be most effective.
Question
Hi, there, just curious how to integrate user testing into the design development process.
Answer
So the user testing actually, there are a couple of things that we do there. So we actually run a series of field tests that we do. So when you look at the educational market, it's interesting that the people who actually buy our software aren't necessarily the people that use it. So you end up with the district administrators making purchasing decisions on behalf of the teachers and then obviously you've got the students who use it as well. You can appreciate if you've got kindergarten at 12 years of age, trying to customies your UI to manage for that age range is actually quite challenging and 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. So what we're looking at, we do a number of field tests where from a teacher's point of view is, we have our teacher flows and the various functions, I may have it from the student's side.
And we go in, we get a sample panel, we go through it, we video record all of that and from that there are questionnaires. That then feeds back into sort of the nature of the changes that we want to see. So part of what we're trying to do with the revamp on one of the major areas around discovering content is, again, listening to that feedback from those field tests, understanding where are those pain points and what can we address quickly ahead or back to school and what are the long term needs that we need to take on.
Host
Thank you so much. That was great. Thank you.