Transcript
Pauline Jepp: Rock climbing really seems like a solo act. That is, of course, until you fall, and then you realize it's all about the person that's on the other end of the rope. When I first started climbing, I thought it was a solo sport. You're the one, you're on the wall. It's a very physical puzzle that's in front of you. You're thinking about the angles of the holds, the forces, the way that you have to move. You're in the Zen moment. You're in your flow. Any climber will tell you that you don't get very far on your own. For a start, if you fall, someone's going to catch you. I don't know how familiar you all are with climbing. If you're on a rope, the person on the other end of the rope is called your belayer, and they will literally catch you when you fall.
They can quite literally save your life. If you have confidence in that person, it means that you are going to work harder, you're going to try things that you've never tried before. More than that, there's an entire community of people around about you that are willing to offer you some beta. Beta, not like software beta. I mean you are looking for some feedback to make things better, but it's those little tips, techniques, and tricks that they have learned that will help them get through the problems. Obviously, one person's beta doesn't work for everyone. We're all different heights. We have different reach. We have different strengths. We have different weaknesses, but sharing this information will help you deal with when you fall, because you will fall a lot.
There was one situation that happened very early in my climbing days, also in my early grad school days with Kaye, where I was quite new to climbing. I was inexperienced climbing something that was much harder for me than I could. My belayer was a much more experienced climber than I. I kept trying everything, and I just couldn't figure out the next move. Kept falling, she kept catching me. Just before frustration stepped in, she said, just move your feet first. It seems like a really small thing, and when I looked at the wall, I only had to move my feet like 2 inches, but those 2 inches gave me the reach I needed to grab the next hold. This has had quite a bit of an effect on me throughout my leadership journey, that balance between support and giving the beta at the right time, but also the right amount of beta. She didn't say to me, move your right foot and put it on the red hold. She just said, move your feet first, and that was enough to trigger my puzzle-solving brain to look at the things that were in front of me and to make that move.
I've had a really colorful journey to get here, not maybe one that's typical, but do any of us have a typical journey? The PhD in Canada, a research position in France for computer graphics. Went back to Scotland for a little while, did a lot of remote work. Then ultimately decided I wanted to learn another language and another culture, and ended up in the Netherlands. Throughout all of this, I've mostly chosen to work for smaller organizations. I like that the role definitions aren't necessarily clear. I like that it looks like you can just pick up a project that seems really interesting, that's going to be really impactful, and you're working on interesting engineering puzzles with your peers. It was interesting, the keynote about decisions, was this a decision or was this an accident? I'm not 100% sure. Working in smaller organizations, I think that it's not always about the engineering problem that you're going to solve, it's about the system around the system.
How do you make sure that the whole project is a success, and not necessarily just that the code passes all its tests? I didn't set out to lead at all. In fact, I think, like many engineers, I didn't think I had the social skills. I also didn't think that I had the capacity. I thought I was much better at speaking to a computer than I was at speaking to people. I want to challenge you, help you think about how your engineering brain, your pattern matching, your systems thinking, can look at the system around the system, the people that support the system, that in order to make the engineering project a success, the people have to be successful with it. I started working in a video game shop, that was the thing that started me on this journey. I think this talk is for anyone who feels maybe you're not on a traditional path, you're not climbing that traditional career ladder. Indeed, those of you that are, I'm sure we've all got some of the similar experiences and things to share.
Metaphors can get you a long way in a talk, I think. I'm going to talk a little bit about my PhD work in terms of swarms, because I think it's really interesting. Kaye and I, when we did our PhDs, multi-agent systems, I was looking particularly at swarming behaviors. I didn't think about it at the time, I thought it was an intellectual self-indulgence. I just thought it was cool. There have been a bunch of lessons that I learned from that, that make me think about how I want to design the engineering department, how I want to encourage the engineers. There are three rules when you look at flocking behaviors, and it's a careful weighting of between these three rules, separation, alignment, and cohesion. You get emergent behaviors like a flock of birds, a school of fish, a swarm of bees. Think about a murmuration of starling, that might be different than a flock of crows or something.
Separation, don't crash into each other. Alignment, all roughly going in the same direction. Cohesion, you want to stick together. Hopefully, you can see how this applies to an engineering department. Separation, we want to have autonomy with our engineers, we want them to know that we trust them, they can make these decisions. Alignment, we've got to think about where the whole department needs to go, like the company strategy. We're all pulling in the same direction. Cohesion is the shared knowledge, the engineering excellence, but also the psychological safety and the trust that you engender in your engineers. It's not about control, it's about designing, tweaking those little parameters you need to for emergent behaviors to happen.
TicketSwap - Sell and Buy Flow
I've got an interesting example, I think, that illustrates a lot of the things I want to talk about throughout the talk. It happened quite recently with TicketSwap. We used to have something that was a little bit like stream aligned teams from Team Topologies, where we had core user flows. One team would be responsible for each of the core user flows. We've got the sell flow team, looks after the sell flow. Clue is in the name. Buy flow team, looks after the buy flow. Clue is in the name. What happened was one year, so the sell flow team had really two high priority items in their backlog, they were going to be busy for the next quarter or two. It was in 2023 when ChatGPT got really good at looking at images and extracting information from images. We'd had a hackathon project. TicketSwap, we sell secondary tickets.
You buy a ticket, you don't want to go to a gig, you can sell it on our platform. Typical marketplace, C2C. It used to be the users would have to enter all the information about the event manually, and one of the hackathon projects was using ChatGPT's improved recognition from images to be able to extract the information, classify it all properly, and match it with an event in our database. It's a really exciting project, it's called the one-step sell flow, because a user wasn't going to have to do anything, we'd extract all of the information and then they just had to click confirm. The sell flow team had several high priority items in their backlog anyway. We looked across the business to see which other team could pick it up. It just so happened a buy flow team didn't have anything that was nearly as exciting and as interesting as this.
Of course, the sell flow team were really upset because it was a cool project, it was interesting and they wanted to do it. It would have been maybe three to six months before we were ready to pick that up. We knew then that we couldn't wait for AI projects, we had to just go with it. The whole thing was a lot of figuring out how to go from domain owners. I don't know if this had happened in all companies, because it's a small company and we just had one team for each of the core user flows. They owned everything about the user flow, which you want them to do. You want them to be responsible for the codes, for making sure that all the tests are passing. If there's a bug, they deal with it. They had a responsible attitude to the stewarding of the flows.
All of a sudden, we're saying to them, someone else is going to come and work in your domain, someone else is going to work on your code. Albeit that we trust the engineers, they have the seniority, the experience, but they're coming into your domain. It was a lot of negotiating, so it wasn't gatekeeping. It was sharing this information and how do we make it happen. We had a few challenges. We had a lot of conversations about teaching the engineers to share their knowledge, to be supporters, to be mentors, to do whatever they needed to do, to make sure that both of the teams were set up for success. A lot of that work was invisible work. I'll talk a bit more about invisible work as we go through. I'm happy to say that after we did this once, and it was a little bit painful, not only were all of these high priority projects successful, and incidentally, we do have something much more closer to a one-step sell flow now. Every time since then, when we've had a situation the same, the engineers are much more comfortable with this domain ownership, domain experience, and sharing their expertise across the different domains than they were before.
Tuning the System: From Project Resourcing to System Shaping
Separation is a lot about the team having the autonomy to be able to pick the project up, and be able to run with it. The alignment was us all knowing that these three projects were the three high priority projects that were ongoing. We're all pulling in the same direction. The cohesion is investing in the sharing of information and the whole context of the domain experience rather than domain ownership. The glaringly obvious flaw in my metaphor here is that in swarms, all of the individuals are self-similar, which is exactly the opposite from what we want in an engineering department. I think even from the early days of the labs, we had a situation where most of the students, it was a fourth-year introduction to computer graphics, a lot of math, a lot of linear algebra. We needed the students to have certain competencies before they come into the class.
One year, there were students that came in from a local college. They had equally qualified, but they had different teachers, different course materials, different coursework. When we brought them in to the conversations, it was super interesting. You could see even from those different educations and lived experience, it changed the group dynamics and it changed the conversations. That's like a microcosm of a little situation. In the same way that in the early days, it was like, don't build your team all with extroverts or don't build your team all with introverts, is we want to bring together people with different lived experiences and different ways of solving problems, to solve problems. This doesn't happen by accident. Throughout my career, I've seen the same thing happen again and again. I'm really happy to see that a lot of the research now is in the same vein, in that the more diversity you bake into the conversation, the more people you bring from different cultures and subcultures into a conversation, it's where innovation happens.
It's where interesting things happen. It doesn't happen by accident. I think even from the point of the job description that you have, for example, a really easy one is if it looks like it's a checklist, people from underrepresented communities won't apply unless they tick all 10 of the boxes. We have a little line that says it doesn't matter if you don't tick all the boxes, still apply. Right through the process of how you parse CVs or resumes, right through the hiring process and the working situation, I think you have to be very mindful about it. Apart from my distraction about they're not self-similar engineers, that's not what I want. I want autonomy, but not self-similarity.
A summary of that. The separation is what gives the teams the freedom to move. Alignment, making sure we're all going in the same direction. Cohesion is that psychological safety. The mentoring and the sharing of information is like a super important part, I think. For us, the tuning of the swarm. Making sure there's a nice balance of all these things for everybody to feel they're moving in the right direction.
Lessons from Perspective Shifts
In this example, there's a number of invisible tasks. I'll talk about the invisible tasks. I think when you're moving from an IC and more and more into leadership, like whether that's even being like a tech lead, a principal engineer, technical path or managerial path, it's a different perspective. When you're a junior IC, you're focused on your code yourself. As you get more experience, you're focused on your team. Then as you get more experience, you're focusing on how you interact with another team. Then it's all the teams across the department. Then it's all the departments in the business. With every step, it's a different perspective shift and different things for you to consider. I tried to think about a few of the lessons I've had from the different perspective shifts that I think might be interesting to share. One of those is the invisible work. As I mentioned in the example, us making sure that the engineers were sharing knowledge was invisible work.
The engineers themselves being mentors and sharing their knowledge was invisible work. How do you make that visible in that it's not something that gets lost? There's no Jira card for reduced tension. No graph we can see for conflicts that are avoided. No dashboards for saying trust built. I don't know about you, but sometimes I feel like you put in an awful lot of work into a situation and then somebody turns around and goes, what do managers even do? It's this in the background. I think we have to reframe it a little bit in a similar way to the example with the teams. It's not about ownership. It's about stewardship. It's about setting the tone. Instead of being about boundaries, fostering as much collaboration as possible. Not the gatekeeping for we can all do this together, and collectively we can make it better. In order to do that, I think you need to name the work, whether it's things like mentoring.
We had to introduce a mentor program, the tech lead responsibilities. We acknowledge that the ICs might take a productivity hit because they're going to be spending time pair programming or sharing their knowledge or whatever. Name it in ways that are visible for the engineers, for the managers, for everyone to be able to make it more visible. For the manager, I think as well to shift your scoreboard, because it is a lot about what you facilitate rather than, do the tests pass? What's your GitHub history look like? Also, I've started thinking about the quiet wins. I want the engineers to raise an orange flag before it turns into a red flag. Keeping a note of these things where we've managed to avoid it becoming a red flag. Because you don't see it unless it goes wrong, do you? You put in a lot of effort to make sure that it doesn't go wrong, and to teach it forward.
I'm going to stretch my climbing metaphor wider than I can stretch my arms maybe. I think it is like instead of climbing the route yourself, you're doing the route setting. Making sure that the work is that sweet spot between achievable and challenging for your engineers. Making sure that they are bought into the work that they need to do.
The second lesson is about managing managers. The invisible work doesn't disappear when you manage managers. It becomes a little bit recursive, because now you're doing invisible work to help people do invisible work. I think maybe in smaller companies, another side effect of it is quite often you're not just delegating tasks, but you're delegating decisions being made. One particular example that we had was, so we need a lot of events on the platform to be able to sell the tickets. One of the company OKRs was the number of events that were on the platform. The number of events on the platform doesn't really tell you anything. We can have like 50 junior football matches in Germany and it's not nearly as effective as Coldplay's new concert, as some of the Oasis, whatever. It's not nearly as effective. It should be about the quality as well as the quantity.
One of the engineering managers had this insight. Although this project had been through a couple of teams, it was all about the numbers, he wanted to pick it up and do things differently. One of the things was to throw away all the process. He didn't want to use Jira, they didn't want to use what typical, like Agile, Scrumban, whatever your favorite flavor is. They just wanted a laser focus, a couple of backenders, just focus on this and just get it done. Of course, I was a little bit wary about this, because how do you keep an eye on making sure that progress is being made, they're achieving what they need to, other than if they achieve their KPIs. Happy to say they totally smashed it, so much so that they had a strategy that in the first month, they smashed their quarterly OKRs for the numbers, and then deliberately made a decision to shift, completely pivot from the pure numbers from the quantity to the quality.
They did it. They did amazing, it was brilliant. My fingerprints are nowhere on this project. I can see now that where my influence is was that I gave them the permission to do this, gave them the space that they needed to do this, the freedom, the autonomy that they needed to do this. The alignment was the quality of the events that were on the platform. We needed to follow that through as well. The separation was that they had the psychological safety in which to do that. My role was less visible. It was more about the indirect influence that there was, and giving them the permission and whatever they needed to do it.
When I'm managing managers, there's a couple of cruxes that I have come across. A crux is the hardest part of the climb. I thought I'd talk a little bit about some of the hardest cruxes that I have had to overcome. I think in this example, you can see that you don't want your engineering managers or your leads or whatever to be clones of you. You don't want them to solve problems in the same way that you solve problems. In this example, particularly, I was a little bit nervous about him throwing away all of the processes and everything, but they completely smashed it. Absolutely did it. The second one is about the context. I have had some difficult feedback in the past about how we should just tell engineers to just do it. In my experience, that doesn't get things done any quicker. I think you want people to have ownership and to be bought into the decision and the task that they're going to do in the same way that careful planning up front and thoughtfulness about your requirements, about your scoping, de-scoping will speed the project along in the long run.
I think it's similar with getting buy-in from people to pick up projects that you want them to pick up if they're going to grab ownership of this. It does take time, and it is invisible work, but I think it's worthwhile in the long run. I've learned the hard way where people, they spend so much time and effort saying, why are we doing this? Why are we doing this? Why are we doing this? When they should be using their considerable brain power to just solve the problem and get it out of the way quickly, because it would go a lot quicker if you stopped spending all that energy asking why. Share that context early and deeply. The last one is about the rescue reflex. I think this is where part of the invisible work and getting to know your engineers and professionally, what are their intellectual itches that they like to scratch?
Indeed, what are the things that they really hate to do? What do they think that are really boring? What do they not find satisfying? Because some of the jobs that you have to do, let's face it, you don't really want to do them. It's not the most interesting part. How can you get ownership and buy-in from your people? You get in there by having this understanding of your engineers and how their minds work. You don't want to micromanage, you don't want to get involved too early, but equally you don't want to wait until it's burning and you have to put a fire out. Getting to know them well helps you figure out at what point do you step in with the beta and what level is the beta that you need to provide? I'm not sure that there's a particular formula to do this other than getting to know your engineers and intellectually what makes them tick.
The next lesson is working with founders. I'm going to bring another climbing story in here. Alex Honnold made a free solo ascent of El Capitan, which free solo is no protection, no ropes, no nothing. This is like 3000 feet rock face, and most climbers would take three or four days to do it. There'd be like a team of people, they're like sleeping out there. He did it in 3 hours and 56 minutes. It's like complete madness. Like, what are you thinking? When I think about working with founders, I think this is an interesting perspective when you think about it. What is brilliant about what they've done is they've built this company. They've poured their heart and their soul in it. They've been up all night. They've lived and breathed, this thing all exists inside their head. They have all this confidence and capability to make this thing happen.
That is in contrast to the engineering department that you're building in that you're teaching your engineers to have a certain degree. They all don't have this information in their heads, they haven't worked at it as long. We have to communicate well. We have to share this information. How do we do that? We write documentation, whatever that looks like. The information needs to be shared with everyone else. We have certain processes we follow to make sure that we do things properly and we do things well. The founders at TicketSwap are still coding. One of them used to be the CPTO, I would report direct to him, and they decided to step away from the CPTO responsibilities just so that they could code some more because they're makers at heart. You don't want to quash any of that. It's brilliant. It's amazing for the organization. It's inspiring for everyone else.
Equally, you've got an engineering department that needs to share information, that needs to get stuff done. We now need to speak to the new board and the new CPTO, my new boss, and make sure that we're communicating that progress is being done. Quite often, you'll find yourself working as a bridge in between these two different worlds, and neither of them are right and neither of them are wrong, they're just very different. You do become a little bit of a translator between making sure that their vision, their energy, their inspiration is never quashed, but equally that it's respectful and the engineers understand what's going on.
It's difficult to get this from a founder's head, and sometimes they understand so much more than they realize that they understand because they've lived and breathed it for such a long time. They don't know how much they know, so trying to get that information out of them can be challenging sometimes. It's really helpful for me to write as much of it down, try and figure out where the assumptions are coming from so that you don't have a difference of understanding about what is intended. We had one situation, so we had to build a dashboard for a partner or something. The founder knew exactly what needed to be done and exactly how it needed to be done, but he wasn't the one doing the coding at the time, it was a different team that was doing the coding. They did what they do well. They planned it out.
They de-scoped. They did the thing. It became apparent over time that there were two entirely different conversations that were going on. The founder was speaking to some of the C-level about how he thought the project was going, and then the team were working on something in their own pace, in their own way. It was a really painful meeting where we realized that these two things crashed and we had to figure out how to change it all, change the narrative, bring everybody back into alignment. It was challenging, but it really needs to be done, being super explicit and getting that information out of their heads. Again, it comes back to logging some of this invisible is making sure that there's alignment between these two different ways of working, and you are a bridge. Another thing that's interesting with founders, especially founders that are still makers, like albeit they're 10Xers.
They're smashing the code out constantly, they're brilliant. They feel like a peer in a lot of ways, and so sometimes when we had a situation where one of the less experienced engineers received some feedback in a PR, that was a difference of opinion. It's not saying one was right or one was wrong, the feedback was fine. The fact that it was a founder that gave the feedback, all of a sudden, the feedback was received not as if it was from a peer, but from this mythical source, the fount of all knowledge. It was not the founder's intention in the slightest, he was offering some great feedback. It took weeks afterwards for us in our one-to-ones and supporting the engineer to build his confidence back up before he stopped second guessing himself and before he stopped, "What's the right thing to do, should I not do it again," and rebuild up all that psychological safety.
Those hours of meeting and all that extra work, how do you log that apart from mentoring one-to-ones, whatever I mentioned before. It's a lot of invisible work in the background to figure out how to communicate these two different views in such a way. Some of it is just that you sometimes have to have a thick skin. If you push back against this feedback and you disagree with it, actually, there's a really interesting conversation to be had in there. Treat them like a peer, they're working as a peer. There's the hidden cost of making sure that that works ok.
Founders carry weight, they carry the weight of the business and all the information that they've had throughout their careers, but their opinion also carries a lot of weight. The founders, the system that they work in can be quite different from the system of the rest of engineering, so you have to be another system in between both of these systems, something like that. You do have to translate. I think you do have to be the person that's responsible for making sure that everything works smoothly, and we all have a shared understanding of what we need to do. We want to protect the founders because they're brilliant, and we want them to keep going, but also to protect the engineers and make sure that they're building something scalable and brilliant. It's all about making sure this communication happens productively. It does mean sometimes that we have to rewrite the system.
It does mean sometimes that we have to figure out different ways of facilitating all of this communication and looking at what the effects of it are, what has worked and what hasn't worked. Engaging with your engineering brain in that respect for, do we need to change it? How much do we need to change and how do we measure if it has worked?
Key Insights
If there are some takeaways from all of this, it's about redefining success. It's not necessarily what you built. It's not that your tests pass anymore. It's a lot about what your teams build, what your diverse teams are empowered to do themselves, all pulling in the same direction. Doing whatever you can to make the invisible work visible. Definitely use your engineering brain to solve some of these problems, test assumptions, record the results, make the changes as you need to. This perspective shift, I think there's gold in mastering this perspective shift and how you look beyond your immediate concerns and the areas around about it. I think that's where you learn a lot about yourself, where you can apply your skills, and ways that you can help the business to grow. To trust the climb. The leadership isn't necessarily a reward for being good at tech, it's a completely different problem space. If I go back to my climbing metaphors, it's not a different climb, it's looking at the whole mountain in a different way.
How to Get Credit for Invisible Work
Mason: You talked a lot about invisible tasks and stuff. What is your strategy for making sure that people get credit for the work that they do that's invisible? How do you as a contributor make sure that you get credit for it?
Pauline Jepp: I think introducing the mentoring program was really good. What we also did was we added this to part of our career development plan for engineers to progress to the next level. We want them to take on some mentoring tasks and we want them to take on some of the coaching, pair programming, all of these things, and to recognize it as some of the responsibilities that they will take on as they progress in their career. Indeed, when they're going to tech leads as well is acknowledging that as part of the career journey. I think for managers, it's looking at how well the team's delivered. For me, it's, did we actually accomplish what we needed to accomplish? Did we communicate well across the department?
Questions and Answers
Participant 1: When you are an engineer, you will have a way of work, and you tend to work with the peers more closely. You will have an empathy on how they work and their culture. When you move to a manager, the scope of work will differ to you. More of managing a team, addressing the cost benefits, providing profit, managing the people. You might have to take a decision that conflicts with your ideology that you had when you were an engineer.
Pauline Jepp: Sometimes you have to do some tasks that aren't exactly the tasks that you want to do. That's where the whole phrase disagree and commit came from. You voice your concerns. You talk about why it would conflict. If you can find the common ground, find the thing that scratches your intellectual itch, then you can go that way. Sometimes I think your job could be done by 10 people, 10 people could do your job. If you're lucky enough, you and the job go together for a period of time. If it's something that really doesn't fit in with your personal values, then maybe it's time to do something else. I think for the engineers, it's the same. It's like having those conversations. We all have to do some things that aren't the most interesting, or we might have a disagreement about the solution. We should work together to figure out if we could convince the other person for the solution. If we can convince them, then we have an answer.
Participant 2: I have a question about how you can get the leadership to move away from productivity-based metrics, such as tracking tickets completed, to a more meaningful metric. What are some of those meaningful metrics that you might actually recommend for teams?
Pauline Jepp: I think especially at the moment, we're going through a lot of similar experiments to what makes it more visible. Are there metrics that we can show because of this, like starting the mentorship program, are more people joining it? How are they getting involved? Looking at the career development of the mentees before they join, and how they have improved after, some feedback from them. The tech lead, we introduced tech lead responsibilities recently as well, and acknowledging that there is an impact, and monitoring the impact and the productivity. Also, there's an increase in productivity for the people that they're leading, or the PMs, or the product managers, or engineering managers, the relationships that they've got there. Trying to shine a light a bit more on that. As for exactly what the metrics would be, that's still a bit of a work in progress.
Participant 3: How do you build trust as a two-way street? When you're working as an IC, you work in silo, if your manager doesn't trust you, you really need to go and convince and make a case like why this needs to be done. When you're a manager, or like in some leadership position, you need to really show that you trust the instincts of your team on the engineering team, or a particular IC. How do you go about building that trust at a broader level into the entire engineering team or the company?
Pauline Jepp: I think when you come through the track from a developer background anyway, there's a shared understanding and a shared language. Indeed, I think it's a lot about building that relationship with your engineers, like I said, understanding what satisfies them intellectually, what bores them. In all of my one-to-ones, I think the question I ask most of the time is, are you at that sweet spot of achievable and challenging? Then, how can you figure out where to step in, how to support them, but also like how to get out of their way and let them figure it out themselves. Sometimes that means watching them fail. I don't know if you've read this, it was like some years ago, I saw this thing on Reddit, it was ridiculous, where someone said that when they wanted a problem answered, they would go on Stack Overflow. They would write the question, and then they would log in with a different account and write the wrong answer, and they were more likely to get people to respond.
It's a really painful thing for your ego to do, but I do this. You're like, you say something blatantly wrong to get engagement from people, and then people get bought in, and then you start having more of a conversation. It breaks the ice. Then you can dig into what does satisfy them intellectually and what bores them intellectually. I think it's careful attention to the people that you work with, and building that relationship with them, like frequent one-to-ones. Radical candor, I love that. I want them to be better engineers. I also do a 360 quite often. I invite them all. I don't handle things the best all the time. I have blind spots. How do I know what they are if you don't tell me? I want to be better, so please tell me. It works both ways. I'll make mistakes. I'll be public about my mistakes.
I'll deliberately make mistakes, so it's obvious that it's ok to make mistakes, and we learn from our mistakes. I ask people to give me feedback, so then when I'm giving them feedback, they know it's because I want them to be better engineers. I'm invested in them and their career. I think a combination of those things just generally builds trust.
Participant 4: I enjoyed the talk a lot, but it wasn't what I expected. I expected to hear the story of how you made the transition from non-leader to leader. Do you have a two-minute summary of how that happened? You didn't just come in as a leader, did you?
Pauline Jepp: No, my first job out of academia wasn't even that interesting until I made it interesting, and made it much more scientific, and tried to steer the company more in that direction. This was like the virtual shark net that we bought, which incidentally really annoyed me, because it was called Clever Buoy, and I am not a boy. This was where I started to see that it's what's around the system. The best engineering solution doesn't always win. It's a lot about how it's sold. It's about how it's used. It's about how it's talked about. I started to see that it didn't matter how good my algorithms were, my target tracking, my classification was, it was a lot about, how is this going to be perceived by people around about it, people in the company, people outside the company. I could see that I had to maneuver around this, and figure out how to make it work.
Then with every step that you do that, you take on more responsibilities, your perspective shifts. You realize that you have to move more in a particular direction, and take on some of those leadership roles, and awfully often drag some people kicking and screaming along with you. After the talk, I'm thinking, how deliberate was it, and how much was it I just wanted to get shit done? Not sure, but yes, it was definitely an exploration for me. Like I say, I didn't think I'd be very good at it. There was a couple of really exceptional managers I had when I worked at Lloyd's Register, who changed the entire discussion for me. Previous to that, I thought a hierarchy was about power, but all of a sudden, these two amazing people were leaders, were showing me that it's about responsibility, and the shift in the responsibility. This completely changed how I viewed leadership and management.
Mason: You gave us a lot of initiatives, a lot of good advice that people have given you, and advice that people have given you along the way of betas that you've received. Has anyone ever given you some really bad advice, and what was it?
Pauline Jepp: Almost every time I've made a move to a different company, somebody said to me, you're going to hate this. Like the job where I did the virtual shark net, which was the best job ever. I went to a more corporate structure, like LRs. It's one of the oldest companies in the UK, it's like for shipping. We were in the software. I'm doing physics calculations. Everybody that knew me, because I'm so scientific in my background, they were all like, what are you doing? You're going to absolutely hate this. Then, equally, when I left LR and moved to the Netherlands, and they're like, you're going to hate it. People just keep saying you're going to hate it, but actually, I'm quite resilient, and I just like solving interesting problems.
See more presentations with transcripts
