The Guardian is globally renowned for its coverage of politics, the environment, science, social justice, sport and culture. Given the grand size and demands on the Guardian’s technical systems, how do they keep up with the demands of its journalism staff, cater for the needs of its millions of viewers, and deliver seamless integrations for its ad and subscription-based business model?
In this live lunchtime #TechTalk, we’re speaking with our special guest, Mariot Chauvin, Director of Engineering. In his role, Mariot looks after approximately 140 software developers that work in 26 cross-functional teams, who are responsible for a large estate, ranging from the Guardian mobile apps and website to the editorial tools suite and all supporting platforms.
You can watch the techtalk and read the full transcript below, or read our highlights summary article: How to run digital engineering in a large organisation.
Watch the techtalk
Read the transcript
Zoe: Hello everyone. Welcome to the official start of the webinar. As Meena said, if you missed it, I’m Zoe Cunningham, I’m the director at Softwire, and I’m the host of our Digital Lighthouse podcast where I talk to tech leaders about their challenges and leadership tips and all that kind of exciting stuff. Today, we have a Live Tech Talk event, which is being recorded and will be sent to all attendees later this week. Of course, before the end, we’ll also be running a Q&A. Do submit your questions into the Q&A box below.
What we’ll do is we’ll get to as many as we can. The earlier you ask a question, I always say this, the earlier you ask a question, the more chance we have to come to it because it’s normal that people tend to think of questions right at the end and think, “Oh, I want to know that.” If you have a question, please do send it in as soon as possible. Without further ado, I am delighted to introduce our special guest Mariot Chauvin, who is the Director of Engineering at Guardian News Media.
In the previous role, Mariot worked at Zengularity in Paris on designing and building highly scalable information systems, at Obeo on complex systems modelling and at IBM Zurich Research Laboratory on the creation of a messaging protocol for wireless sensor networks. I’m sure everyone in the audience has heard of Guardian News Media. It’s globally renowned for its coverage of politics, the environment, science, social justice, sports, and culture. Its journalists deliver agenda-setting, investigations, breaking live news, compelling opinion writing, and the liveliest features.
It’s also well known for its award-winning podcast, video documentaries and infographics and visuals. Given the grand size and demands of the Guardian’s technical systems, how do they keep up with the demands of its journalistic staff, cater for the needs of millions of viewers, and deliver seamless integrations for the subscription-based business model? That’s what we’ll be finding out today. [laughs] Welcome Mariot. Thanks so much for coming on.
Mariot: Hi everyone. Thank you, Zoe, for the opportunity to talk. I’m looking forward to questions and trying to share an overview of how we work at the Guardian and the kind of challenges we have.
Zoe: Amazing, thank you so much. Well, as Meena teased a little bit earlier, Mariot looks after roughly 140 software developers that work in 26 cross-functional teams and are responsible for a large estate of technology ranging from the Guardian mobile apps and the public-facing website to the editorial tool suite and all of the supporting platforms for the journalists. Question one, how do you manage so many multidisciplinary teams that all sit within your remit?
Mariot: I think first I would like to say that it’s a collaborative effort, it’s not only one person, very talented colleagues within my SLT that look at projects, viewings and as well from mastering or project management, but as well a very talented engineering management team which we share ideas, and we discuss it first a collaborative effort. I’m trying to lead them but it’s a collaborative effort. I think we have noticed across the years that the best way for a team to be successful is for them to be small and autonomous.
There is a conscious choice from us to just not have big teams with a large remit, but rather have a small team, very multidisciplinary because we have noticed year after year, that the smallest ones with the smaller remit were the ones that were able to be more performance and when I say more performance, achieve more at the end for the business. It’s not always easy because there is a lot of decision and collaboration needed between teams. We have quite of process in a way to deal with that.
One example is one meeting we have weekly which is called Blocker Independency where we discuss everyone, at least one person from each team is joining that meeting and this is where we share for instance. Blocker where there are dependencies between teams is a very agile way to try, rather than trying to figure out all of the dependencies from all of those teams in advance which we try a bit but we as well conscious that new blockers and dependencies will arise and we try to manage them as they come and trying to find the right– Where there is considerable effort into planning and into thinking about a quarter ahead or year ahead.
There is as well, a lot of correction and adjustment within a quarter to ensure that actually, every team can deliver and achieve, even if we aim to be autonomous in practice, there is always dependencies and blocker. Another thing I think is important for me to say is we have grown significantly in the last year and before we scale, we knew there were going to be challenges in terms of the number of teams. It’s not the same to have 26 teams as it is to have 15 teams. Every time you grow, there is a new problem coming very similar to a software developer perspective, there is always a new bottleneck every time.
You scale your software you discover that there are new problems. One thing we decided to do was to invest in what we call a Developer Experience Team, which is a team that is not immediately linked to a business objective as is but is more linked to the objectives of the department and which are in support really of the software development team. We have now four of them and they’re looking up everything that is quite common. For instance, deployment, for instance, operations, logging, and tooling. We use that by scaling to a very large number of more, at least a larger team we will need better standardization, best practices, and a way to encode them.
The objective of those teams is to provide guidance and support through providing what we call the paid world which is an analogy from Netflix, which is providing a lot of by default services and helpful services and libraries. That can be adopted by the team to encourage more standardization across the team, but enable enough flexibility for teams to sometimes not adopt a particular practice or not adopt a particular technology when they have a good reason for not following them. As I mentioned, it’s not easy or simple there is a lot for many people to try to do that and it’s a constant thinking about how we are best doing things.
How much work to be done within a team or how much work actually should be solved by another team? Where it’s helpful to put it as a standard. That’s just where some things can change and we have another really good discussion within teams and with the developer as well around well, the right to, what do you expect for you to be provided? That is what you would like to be involved in, notably around infrastructures. One of the first principles we had many, many years ago as a way of operating was to say, software and hardware are intimately linked when they are running infrastructures.
Therefore, a team is responsible for its software and infrastructure and we want to encourage the team to be responsible for it. Managing infrastructure and managing software is not always the same skill set and we need to grow the amount of skill set. We have done a large amount of work recently on trying to provide a better template or add another template. That’s what you can do directly on the value adds to help the team. Adding towards that immense cognitive law about having a very, very rich skill set and domain knowledge, which obviously can be quite difficult when you need to think about absolutely everything in your external.
Zoe: This is fantastic because I feel as a host, I am almost not needed but as you keep talking, you keep highlighting all of these tradeoffs, because I think a lot of these decisions are tradeoffs. It’s not about talking about the size of your teams and obviously, 26 teams across 140 people. That’s quite a large– You’ve decided to have small teams. Then the challenges, great, you’ve got these really small, close-knit teams but how do you communicate between teams because now, there are a large number of people who are not in your team?
Then when you’re talking about the developer experience function, which sounds again like a fantastic way of making sure that developers are working as fast as they can or producing code, delivering as fast as they can, which I know is a topic that comes up all the time. There’s that aspect to it but there’s also this aspect of being autonomous as a team and making your own decision versus standardization is everyone working on the same platform, and using the same tools and does everything interoperate properly? How much do you think of your setup as tradeoffs and how much is this pretty straightforward, we need to do this.
Mariot: I think, you’re so right in the sense of it’s a lot of tradeoffs and as we have grown, we have made a conscious decision to have most on the organization but more easily at a lower scale but a very large diversity within your team. The more you grow, the more you need enough standardization across some common blocks. I will share examples around IWI because that’s a great example. When we had a smaller team, we were encouraging people to write their cloud formation themselves because they were in control.
The moment you grow the number of teams that kind of each transformation bit becomes the talent or liability because when you need to update 26 of them, and I simplify but when you need to modify multiple repositories, many of them have become complex. This is where you have the power of extraction. Can you extract enough? I think that it resonates with one of the rules about when you need to extract and/or not repeat yourself on your right function. Something your developer sometimes is very keen to address it. “Oh, I’m just going to generalize my function” and most senior developers come and say, “No, no, no wait. Copy-paste at least two or three times before it’s tried before he starts extracting and refactoring and making this generate.”
I think we can apply this line of thinking here, which is to say, at the beginning you may not need every law of common standby solution depending on the size, and the more you grow the more you feel you need someone to come and choose between your team. What is the right number… I will say that at the Guardian we have seen the benefit of how some of the central tooling can help teams to be much more efficient in doing their jobs in terms of delivering value to the organization because from early on, 10 years ago, I think we started developing our deployment tool which has been a massive success story which is linked to the quality of the tool and the quality of the developers at work on that tool is still in use.
We have seen how a common deployment tool used by all the teams helps massively in terms of doing your job because you don’t need to worry about it. You know the tool you are going to use. When you switch teams, which is another thing we do in terms of collaboration, in terms of knowledge practice or knowledge sharing practice having the common tools for doing all of your deployment is massively helpful rather than everything having to reinvent the wheel and just how we are going to manage deployment.
Zoe: Yes, exactly. You don’t want to be constantly doing the same thing over and over again or spending your time constantly learning how to use new systems when you are all in the same team working on the same platform.
Mariot: I was mentioning conscious decision is something we’ve discussed a lot with Tim, I would say a year and a half ago about what should be your technology strategy and what are the main issues or challenge you to see as more experienced developers within the organization. What do you see? A lot of developers came back to us and said, “Well, there are just too many choices to be made.” Some people are using pNPm, some people are using Yarn, and some people are using npm.
A lot of developers were asking for a more standardized solution. I just gave the example of the client-side package manager. You can generalize this for a lot of other things and again, at which point do you just give everyone the same tool? I don’t think this is the right solution. It’s all about locking the right tradeoff and having that. I think I’ve heard about this expression like breaking glass capability where you have an emergency and you want to break glass to take something different. You might want to go with the standard approach of doing things. Sometimes, for various reasons, you may want to not follow this conventional role or this standard role, and you break the glass and say, “Well, in my project, or this particular case, I want to use a specific tool which I think is better fit for purpose.” That autonomy or ability to have flexibility, I think keeps us successful. Any approach which is too dogmatic and just says there is only one tool and this is the tool across as many of the teams can’t be successful in my mind.
Zoe: Yes, I think that’s a nice analogy because it’s showing that balance between standardization and flexibility and I think it’s quite a good example or quite a good way of communicating the level you have to reach. It’s not everyone uses whatever tool they want all the time and it’s a free for all. It’s in exceptional circumstances when there is sufficient need. That’s the time to do something differently. Okay, great. Let me just move on to my second question.
The Guardian has a reputation for strong digital technical capability and that requires hiring the best people. How does The Guardian as an organization attract talented needs when there is such a scarcity in the industry? The flip side of that as well is how do you retain people once you get them?
Mariot: That’s a great question. I’m sure many, many organizations-
Zoe: I’ll be taking notes, we all want the answer to this question.
Mariot: I will say first, as an independent news organization, this is probably one of the main challenges which is how do we attract the brightest people to work for something that’s a purpose from the community and not for those people to just join, companies are paying the most. In the past, that’s been a tech company and I would say stem from NHS or HMS. How all of those things which are more not for profit but more for community, may be attractive or attract the best talent and the brightest talent and it’s really to challenge as an organization.
One key thing for me as a role is making sure I can attract the right people and allow them to understand that they can build another successful career and an incredibly good challenge to solve. I think the first things, which is the purpose, where there’s a company or where there’s a– the staff is like, we have a purpose or value are more than 100 years old. They were set out by C. P Scott in 1921. I know values I think are the first thing that’s helping us because people know why they join The Guardian. Usually, they have a very good idea about what we stand for, and this is good.
I think I’ve mentioned other companies, but I think it should be true in most companies need a purpose and we– people should join first because we believe in the purpose of the company. There is another reason, for instance, salaries and others, but I think first it really should be the purpose of companies that attract people. It’s not the only thing we are doing to try to attract great talent and retain them.
Something which is linked to our purpose is that we have this principle of working in the open. It means we encourage people to contribute to open source, for instance, but it goes just beyond that. For instance, we create our GitHub repository public by default. We want to encourage people to work in the open, which is linked to transparency because actually, a lot of people are supporting The Guardian financially.
It’s quite good for us to be able to say, “Look, this is what we are doing. It’s not secret, this is how we operate.” It’s good as well because it encourages people to think about their collaboration and their way of thinking in a way like, “Look, your work is public and your collaboration you will have, which is public,” which is a good reflection for people to think about, “Okay, actually, the way I’m going to do it, it’s going to be public, so doing something a bit about of sketch actually shouldn’t be doing it.” It’s helpful as a reflection.
From a very operational perspective, it’s a really interesting property for security, for instance, because it forced people to separate its secrets of private information from where electronics can be public and infrastructure. It’s forcing developers and others to think about the operation of content. There are secrets. They should not be stored in my repository. There should be injected. Otherwise, private repository by default. It’s not encouraging, but it may be hiding that problem where it’s forcing us to integrate.
There is another really interesting aspect of working in the open, which I think is great, is like first, you can show your work to other people, other colleagues or friends or people. It’s great to be able to share, especially in the world specific for software engineering where there are so many open-source, public repository examples. It’s great to show other people how things are done and how things can be done.
It’s great as well when people left The Guardian to be able to say, “This is what I’ve done. This is public, you can see it, you can see.” I think it has a lot of benefits for this and I think it’s really helpful for people that are interested to join The Guardian to be able to look, “Oh yes, I see where they’ll do it. I can see how people interact,” and it removes a barrier or friction for people to discover The Guardian.
Zoe: I think it’s really interesting how it ties back to the purpose of the organization as well, but it’s actually about connection to the community and accountability to the wider community. I think that’s also quite a neat aspect of that.
Mariot: Beyond just putting source code, why we have put our performance framework and pay bands which are available on GitHub and people can search for it at some point? Again, that transparency is really good for us when people are, “Oh, maybe I will be looking at The Guardian.” You can find this information and you can see by yourself, which is removing a barrier or friction. I don’t know.
Is this organization for you? Are they paying enough? Why is that to be why I’m going to be assessed? Well, we put all of that information so people can discover by themselves, which is interesting because it helps us as well on onboarding because people have already seen this information and it’s public and it’s the same information. When they’re onboard, there is something less to discover. They already know and they can come back and-
Zoe: It helps them to decide if you are right for them in advance. Yes.
Mariot: They can see. We’ve put something linked to that, which is the culture. I mentioned purpose, but the culture is really important for people before they choose the company and join. It’s like, “Oh, what is the working practice? Where is culture?” So we have put our engineering culture on GitHub as well. It’s available. It’s been contributed by many people and we encourage our current employees to update it if they think they have an idea, and we put it again in GitHub in the sense you can– external people can see it. You can see how it is, and I think it’s crystallized that, “Okay, before I join, I understand how this company operates. I can see it and I can decide if is it for me or not.”
When you join, after you join, if you see behaviour or if you see something not happening in the way it’s presented in the culture, you can refer to it. You can call out or even mention if you say, “Well, I saw that a colleague was doing this. Why are we not practising it?” I think it’s a great tool for yielding or materializing the purpose and providing an opportunity, which is great, and just want to just my two lines. I think our culture is highly collaborative, but it’s as well really encouraging people to grow and progress, and I think these are the two aspects which have been for us important in retaining people, which is we know we are not having the highest salary on the market and we know we’ll probably never be able to afford because the money, the people, the support we want to give is first, we’re not a for-profit organization, so we have to follow the market, but we can’t operate above the band, so it’s really good to offer something else and something different to the people than just salary package.
So we really encourage growth and by means, growth is not only a progression within the career, but as well knowledge, skill set, and also, just two examples of things we do around this, which is interesting. The first one is we have our schools, which are run by directly some of the developers. One of them has been running for a long time and is a… just opening… school, and this is run by an individual and by most senior developers or people with that skill set, which is a great opportunity for people to grow like your first ability to mentor others and to train others, which is again a good skill.
The more senior you become, the more it’s about sharing your knowledge and teaching how to do things. It shows that you are an expert in some difficult concepts more than junior people or people that are new to that specific knowledge. The certain things we do, it’s 10% time, and 10% time is very different from the 20% time famous from Google.
There is 10% of the time, so one day every two weeks where we want people to spend time learning. You can work with new technology, you can start to contribute to a request, fix a bug, or learn a new language. It’s your time as an individual and it’s not linked to being productive or not being productive directly. You don’t have to spend time on the new project. It’s not for building a new project. It’s really for, as an individual, there are some technologies that I’m interested in or something that I’m interested in.
Zoe: It’s to develop yourself as an individual. And to develop your skill set.
Mariot: And do not go quick. Most of the time it’s about delivering value and we encourage people to go far, 10% time is the contrary. Go down the rabbit hole, find exactly why something is not working as expected, or find why something is working in a way and take that time to learn something that otherwise you will never have the time to learn.
I think incredibly important in the technology world where, how many new technologies there are and how many new releases there are of software. It’s a constant. There is a fear of missing out. I think for a lot of developers it’s just like well, in two years all of the technologies I’ve previously learned how I’m going to still be relevant, so providing that opportunity for people to be able to continuously learn and spending time about their new interest is I think one thing that is good for them to be able to retain them.
The last thing I wanted to mention on this is rotation. We encourage people to move between teams. I’ve mentioned we have many teams, but we make an effort on encouraging people to move teams across The Guardian, which is first a great way for them to evolve after one year in years, you may want to ask, “Okay, I’ve looked at all the stuff. I want a new challenge.” That’s a great way for people to have a new challenge and stuff.
It has a lot of other values. One of them is knowledge sharing, because when you do that you constantly have to say, “Oh, how are we going to share knowledge?” When you have a team, which remains the same for a long period, naturally people will just know their head so it’s good for them to see where a new starter can’t understand, because I’ve been talking about the same thing. When there is always a bit of movement in the team, it’s positive to say, “Okay, how are we going to introduce someone new?”
Now we have been keeping all documentation and stuff, so this has the value of encouraging knowledge sharing as well as adding value about standardization because when you’re working in a team, you can come with all of your existing knowledge and baggage and apply them to another team. We found this as a really interesting tool for keeping people motivated, aligning around standardization and guidelines and stuff and ensuring we have really good knowledge sharing between teams and others.
Zoe: I think those are always the best policies, aren’t they? When they’re solving several of your challenges at once. Not just that they’re win-win, they’re win-win-win-win because they’re helping in all kinds of different ways. I’ve got a lot more questions to ask you, however, we started getting questions in from the audience and I want to prioritize making sure that I’m asking you the things that people want to hear. Our first question from Priyanka, and this is very relevant to what we were just discussing. How fluids are the roles?
We’re talking about switching between engineering teams but within engineering and engineering roles maybe product roles and development roles and design roles or even as Priyanka says between tech engineering and even journalism, writing and editing. How fluid are those roles or is everyone– do they stay very much within their function?
Mariot: I think there is a different level of fluidity within engineering. There is a lot of fluidity placebo because in general, there are much more open roles. After all, the market has been very open. There have been a lot of people changing in general so there are constant opportunities for people to start. We have several people that move from full-stack developers to become iOS developers or native developers.
On the contrary, we have had people that have been full-stack developers become security developers. We have got quite a range. Now, within all departments where there is all that function, there is as well a bit of fluidity but it’s not as easy because the skillset is much more different. We have seen why those people that are moving between project engineering and usually where we do this is around secondment, right? There is a secondment, which is open and people have the opportunity to try, but especially when people have already a more senior role technically, it’s not always easy to accept to become a more junior role in another function.
It’s necessary to learn new things. It’s existing but far less frequently than it would be within engineering, where being a software developer, there is some specific skillset, but most of the job is very similar and you can change technology quite easily. The last level of fluidity I would say, will be within the department, but you want to work in the editorial department. I will say this is much more difficult and there is some good reason for it. If you want to become a journalist for The Guardian, it’s incredibly difficult because that’s why I’m not hiring a lot of people but when we’re hiring someone, competition, we will have many, many, many, many other candidates.
It’s not impossible, but you have to accept that you’ll be not in a privileged position against external candidates I would like to apply for a position. Of course, you may have internal knowledge and organizational knowledge that may give you a bit of an edge on some aspects, but the competition here would be incredibly hard because The Guardian is very, very looked at from an editorial perspective.
You will see many, many, many, many people candidating with incredible skills. If you have writing skills as a software developer, they may not immediately translate it as a skill set as a journalist. It’s not easy, it’s not impossible either but you have to be conscious that it would be easy. You will not be fundamentally at an advantage being a software developer at The Guardian to become a-
Zoe: Yes, I think that makes sense. It reminds me of another question. Given that The Guardian is a news organization, how much technical expertise makes it to the very top of the company? Are you likely to ever see a CEO who’s come up from the tech side or is it always the news side has priority in terms of decision making?
Mariot: No, I think it’s interesting. I think The Guardian is a very collaborative place which means there is a large amount of interaction between people in different departments around decision-making. I think you will see people directly collaborating with people in an editorial on that project and directly discussing it. I think the huge difference is that because people are caring about the content, there will always be a lot of debate around something and it will go much deeper than just the commercial interest or the benefit of the organization.
A large number of times we will discuss technology around our purpose and how much they align or misalign with our purpose. This makes this place interesting and really, a lot of people when they left, they just say, “Well, never seen a place where people are so passionate about a role on our mission.” It means sometimes decisions take a long time because people want to explore all of the aspects of something. It’s incredibly, I think, interesting because you have the opportunity to hear other people’s perspectives.
It’s not just about technology, it’s what is the impact of society, what is the reason why you’re doing this. I think at the higher level people understand the technology and technology impact but they were always going to discuss the challenge, what does it mean, and what is it in terms of our impact on the world? What does it mean? Why are we doing this? They will always question in a good way, question, “Why are we doing this? What does it mean?” There is very, as well I think really good quality from people working in news organizations they’re very curious so they ask questions.
The first thing a journalist or someone in an Editorial will do is they will ask questions to know more about something because they want to hear it, they want to understand from people that know what does that mean and why are saying this? What does that word mean and how that works? People are incredibly interested in the technical aspects of how things work and why we make some of the decisions.
Zoe: Yes and that’s a nice answer to hear to refer back to Priyanka’s question. That maybe you will work within your function. If you’re within technology, you will work within technology but your impact and interaction within the wider organization will be broader. You are still part of the whole team.
Mariot: Absolutely. We have seen that collaboration well several times. What I think it’s really interesting is that your different typical type of profile, someone that works in the editorial site, in a news organization, usually has spent quite a lot of years, and there are rarely quite a lot of new people. A lot of people have been working in the organization for quite a long time and only this is because I’ve been seeing the evolution of technology over the years. They have a very good reflection on how journalists can be used or cannot be used.
While people that join The Guardian on the technology side usually have far fewer years of experience as journalists. They may have a career somewhere else and they switch vertical much more easily in their career. They will have fresh ideas and excellent knowledge about technical and technology. You get this combination of two different types of profiles, someone that’s been in the news organization for a long time and it’s all about the Guardian and the evolution of tech.
You get someone that has been working in different verticals and much new to the organization with a lot of knowledge and a key I think for projects in general, a project to be successful, you need to have these two people who are well working together and building that sense of trust and estimate each other for their skillsets. People are realizing, “Oh there is a reason why we have not done this,” because someone on the other side has been thinking hard about this for many years.
On the other side, someone on the editorial side is like, “Actually, technology may enable us to do this a bit differently now,” which is interesting and what we have seen in many teams. When you have that trusting relationship where people are not afraid of sharing. Sometimes crazy indeed. Trust, and interestingly interpersonal relationships is a really good predictor of success. The more people have the right relationship with each other, the more likely we have to see teams be successful.
Zoe: It’s the only way you can do it because it’s another one of these tradeoffs, where of course there is expertise and there is the expertise that’s built up over a long time, but there’s also new ideas. New ideas are almost a challenge to expertise, right? It’s because sometimes there will be a new– Sometimes you need to know how to do it. After all, you’ve done it already and it’s working out which of those applies is what the challenge is.
We’ve got some questions from Anna here. Maybe I will ask you all of Anna’s questions together and then hopefully we can tie it all together. Anna’s first question is, you spoke about the technical challenges of the recent growth in developers. What are the lessons you learned about people and organizational aspects in onboarding a lot of developers? Then she asks, what is your vision prediction for the next five years for Guardian Engineering? Finally, what have you been most excited about the past year and what are you looking forward to? We might have to do one at a time or try and combine them.
Mariot: I would say onboarding. I think onboarding is hard definitely. We knew before but always make it more concrete on both and quite a lot of people say it’s really hard. We talk about tradeoffs. One of the big tradeoffs is how much we make it discoverable for people about past experiments, past work, and past reasons. If you need an architectural decision record, that’s great, but when you are such a big organization, how do you find that?
What did you find, what was made and what were the assumptions being made at that time? It’s hard to be able to share as much knowledge that is existing. At the same time, the tradeoff is as well letting people make their tests and make their own mistakes because there is no better way to learn than by doing some of the structure yourself and finding problems and every great senior lead staff developer is someone that made mistakes in their career.
Learn by doing and take lessons from your mistakes. It’s not just about, “Oh we giving you everything else, all of the answers, and here is– you apply new ID. There is that balance between sharing as much information as we can, so it’s helpful for people but letting people as well rediscover and discover again some of those lessons. Just because they need it for their own growth and personal career development. It’s the same for every role, it’s not just technical, it’s the same in management. You have to do management to become a board manager and it will mean you are going to make mistakes.
You can read as many books as you want on management, but until you practice it and you make some of the mistakes yourself, you’re not going to become a most senior manager.
Zoe: Absolutely. What have you been most excited about in the past year and what are you looking forward to, and what’s your vision prediction for the next five years?
Mariot: It’s really interesting. There’s quite a lot of subject. I think there is a very loud subject, which is around the authenticity of the news and as you know, many of you have tracked the development of large language models and AI is really from a technology perspective, incredibly exciting and incredibly scary. There will be new newsagent stuff but I think it’s for digital journalists asking a large question about where the role of a news organization and how people will consider authenticity and veracity.
We have a large number of people thinking about, not only technologies, but thinking about why if we were having an image illustration that is generated while it’s unwritten, and what it– It’s not only about obviously, the time to produce it, it’s about the impact it has on the readers. Why does the reader assume if the content is generated rather than un-crafted and how much do they change their position around the amount of content we are producing?
We have a lot of people in the department currently thinking about that. I’m not sure it’s guidance, it’s more like, “This is how we want to operate within digital journalists,” and what digital journalists mean in the context of those existing technologies. Where are your use case where those technologies can be useful as in this organization, versus where they’re going to be harmful by themselves?
I think it’s incredibly exciting for us to see how some of that technology can be useful and help us produce greater journalists, quicker journalists, and better journalists. An example, very good example is been our investigation, we have been investing recently a lot in our investigation tools, and we are providing models for helping journalists to discover facts.
We’ve been spending a really large amount of people and resources to try to help in digital investigation.
For sure, some of those tools and technology in general around AI and large language models and machine learning and all, can be incredibly helpful. A large number of documents with a large number of senses connecting the dots and helping someone to produce great content for journalists. But there is that aspect to trust and to truth in general, which is going to be interesting, and how much people are going to trust something quite frequently– If you look at ChatGPT, it can provide really good answers, but there could be mistakes in them.
Zoe: Right, they’re not necessarily true. [laughs]
Mariot: They’re not true, they could be great content and great response, but there are going to be mistakes and stuff. As an audience, how people are going to trust or not those tools and how much we should have an audience. I’m just using an example, I’m not sure it’s the answer, but we should expect people to come to news organizations. If I want really to trust the source of information, I need to go to a news organization.
I should not be using directly a reference or I use ChatGPT, but there is Bard. I think the new Bard is for Google and Bing is for Microsoft. There is a large number of technology-breaking tools that are going to disrupt obvious the model of information.
I know on our side is really as a news organization thinking– it’s less about– well the immediate use case, but what is the right front for us to be able to explore these technologies and helpfully use them. Not only for us but for society. It’s very similar to some of the conversations we have had in the past around attention time, and as you want to know our Facebook and Instagram, I’ve been encouraging people to use a lot of attention time and become having– sorry, having users becoming addicted to using their app.
Of course, we always want our journalists to be real and understood by people, but as a news organization, our goal is not for people to be addicted to that app. That gets something we discuss and try to find what is the right front for us. When we think about metrics and when we think about what we want our readers to be able to do with the apps, how they use the apps– and the choice of metrics, the choice of the things we decide are affecting the society, not only The Guardian by itself.
Zoe: Yes, so we live in exciting times right now, don’t we? There have been big changes and more to come.
Mariot: Yes.
Zoe: Great. We’ve got another question from Andrew Speakman. On the topic of moving within engineering, what do you do to make this easier? Do you have documentation or process standards to help the new team members get up to speed more quickly? I guess it’s like the onboarding– it’s another onboarding question, but the onboarding within the team, what do you have?
Mariot: Yes, well we have this internal onboarding process, which is either a pack of documents, or it’s a Trello board which will tell you what to do. I think again, this is interesting in the debate about standardization and autonomy.
Here we have seen in the past that’s quite a lot. It’s good for teams to think themselves about it and what is useful for a team on board may not be the same as what is useful in other teams. We’d rather encourage the team to think about this within their remit. What do you do for making easier upon onboarding? There is a template, right? People are going to share templates. “Oh, we have seen this in that team, so can we borrow your template?” or example is the commercial desk team recently made a fantastic almost simple book about joining their team and others were very jealous.
“Oh, can you share the template you have made? Can we use it?” It’s more something where we’re expecting to collaborate. They have their version of onboarding. Yes, there is documentation. Frequently we have this concept of tickets or issues or bugs that can be a good start for things to start with. Very frequently, there is a bit of jargon buster. A lot of people are going to use new acronyms and new words you’ve not heard. You need to understand what they’re talking about.
Here, 50 acronyms are going to be used frequently in your team and that’s quite a common theme about specific jargon or specific terms that are very used in the team. If you just joined, you may not know about them. It may make things seems a bit cryptic until you understand all of it.
Zoe: Yes. I think that’s another good reference back to earlier about standardization versus autonomy. This is an area where it doesn’t need to be standardized. It needs to all be done very much with the end in mind and perhaps be constantly evolving anyway because the teams are constantly evolving. How you bring someone new into that team is going to be different if they join six months later or in a few years when things have moved on and there are new things that are a higher priority to learn. It’s more important to think about the objective and the ends rather than– there’s no point having documentation if it doesn’t do the job.
Mariot: Those are the things we frequently encourage new starters to say, a team is a composition of individuals. When someone fresh joins, some of the things the teams are going to change and it’s fine to acknowledge that the interaction you create there is going to be some change. When the team change, the way the teamwork is going to evolve. There are still things that remain, but we should encourage them to develop their way of thinking.
There is an example of the retro. We use sprint of two weeks and we do retro and we encourage him to say, discuss the problem, discuss the things you would like to change, not because the way you are doing something is working in the past that they’re going to work in the future. Feel free to adapt some of your processes to make it work within your team and discuss that together.
This is a team agency and team autonomy. You have the agency to make some changes in the way you work within your team. There is principle and there is stuff around inclusion that is important. You want to make people included and other principles but I think we use some commentary, I mentioned the block and dependencies meeting where we discuss block and dependency, but within the team, there are millions of things we do and interaction is not codified. Those, are now the ones where you wanted him to find what works for them and how they adapt constantly over time.
Zoe: Yes. Fantastic. Oh, this has been amazing. Thank you so much, Mariot. I enjoyed this chat. Thank you so much to everyone who asked your questions. They were very insightful questions. Mariot, I appreciate you sharing so candidly about the challenges and the tradeoffs and how you make things work to support such a great news organization as The Guardian. I’d like to remind everyone we have more events at Softwire Events, so please keep an eye on our online calendar. The talk will be recorded and sent out to all attendees. Yes, I hope to see you all soon.
Mariot: Thank you so much for a great time. It was great talking to you. I hope everyone enjoyed and had something to learn or enjoyable.
Zoe: Fantastic. Thank you.
