Transcript
Trindade: My name is Francisco [Trindade] and here we have Zoe [Gagnon]. We'll leave intro for a bit into the presentation. Just to make clear, we are here to talk about how to build high-performing teams in an existing organization.
I want to tell you a brief story. I joined Meetup one year ago, I was managing a few teams. In the first week that I started, there was a team presenting a project that was supposed to take three months. That was the deadline that was being given. It was clear the project was going to take more than a year, and it actually took more than a year. The teams I was managing were having discussions about how do we estimate stories, are we estimating effort, or complexity of time, so how do we work together? We were struggling to find ways to really work together effectively. I come from a background of consulting, and process improvement, and teams and building teams, and it was clear to me that something needed to change at Meetup.
Gagnon: I came to Meetup through my friend, Lisa. We used to have brunch together quite a bit - we're a bit busy for that right now. We used to do brunch every other weekend, and I found myself, for about nine months that brunch was just consulting for Meetup. I really thought it'd be nice to go give that a try and see what I could actually do coming in. When I got there, I found myself on a team where it had just come into existence, but the stakeholders wanted immediate results, and we were nowhere close to being able to deliver. I looked at this and I really thought we need a change in how we approach this and how we build software.
Trindade: We are not these mod people coming into a big organization. This was something that everyone was seeing. We were hired as part of an effort to make Meetup better. At the time that we joined, there was a struggle to find a way to work together, a way to work effectively in software, and a way to build software effectively as a company, in the context that we had. One of the challenges the company was really trying to tackle was how to find a sustainable way of working that's both effective and keep engineers fulfilled and happy in their jobs? How do we stop having projects that go two, three, four times over the budget and scope and deadline that we had, or estimates that we have? How do we actually breach this lack of and solve this lack of trust in software delivery that both leadership, from a product and business perspective had on the engineering side?
What we wanted to bring to you today is in three parts. It's really to tell our story from the year that we've been in the company, and tell you what have we done that has worked well, and which context that we had and how that has worked well. Also wanted to tell you the things that we tried and clearly didn't work as we expected, and where we failed, or still trying to improve. The last thing we want to tell you about the blind spots, the things that - we came, certain that we could solve, and really couldn't move in the time that we have been there.
The reason we're doing that is because changing and improving companies, I think, is something that's very common, and I'm sure that everyone here is at the conference and is at this session because you think that your team or your company or your unit could be improved. We really want to try to bring as much of examples and stories and a context to you so you can copy us in context that are similar. You can apply things that we did, and also hopefully, you can actually do it better and not make the mistakes that we made throughout this journey.
A bit of intro. Zoe [Gagnon] here, she is an engineering manager at Meetup. She has been there for eleven months now. She manages the discovery team, which is one of the teams that's trying to help people find events within Meetup. Before that, Zoe [Gagnon] was three years at Pivotal, the consulting company, and she has been around seven years also, working with startups in different phases of their existence.
Gagnon: This is Francisco Trindade. He is engineering director at Meetup, working with the discovery team and the apps team. Before Meetup and his year here, he was at ThoughtWorks for seven years in the UK and Australia, doing exactly this thing as a consultant. He also ran a startup for five years, where he learned that a lot of the things he had done as a consultant didn't really apply to the business world all the time.
Trindade: Meetup's a website, meetup.com. You can always check us out afterwards. Meetup has been in existence for 17 years, which is something that surprised me when I joined. Yes, it's a company that's 17 years old, but still tries to behave as a startup. The mission for Meetup is getting people to connect in real life. We all perceive and see the trend that real-life communities and real-life connections are dying down. people are meeting less and connecting less. Our mission is really to reverse that trend and try to get people to connect in real life and improve their lives through that connection. We are around 100 engineers, we are mostly in New York, plus a bit in Berlin, and a few people remote across the world.
We were recently acquired by the We company, which WeWork belongs to. With that acquisition, which draws the context of a lot of things that we're talking about here, Meetup has been trying to get this second wind of a startup growth curve, and really multiply the size of the company and the impact the company has in the world.
What to Change
Gagnon: I want to talk a little bit about the situation that we found when we first got there, and some of the ways that we identified things we'd like to change and how they were affecting the company. The first one that we identified was project teams. We didn't really look for symptoms of this because they were just there, there's projects teams. What we found in our experience, and what is really playing out at Meetup as well. This made collaboration really hard because people were coming together for a project, working on it for maybe three months, maybe a year, maybe it was supposed to be three months and it took a year. They would work together, and then they'd go away. It’s really hard to find people that you connect with, you can build a relationship with, and then lose it. There's also a lot less safety in those cases because each of those project teams had an engineering manager who would be your manager for three months, and then you'd get a different manager. When I got there, one of the people who I manage now had four managers in one year. I think we can imagine just how uncomfortable that really is.
We also didn't have much context across the organization because the people who built stuff wouldn't own it - they'd go somewhere else - or the entire team would dissolve. That made it really hard to have long-term ownership and context, and just maintainability.
We also found some legacy code. We found that it was really hard to implement changes. We had high and unpredictable cycle time, some things would go really fast because it was a newer thing, and some things would take forever. We had a lot of custom frameworks that had been built out over the years, both in the front end and the back end. That was causing people to avoid doing certain kinds of work at all. We have a custom request handling framework for our backend for rest requests, and nobody wants to work on that, so we don't add new endpoints anymore, which was a problem.
Trindade: If I can add to that, I'd just like to create some context. One of the teams that Zoe [Gagnon] was working on last year, it was part of the legacy codebase when we had this legacy UI. You had to put some UI elements on the screen [inaudible 00:08:48] and the team had to learn four languages to add that. It took them, I think, a few weeks to actually add one element.
Gagnon: The total thing took a month and a half to add the stars to three different pages in JavaScript, Java, Scala, Python, including using jink, mustache, handlebars, which we had forked and merged together to cause meetstash, which is a really cute name. The whole thing was was JSPs, and there was a Django server running in Jython in order to do the pre-rendering, so that was pretty complex to work with. You can imagine with that little chain, there's exactly one person in the company who knows how that works, and a lot of our time was spent waiting for him to be available.
We then found, because of this fact, that those three-month projects took a year, or adding stars to a page took a month and a half. The executives had lost trust in the engineers and didn't have any confidence in the view of the future. We had a lot of meetings that took a very long time and didn't result in anything. We figured this was really caused by the lack of process that we had. There was something agile-like but it's the form without the function of it. There were retros, where people would come together and complain, and then leave. There were stand-ups that could take an hour, as everybody detailed the lines of code they had written the last day.
There wasn't really a cadence or an understanding of why we would have these types of rituals in our process. That's because there wasn't a lot of people who were thinking, why do we do these things, what value are we trying to derive from them, and how can we improve to get more of that value out?
As we mentioned before, we had a lack of long-term ownership from these project teams. From legacy code, as well, we didn't have a lot of great understanding of that. We had lots of on-call incidents because people were writing code that they didn't really understand. Those incidents took a very long time to resolve because they didn't know it, they didn't write it, and they weren't allowed to change it, and that caused real problems, long-term.
Finally, underpinning a lot of this was that we had a lack of engineering craft. We had models that had little to do with the actual user experience. You may be familiar with Meetups, and know that you join a group and that group hosts events. You may also be a little bit surprised to know that there is no group or event table in our database. That seems natural to me. We had a lot of browser-based Selenium tests, and they could fail for reasons that people didn't understand. Even when they failed for reasons you did understand, it didn't necessarily tell you why it had failed, just that this piece of the page was no longer working.
We had really low predictability, just overall, if the code could work correctly because we have very high coupling. Sometimes you'd change this thing, but that was actually statically scaled to globally available, and this thing over here, you'd get spooky failure at a distance, which is terrible. We also had a case of misapplied or misnamed patterns. Maybe not everybody's read the Gang of Four, but there's a proxy pattern that stands in for a database connection. We've got those, but they're called adapter patterns, which are completely different things in that book and in the normal nomenclature. This just led to more confusion. We found, overall, that there was just this lack of craft and deep-diving that was really slowing down the organization.
Process and Practices
Trindade: This is going to be where we start telling about what has happened. What we did as good ex-consultants was, we applied the number one rule of consulting, which is you assess what's your sphere of influence, and you try to change within that. We're going to try to frame our conversation now as telling the story of what happened within that context. We're going to talk about the things that we had control of, what we did with that, and what happened. We're going to talk about the things that we didn't have control of, and what happened with that, and how we tried to influence and tried to move out of it. Also we’ll try to talk about how he tried to change that influence that we had within the company. To begin with, the thing Zoe's [Gagnon] going to describe basically what we had control of, and what we have done about that.
Gagnon: For me, as the manager of a team, I had pretty decent control very direct influence over what is this team going to do. One of the places was just the process, what steps do we follow turning an idea into a software? We started there, and we started with just making stories much smaller so that they could actually be understood. They used to be feature-sized, and that would be two or three weeks on a story. We started with getting devs involved in story writing so that the acceptance criteria actually made sense to them. We ended the up-front architecture and emphasized YAGNI and examples for extractions before really moving on.
We also re-emphasized feedback loops by taking those retros, taking their cadence from once every three weeks to once a week, and emphasizing that you have to walk out with action items, then you have to do the action items, which really is the key. Feedback matters when there's action on it. We also started doing one-on-ones with everybody on the team, in order to give them individual improvement feedback. We started collecting metrics and discussing how can we move faster, broadly across the team in a very open way. We definitely, the whole time, emphasized as well, this is a system problem, it's not an individual problem. It's not something that any of the people on the team caused, but rather the way we were working together in a system. The basic idea there was that a band system will beat a good person every time.
We also decided to focus a lot on the practices underlying it. We did faster feedback for the devs through test-driven development, through pairing, and through instituting trunk-based development so that they could find out very quickly, does it work like you want it to? Is it a good idea to do it like this? And does it work with all of the other things, and can you learn from those other things at the same time? We created faster design feedback by creating iterative architecture rather than imposed architecture, and emphasizing YAGNI, or deferred decisions and saying, let's just wait until we have more information to make these decisions.
Engineering Lead and Engineering Manager
Trindade: Another thing we did that's interesting - and Nick [Caldwell] just mentioned it in the keynote - we looked at were the leadership roles within the team. Meetup has these two roles, the engineering lead and the engineering manager, they were the engineering leaders in the team. As Nick [Caldwell] mentioned, if you go to five companies, you get seven answers of what you should do. At Meetup, if you go to five teams, you got seven answers of what they should do. We decided, looking about how these people worked and how this leadership worked within the team, and tried to make some adjustments.
One challenge we had with engineering leads was this idea that engineering leads were very busy. They're supposed to be technical leads, they're supposed to be the people leading the team technically, but they were very busy with meetings, coordinating meetings, coordinating retros, coordinating things across teams. What ended up happening a lot of times is that engineering leads become this ivory tower architect. They were people that would give advice on code but really weren't coding, that would make architecture decisions but didn't have the context on the ground and didn't end up facing the decisions they made in the future, so living with them. We really tried to move away the technical leads with the team's meetings, away from higher-level discussions that they didn't need to be in, and being more in the code, and helping the team technically.
One thing I set up with all the leads I managed was they had spent half their time coding and half their time hands-on with the team, like the delivery. I was speaking with one of them a few weeks ago about the last year and what has happened, and he mentioned that the biggest and most positive change he had in his career in the last year was that he was able to go back to being technical and go back to actually having technical influence. We had this pattern, the technical leads of the teams don't want to be technical leads anymore because they couldn't do technical work by doing that.
Then, the other side, we had the engineering managers. Meetup had historically had this function spread across disciplines. We had web managers, and front-end managers and back-end managers, and they managed people across teams. This wasn't something that we introduced, but as I joined, and as Zoe [Gagnon] joined we were moving to this pattern of having managers within teams, so managers that could actually help a team across the stack, and not just a particular discipline.
The challenge, because there was like a cultural history, is about this individual versus team mentality. I think a lot of our managers are used to thinking about how to make individuals succeed in their career, and they focused on that, and no one else was focusing on how to make this group of people work together effectively. The things that Zoe [Gagnon] was mentioning about process and how to run a team and how to improve the team, there was no one there responsible for that or accountable for that. We were relying on a lot of engineers through retrospectives to come up with all the changes they needed, but of course it's unfair and not very effective to expect that people who work in the system are able to step back and figure out why the system is not working. We tried to realign that position and that direction.
Gagnon: Especially when your retros aren't generating action items, you're not really doing anything based on them anyway.
Did It Work?
We talked about the challenges that we've had, some of the things that we tried to do inside of our sphere of control in order to address them. It's good to stop and think about this and ask, did it work? Did having this process emphasis, did having this engineering practice emphasis, did reworking these roles to have much more separate and clearly defined boundaries, was that effective? What we found is mostly yes, because it was.
It turns out, this was the easiest part of all of the change that we have driven. From 10 years of consulting we've definitely worked with difficult clients. People don't pay you to help them change if they're good at change. This was not that. People here wanted to change, and they were very excited and hungry to do it. We were able to have, in this short period of time, a lot of really good results. Teams were collaborating better, teams were producing better, they were more predictable.
This doesn't mean that everything that we did worked. Particularly, we talked about building the engineering mastery around things like test-driven development, or iterable architecture, like an evolutionary architecture. Those we haven't had a lot of success with. It turns out that if you want somebody to build up four years worth of experience in something, it takes about four years. One person can't give eight people those skills in just one year, it's not going to work. That's something we're still going to try on, but we're going to have to change our approach on because just coming in and saying, here's how you do the basic thing, here's how you invert a dependency, go do it, is not successful approach.
Trindade: This is where I think our background backfired on us. I think both me and Zoe [Gagnon] were used to change teams and change organizations from a consulting perspective, where you are there with multiple people, and there's a critical mass of people influencing on all levels. I think we didn't realize that that didn't exist at Meetup. Although there was a resistance to change, I think as Zoe [Gagnon] mentioned, a very positive aspect of the company and this culture is that everyone is happy to try something new to do a better job. At the same time, there was no expertise, and so we always struggled with the fact of, where do we put the limited expertise that we have across the company, in which level do we put it, and how do we influence that? That's something we're still trying to figure that out.
We spoke about what we could change, and that was the easy part. We just got there, made those changes, these are things that we didn't have to consult many people. Within our power of influence and decision, we could actually change and try to make a move. Also, there were things that we started noticing and started dealing with. I've been away from our sphere of influence, so things that were in higher levels of the company, or things that were more ingrained in the company's culture and that needed more collaboration, there were aspects of it that were really hard to move, and we didn't know exactly what to do about them. What we're going to talk about a bit about now is what those aspects were, what we tried to do to make a difference, and what ended up happening with that.
Project Teams and Deadlines
Gagnon: One of the first things that we really wanted to address was the projects teams that we were running. For the first six months I was there, I was on a team that was guaranteed to go away because we wanted to launch exactly one feature that had stars in it. Once we figured out how to do that, the project was over. The stars were out. Or, as the case was, we saw that they didn't work, and we tore them down, which was really nice. This is not something we had control over. Me on a single team or Francisco [Trindade] working with two teams, we couldn't change the way the company allocated people just because we said so. We started having conversations about this. This is really moving into much softer influence, where we just talked to people. We said to our VPs, to our CTO, to our incoming CEO, "This is a thing that's hurting us, and here's how we can fix it."
We also had mentioned before that the executives had lost trust in the engineers, and they compensated for lack of trust with an imposition of deadlines - really strict deadlines, "This scope must be finished by this date, or there might be consequences." I wanted to address this because it was really affecting my team directly. I went old school for this, and I took some sticky notes and I stuck them on a structural support column in our office. Each sticky note had a story, it had the points we estimated for that story. We just did them top to bottom and in order of most importance. Then we stuck up right next to it, team's velocity. We've got eight points a week to work with right now, that's how fast we're going. I started counting off. Every time I got down to eight points, I'd put another week there. Eight more points, one more week and we could get the whole column full. We brought stakeholders over and we said, "Look, if you want this scope by this day, something's going to have to give. We can't do that, that's not reconcilable." Sometimes old techniques do have some effect.
Product Engineering
Trindade: Another thing that we faced quite a bit was this divide - for lack of a better word - between product and engineering. We're both engineers, so we're talking from our perspective, but also, this wasn't a one-sided problem. I think it was a systemic problem that was across Meetup. Because of these problems that we've been talking about, like the failures in projects and failures in delivery, we got to this point that product just didn't trust engineering to deliver. They were like, insert scope and tried to get a lot of things in the scope as much as possible, and tried to create the scope without consulting engineering at all. On the other hand, engineering would react by just defining everything as very complex, and everything very hard to do. We had this debate that wouldn't go anywhere, and we ended up just with the strongest person winning, and deadlines and whatever the consequence of that, which was never great.
We had this broken communication that was both within teams, within product managers and engineers within the team, but also as a company with product leaders and engineering leaders, and business leaders conversing together. What we tried to do here specific on the team was working with the PMs, working with the engineers to align them the same on the scope, and actually reasonable scope conversations, reasonable complexity conversations. Then, also trying to talk to the company and, in leadership meetings, trying to assess this problem of scope versus time, and the quality. There was a point in time during last year that I used to go through every slide that was presented to leadership and just remove dates from it and say we're not going to put dates, we're not going to talk about deadlines, and try to have that conversation again and again with people to say why this is a challenge, and why we have to behave differently.
Gagnon: For me, this really pointed out the value of doing a very broad T-shaped skillset. Sometimes we talk about T-shaped engineers, like people who are good at back end and then ok at front end and ok at mobile. For me, I wanted to move beyond that and get good things related to engineering in the past to do design and product management. The fact that I had previously interviewed for and gotten offers for product management roles really helped me pay off here to work with product managers to cross that divide and be "I know what you need because I've done this. Let me help you understand what we need also," and bring that a little closer together.
Lack of Long Term Ownership
Trindade: The last thing that we got, we mentioned before and we hadn't made any progress in, was this lack of long-term ownership. As Zoe [Gagnon] mentioned, project teams were started and finished based on projects. Imagine the team would come up, build some software, disband. That software still exists, who maintains it? We don't know. Then, there's a problem, there's a pager incident, the people on the call don't know who to talk to to figure out what's happening. That was a concern, and of course, that causes stress across engineering, and caused a lot of churn in terms of time and effort to solve it. It was an organizational problem that we didn't have any solution for. These four challenges that we had, I think were things that we kept discussing and we kept talking about. Not just, of course, between us, but between the others, and the VPs and CTO and engineering and across engineering leadership. We really didn't know exactly what to do about it until something happened.
Reorg
Gagnon: Meetup is a company in transformation. One of those kinds of transformation is a reorg, and we got one. Actually, just when we needed it as it turns out, because this really helped the company. We moved to long-term squads working on pieces of the product instead of projects to add things to the product, and longer-term ownership so we could start to look at here's a team that's building expertise in this thing. Let's shuffle the things related to that towards them, and they can be the owners of it. That really helped solved those problems right off. We found a really big effectiveness from our push in the conversations we had, in the relationships we had built. We saw these changes happen to really bring relief for these big organizational problems. The investment that we had made by having conversations, by being persistent had paid off here.
Trindade: I think one big thing was focus. As Zoe [Gagnon] said, as we're discussing how the team should be shaped and how we should reshape the organization, and as we reorganized the company, we organized the teams with the idea of creating longer-living teams that were focused in one area of the company. With that, of course, that gave more focus that enables us to achieve a lot of things that we couldn't achieve before. We have teams that actually own codebases and improve codebases in the long term. Iterating our practices, both within engineering, but also engineering product, we are more independent as a team, and more autonomous, and we could actually figure that out better. Across the board reorganizing the teams unlocked a bunch of possibilities that changed the things we could do with our team.
With this reorg happening, the opportunity that we saw was was how can we use that to reshape the influence that we have within the company? How can we, with the reorganization, try to break the boundaries that we had before, and how to we make our teams even more independent, and more able to achieve success? The way we did that was by trying to forcibly separate our team from the rest of the company. Meetup has the 17-year-old legacy code base, and they had multiple generations of it, as we mentioned. We decided to start new projects in this year, 2019, all in new codebases, new infrastructure, new architecture, and everything else.
The reason for that was both organization and technology. In the last year, one of the big problems that we had was, because teams are so on top of each other, there was all these distractions that kept happening. Some team that delivered some code that broke our pages, and then we are on-call for that, so we are distracted. We had conflicts, pipeline problems, because we were all entangled together, so delivering software was much harder. That's where practically, by separating ourselves, we made that much better. Also, organizationally, it meant that we could make decisions that didn't impact many people apart from us. That meant that the team could move faster, and the decision making could take more risks because the impact was controlled within our scope. That enabled better practices even in how to work together.
That wasn't all positive, it was quite controversial within the company. It was something we did intentionally, but not sure if was the right approach without telling many people. Of course, that caused a bit of divide, so there was some miscommunication that happened that caused problems, and there was some challenges of how to deal with the consequences of that throughout the year. While this was definitely a good practice, our engineers love the code they're working out, their practices they're doing, and I think the quality is much better, if anyone's thinking about that, definitely think about the communication that you do across the company when doing something like this.
Gagnon: That's, honestly, one of the blind spots that we've identified. In addition, we had the mastery issue, where we thought this would be really easy based on our previous experience, and it turned out it was really hard, based on our current experience. We also found by going off into our own codebase, building something brand new, our cross-team communication and collaboration really suffered from that. We were building things, and other people also decided to do things outside of the legacy codebase.
We could have learned from each other quite a bit. Instead, we were surprised when they had launched a thing and it's "We needed that thing." That was a place where we weren't doing as great as we could be. Then also, our communication with non-engineering parts of the company, with customer support, with the marketing team, those are areas where our work really does involve them quite a bit, but we're still not very fluid at that. We're not very good at that yet.
Results and Lessons
We've also had some results. One of the things we've seen right off is that we had a massive lift in our employee satisfaction. Our last survey shows us not only did we have a 30% lift from where we used to be, but that it's now 30% higher than any other team in the company. People definitely are responding to what we're doing here. We also see the team practices are getting better with real results. Our cycle time per story has dropped from a 10-day average to a 2-day average, which means we can ship things in one-fifth of the time we used to. Our volatility, which is how much we vary from our average velocity has gone from 120% to 20%, so we are a much more predictable team than we used to be as well. Those are places where I think we've really paid off. We're now able to also leverage some of this to bring in new partners and build that critical mass of experience that will help us in the future.
There are some lessons we learned. It's hard to get experience. It takes a lot of work to build experience, and you can't just drop in with some words of truth and expect that to be experience. There's a lot of challenge between having a great person on the ground doing work, or a great person doing leadership activities. You can't really have them do both. That was, at least in our experience, a really challenging ask.
First, for the takeaways, it works to work within your sphere of influence, and then invest energy in expanding it. Start off with the things you can control, and then put the effort in to move that bubble a little bit bigger. People are not afraid of change, they're more afraid of change happening to them. If you bring them in and you invite them into the change, you can create a virtual cycle of improvement, where the improvements themselves create more improvements. Then, don't underestimate skills and experience. Waiting to build it on your team can be very slow. It can help to hire new people in, or to hire on consultancies to help you build that.
Questions and Answers
Participant 1: You had mentioned you had that one person on the team that really knew all the tricks on how to get the code deployed, the stars and stuff. When you reorg'd the teams, was there a challenge to find the right team for that person and still make them effective?
Gagnon: What was the real challenge, this person was not on a team. They were free-floating, going to every team. If you wanted help, you had to get on the list, and convince him that your problem was the most important problem. That's not something that we've resolved, but by moving away from the legacy code base, we have much less dependence on that knowledge of it as well, that historical context.
Participant 2: Do you mind touching a little bit on the upper management side? You talked about how to get from a top-down approach, but what were the challenges that you guys faced with the C-levels, for example, with the managers of the managers?
Trindade: When we joined, a bunch of people were hired with that intent of upscaling engineering. We had some trust because of that, I think. We felt like within the engineering organization, Meetup is a very empowering culture. I never had to justify many of the things that I wanted to do, to my boss, and my boss's boss, or the CTO, for example. They trusted as a lot. In terms of product and leadership, I think that was a harder conversation. Usually what ended up happening to me in the past in my career but also at Meetup is just having honest conversations.
When I joined literally in the first week, we had this meeting when this project was presented, and it was like a rich platform, like a page. They were saying it's got to be done in three months, and I went to the general manager of the company and said "I don't know what's happening. it's my first week, but I'm pretty sure this project is going to fail," and explained why. I said "This is my experience." Of course, the project continued, I didn't have the trust then. The project eventually failed, and then I gained his trust afterwards.
I had one manager in the past that gave me this tip, "In order to be successful at your job, you have to risk your job every day, and what you believe in." Being honest, and just stating what you're seeing and what you're thinking, and not trying to have, of course, with care and with kindness, helps you gain the trust.
Gagnon: One of the things also that I leveraged a lot was just doing things and then showing the results, and using the results to drive it up the adoption. I could take three people for two weeks and say, "Let's do this thing, and let's measure how it goes." At the end of it I found, "This had a really big improvement. Look at this, we said it would come out on July 14th, and it came out on July 14th." Let us do this more broadly, and we'll get more of these results.
Participant 3: Meetup is a relatively new company. How about the companies that are very old and have very old legacy code, and that code, if you want, is what we ship to our clients, what puts food on the table. What would you do in that case? Because you cannot tell teams, "You're not going to work on the legacy code, and that's it," and moving away from it takes years. How do you convince teams to keep working on that legacy code?
Gagnon: I've worked with some financial institutions that have some longevity like that, core business processes are still running on machines that they bought from IBM in the '90s. What we found there is, you can do a two-part approach to that. The way that people interact with these business processes is nothing like it used to be. We are no longer using dedicated terminal machines when it's green, and you have to know exactly all of the secret codes to put in because Y means three things on three different screens.
Now we're using browsers. When we move into new things, browsers and mobile, we get to have a clean break there. Then, you can create adapter layers that are all right, everything in front of this is going to be modern and clean, and everything behind this can be the existing processes. Then, when the existing processes are written using tools that are amenable to it, you can also leverage those to push a little bubble of freshness back. That does take years, it's true, but it can pay off as you move. Everywhere that that freshness is, it's so much easier to move, that people want to expand.
The "Working Effectively with Legacy Code" is a great book that details how to do this. It's going to be pretty hard if you're still in the COBOL or Fortran '98 situations, or hard-linked C. A lot of companies are using just Java, but Java one or two. You can still modernize that and get some more freshness in there because the language is going to support a lot of the tools that we have these days.
Trindade: Just adding to that, Meetup is 17 years, any company that lasts longer, you're going to have multiple generations of code. I think being stuck to the legacy is a mistake, because you're always going to have to evolve your code, and you're never going to be able to make a clean break from going from 17 years of code written in some ways. Just clean all that up and build new; as a company, you're going to have to learn to live with a continuum of code. There's legacy and the new code that you're building, and hopefully if you're doing that well, that gap is evolving with the company. Then, technologies like that allow you to deploy things more independently and more like microservices and building smaller systems allow you to really have multiple generations of code working together, so you can still have productivity on the new things, but also maintaining old legacy when you need to.
Gagnon: Yes. I think it's a spectrum. Stuff that has to change a lot also affords you the opportunity to make it more changeable.
Participant 4: I have two questions. One, being from more of an engineering individual contributor side, I would say my sphere of influence, those of my colleagues, tends to be more on the actual deployment, how we build code. This is based on Conway's law, knowing that communication structure tends to be how you deploy, have you seen or do you think it's possible that how we deploy can eventually influence our communication style and how our teams eventually get structured?
Then, second, our engineering organization is a lot like that, project teams that are formed and then blow up every three or four months. We're also an incredibly seasonal company. Our business tends to happen right around August, where we start picking up into December. We can't reorg right now because we would miss our season. With these feature teams or our project teams, we notice that there's a lot of that forming, storming, norming, performing. Having done this with some of the teams at Meetup, have you seen or have some estimate on approximately how much time does it take for a team of 10 people to really enter that performing phase so that we can start selling it to our managers and to our VPs, that we need to stop destroying our teams, and maybe give us a timeline for when we can actually start performing?
Gagnon: I can talk about the first question because I've seen this a lot. I put up on Twitter one time, I was talking about how often I've seen companies try to solve their organizational problems through a deployment strategy, which is microservices. A lot of people say "Microservices is going to fix it so that this team and this team are not going to stomp on each other on the code anymore, because it's two different things." It turns out, that doesn't really work in any case where I've seen it tried. I've seen it a few times tried. Fortunately, as a consultant, you get to see lots of people experiment with it.
The fact of that is your teams are going to have to do things. If those things are deployed or owned by other teams, it's still going to stomp, even if it's little, separate deployables. I don't have a lot of faith in a deployment strategy being able to trickle backwards and influence the incentives, the things that are really driving a team to do the things they're doing. I would definitely, if I could, in this situation, and in past what I've done is just started having lunch with people off of teams in order to start building those bridges and rewriting that Conway a little bit so it's not toss stuff over the wall, but it's rather, "Let's shake hands and let's design systems that shake hands, too."
Trindade: In terms of how often it takes to build a team, it depends on so many things. I think it depends a lot of the experience that your team has, it depends a lot on how well your organization knows how to do process and do software, and how stable that thing is. I think at Meetup we have there's two problems that the organization is still learning how to deliver software at the same time as engineers are quite junior. It slowly takes a long time because a lot of things are in discussion. On the other end of the spectrum working in consulting, where you spin up teams in days, because we all knew how to work together, and you were all quite experienced a lot of people would fill the gaps and make it work. I would probably not think about time, because I don't know your context, but I think maybe a better way to frame is, what are the metrics or signals that you should see when a team is performing, and try to measure that so you can start to have a baseline of what's happening and how that's going.
Gagnon: You can see those ramp up, too. If you say low cycle time is a performing thing and we start off with a high cycle time, as people storm and norm, you can also watch the cycle times start to come down. It's not like a light switch where it's all of a sudden ten to two. It's continuous. You can say, "Look, this is a trend. It hasn't plateaued yet, and if we break up the team now, we're just cutting off that trend." We haven't even gotten to the good part yet.
See more presentations with transcripts
