 I think the audio sounds okay, so thank you for coming. Late in the day, on the last day of the sessions, I know everybody's probably tired, but again, really appreciate folks coming out and listening to cross-functional teams. So my name is Jeff McWhorter. I'm the Chief Operating Officer at Gravity Works Design and Development. We're a digital agency in the States. We are about 26 people right now, and I want to tell you a little bit about our journey as a company and how we implement cross-functional teams, what they mean, and how it really helped us out at a critical point in our business. So what are cross-functional teams? Cross-functional teams, also known as multidisciplinary teams, were started in the 50s by an insurance company called Northwest Mutual out of the United States, and they have different effects based on the different types of business. Cross-functional teams inside of a product company are gonna operate a little bit different inside of a consultancy. A traditional cross-functional team just really combines folks with different skillsets to solve problems together. So a lot of times at product teams, you'll see developers coming together with sales folks and accounting folks and marketing folks, really areas that are out of their discipline to solve complex problems and create solutions. So one of my biggest pet peeves at conferences is when folks start off a session and they spend the first 10 minutes talking about their company and where they work and then they talk about a session that has nothing to do with their company. So I've always strayed away from talking about my company, who we are, but I think in this case it's really important to understand our journey and who we are and why cross-functional teams helped us get to the point where we are today. So we're a consultancy, we're a digital agency, we make websites, we make mobile apps, we just make cool things, digital things and just really enjoy the craft of software development and meeting people and solving problems and creating things. The company was started in 2009 with myself and a business partner. She was the design side of the house, I was the backend development side of the house. We just liked making things and we never thought that we would grow and we would have employees. So we worked in the company for about, we started the company, we worked for about two months and realized that we couldn't work on our craft, we couldn't build websites and then have another website lined up, sales, you had to have sales, you had to have that pipeline coming in and we learned really quick that it wasn't just gonna be the two of us. So we hired somebody to help us out with some proposals and then from there we learned that having somebody helping us out with sales and proposals drove more business. So then we needed another backend developer which led to another front end developer which led into more and more and more resources. So it was really growth is something that we really thought about early on and how are we going to maintain culture? How are we going to be able to grow and really get into making a company at that point because when we started the company we thought it was just gonna be us making websites and mobile apps. How can we create an experience for everyone? A keynote was really interesting when she was talking about vision and does everybody in the company know the vision of the company? And me being a founder, of course, I think, yeah, everybody knows the vision and I have ideas to go back to the company and ask folks, do you really know the vision? And I hope people know that we wanted to develop a place where people just like to make cool things and keep that going. So we operated for about six years with our cross-functional teams and we thought it was fine and then my business partner decided that running a small business was not for her. She's had enough and it was tough and she left and she went to Accenture. Very large consulting firm. Global, thousands of people. So from a company that had about 10 people to thousands of people, she had just had enough. So I was left with this company. I bought her out of the contract and I'm left with this company and how it worked before were me and her were managing the projects. At that point, I was still writing code. She was still writing code but we were just juggling so many things and then that's when it really dawned on us we really needed to change. So operated for about six years without cross-functional teams and then in 2000, so we implemented them in 2015 and we used them for, we've been using them around seven years now. So I'm gonna show lots of different org charts that we've had since we've been implementing them and I love talking with folks from different organizations and having them define what their roles are. So what is a front-end developer in your company versus what is a project manager in your company? What are their roles? How do they differ? So I think it's really important for me to go through and kind of define these roles so you understand what they are at GravityWorks and how they relate to your organization. So the first role is a front-end developer. We have the most front-end developers out of any role in our company. Front-end developer is, I would classify it as an old school front-end developer, HTML and CSS. Yep, I get that new front-end developers are using React, they're using View, they have those things but at our company it's really front-end developers are HTML and CSS. Back-end developers, C-sharp, PHP, going into the database, writing queries and then they're the ones who are traditionally coming in to do the React, do the View, do the complicated JavaScript frameworks. Now that's not to say that's all projects. A lot of our front-end developers are getting more into the View and the React and whatnot and they're pushing those back-end developers into their traditional back-end developer roles, creating modules and whatnot. But that's for intensive purposes, that's kind of where we are. Project Manager is the interesting one and we've had a lot of shakeup in the last few months at our organization with Project Managers. What I feel a Project Manager is, a Project Manager is the gatekeeper of a project. It is on the Project Manager to put their stamp of approval on a project before it goes out the door. It's their responsibility to talk with the clients, work with them on requirements, maybe not like a full spec document or whatnot, but work with them, understand it and then maybe you do have to go in, we're a smaller company, maybe you do have to go in and add some content once in a while. Maybe you do have to go in and test something at the very end, it's your stamp of approval. But as we're growing as a company, we're starting to hire Project Managers that are coming from larger organizations. And I definitely apologize for when our New Project Managers are watching this, but they're paper pushers. They are literally pushing a schedule, they're looking at it and then moving on to the next thing. And that's not necessarily a bad thing, it's just we as a company need to adapt. We have a lead front end developer, we have one individual who leads our front end team. We learned early on that through trial and error, we don't want him working on specific projects, we want him coming in when there's problems, we want him leading technology, we want him helping with architecture and leading the team and helping our other front end developers advance their career. That's the same with the back end developer, same type of role. UX Manager is somebody who is in management, but definitely has a handle on UX. Helps conduct research, helps do lots of different things, manages content strategists and designers and is more than just a manager for sure. Creative Director in our organization, our Creative Director still does designs. He's inside, he's doing designs. I think as we grow and we have more creative folks, I think that he will do more art direction and things like that, but as of right now, he's helping lead the vision of the company on the creative side, but he's still in there doing designs. Content strategists, I want to stay away from using a lot of idioms, but our employees have multiple roles and especially the smaller the company, the more roles you have, wearing multiple hats. That's an interesting idiom that I'm assuming came from police officers wearing hats and then a firefighter wearing a hat and who knows, but just lots of different roles, but our content strategists at the heart is developing a strategy for a website, working with the clients to write content and every once in a while they get pulled in and they have to do content entry as a site builder. Content entry site builder is definitely a newer role to us in the last couple months here. It's a role that the Drupal community introduced me to 10 years ago and I love this idea of site builders who are entering content and using modules and just putting together a site based on things and I'll get to them a little bit. Lead project manager, straightforward, they lead the project management team and then over on the right is kind of me, the chief operation officer and sales. Again, I'm an entrepreneur, I come from a small organization where I'm used to wearing multiple hats. So I jump in and I push the broom when I need to push the broom to help out. So I still do a lot of the sales. I do have some help internally sometimes from other folks helping me with the sales but I'm still doing the sales and I'll get to that one in a little bit. So on paper, when we first implemented cross-functional teams, we were around 12 people and we're coming off of me buying out my business partner. The company was kind of at a state where, how's this gonna look? How's it going to work? How are we gonna continue on when we had two figureheads of the company? And we brought in a project manager to mainly replace my business partner and he was really sharp. He's still with the organization, he's our lead project manager right now and he's the one who introduced us to cross-functional teams. And like I said, it looks very clean on paper where we had this flat org chart where everybody reported up to me. I was responsible for doing employee evaluations and reviews. I was responsible for having one-on-ones. If you had a problem with your insurance, you would come to me and ask me about insurance and benefits and all that sort of stuff. But you know, I'm an entrepreneur, I loved working 80 hours a week, it didn't really matter to me, I just enjoyed it. Project managers were doing what they did, they managed projects, they weren't managing people. I was the only one really managing people at this time. Front-end developers were off writing code and being happy, back-end developers were off. And then it was interesting over in the UX side, the content strategist and creative director. So the creative director at this time was just our only creative. He was doing the designs, working with the strategist doing IA and whatnot. But it was great, it looked awesome on paper. But it really turned into a mess. Mainly because what happened is that middle right there is project managers had a project and you may have been working with one front-end developer on one project, a different front-end developer on another project and really we had one project manager that was working with all seven, eight of those front-end developers. So they were really juggling a lot through there. Same situation with the back-end developers, project managers were working with multiple back-end developers, the UX team was all over the board trying to work on things and it just was really tough. The biggest thing, why we needed to use cross-functional teams was deadlines. What would happen is this front-end developer would be working with this project manager and would get laid on this project, which would delay the project that this project manager was working on, which then delayed this project manager. So all of these deadlines started to get missed and we were trying to bring in new clients and new things and deadlines were getting missed. So I give you cross-functional teams version one. Oh boy, this was a while ago. Like I said, this was about seven years ago. And where we get the cross here is on the left side. This team right here still had that front-end development team lead. So we weren't able to get him off of the team because this project manager really likes that front-end developer and wanted him on his team. So the cross was coming in here where we have front-end developer team, project manager team, so we go project team, team, and then project managers down there. So our project teams are teams that are working on projects. They're named, these names here coming down here, team RC, remote control, team nine to five. It's team nine to five, not because they work the hours between nine to five, but the Dolly Parton song, the singer nine to five. And then team Zeppelin. I don't know where that name team Zeppelin comes from, but it's got a cool little icon there. UX accorns, they're not just unicorns, they're UX accorns. So this was our UX team. We introduced it this time, the UX manager. So that UX manager was coming in to start doing a little bit of that people management. We realized that we needed not just project managers, but we needed people manager. Coming from open source, coming from agile methodologies, middle management just kind of really scared me. I wanted to make sure that the roles that we had had value, and it just wasn't there to be there. So you'll see that the back end team leader wasn't on a team, front end team lead was on a team, PM team lead was on a team. So again, we're still a small organization at this time. I think we're like maybe 15 people. So we had to wear those multiple hats. We had those multiple roles. And it was really tough for the PM team lead and especially the front end team lead to be able to manage two, four, six people, making sure that they're getting reviews, making sure that their career is being taken care of, but and still be expected to deliver on projects and whatnot. We had lots of conversations about back end developers at this time when we first implemented this and should we put a back end developer on each one of these teams? And it was said that there's no way that we'll ever be able to get back end developers on a team. It's just we have mobile apps that we're working on. We have a couple dot net apps that we're working on. It's just really tough to get it in there. So we agreed and we treated them as a shared team. So the UX team was a shared team. The misfit toys is the back end developer team. And they would come in on the project. You'd normally get like one back end developer on your project. They'd come in, they work and then they'd move on to the next one. And then the last one on the bottom here, which is kind of the start of like a truly functional cross functional team is we had our operations team. So with my business partner leaving, I wanted to make sure that the company had a voice. It wasn't just a dictatorship. It wasn't just me trying to lead this company into the future and do things. So we created our operations team, which at the time was our PM team lead who introduced us to cross functional teams as well as our UX manager. So right away we saw the benefits from this. The biggest benefit was deadlines tied to teams. They're not tied to the company anymore. So what we found happening was we were meeting more of our deadlines. Inside the team, we were still missing some deadlines. But as a company as a whole, we were meeting more of our deadlines. The work was more consistent. When my business partner left, we had quality concerns. I think you're not progressing as a company if you're not talking about quality and somebody saying we have quality concerns, but we have bigger quality concerns and breaking off into teams really put focus on employees to be able to look at what they were doing, have somebody reviewing their work. It really helped us out to provide a better service for the clients. Project managers now knew their strengths and weaknesses. That was really big. When you're working with six other front end developers, a lot of times you don't have the time to slow down, get to know your front end developers, get to know where they're good, get to know where their weaknesses are, and be able to say hey, why don't you go out to the team lead and ask for help. We know that you struggled with React before. Let's make sure that we're managing expectations. We set you up for success on this project and make sure that we're going in a good direction. Innovation and creativity. One of the big things that we were really worried about with cross-functional teams was competition. You saw they each had a little logo and that came against my advice. The teams wanted to have an identity, but I thought what was gonna happen is the teams would start competing against each other. I got five projects done this week. I got 15 projects done. I mean, from a management perspective, that's great, right, you're setting up this competition with people going back, but that's not the kind of company that I wanted to develop. I wanted to make sure that people were being healthy. They weren't working 80 hours a week. They're working normal hours, so I was really worried about that, but it led to innovation and creativity. That's where that competition came in, was seeing that this team is working on this cool project. Hey, can we get this cool project? Because we wanna be able to do this. Employee engagement went through the roof. I'm just one person and a smaller company, I wasn't able to have one-on-ones with many of the folks on the team, but this enabled it to that the cross-functional teams gave two outlets. You had your project manager that you could go to and you could talk to them because they're responsible for your career and then your team lead, your front-end developer team lead because they're responsible for your career too, gave two outlets. Business agility, we were able to move quicker. This one is one of my favorites, someone to advocate outside of the project space. So, project managers, their jobs are to get projects done. Sometimes they think of people as resources. They're cogs in a wheel and project managers are pushing to get projects done, to get things done, and we at one point had one project manager who just pushed and somebody would ask for vacation and the project manager would say, I don't think that works with our budget, can you push it out? And again, that's not the kind of company that we wanted to have. So, vacation requests are not approved by the project managers on the project teams. They're approved on the functional team, over on the specialty team. So, the back-end developer lead, front-end developer lead, they're approving the vacations. That way, if a project is getting close to the deadline and somebody needs vacation, they still can have that vacation and then maybe the project manager will wave their hands and yell, but then it's a conversation between the team lead and the project manager so that we're still thinking about people and we're thinking of people as people, not resources. A resource plan that can be forecasted, the true state of the company could now be completed. Oh man, we used to sit in these meetings on Fridays and we called them the resource meetings and everybody would come and they were uncomfortable because we had that big mess of people and everybody saying, I need this person for this many hours. I need this person and when somebody wouldn't get the hours that they needed, they would pout, they would be upset, they would be mad and it was just an uncomfortable meeting. Now, you resource inside of your team, okay? It gets great if your project's being pushed out, you gotta call a client and if we need to get you more resources, we'll have that, but we could then create a true forecasting plan that we could resource out like six months. Oh, this slide. Our creative director did the slides for us and I think he saw the word specialty teams and thought of American football with the kicking team. I am not a fan of American football and he put a comment in my notes and it says, could make football reference joke here for European football or not or remove the player? I'm not gonna remove the player but I'm also not gonna make a joke but I much prefer European football than American football. Anyway, project teams versus the specialty teams. Let's see what I have for notes here. I think I kind of talked with most of these. We can talk a little bit about meetings. And so, I think I have that in the next, I have another one we can talk about meetings. So I guess I could have got rid of the football player altogether there, maybe I should have did that. Okay, cross-functional teams version two. So our cross-functional teams, we worked in with version one for about four years. I don't think we had any major problems with it but four years into it, this is going about 2019. We hit the pandemic and a lot of things were going on in the States and we introduced another specialty team down here, our DEI team because we had the question, do we feel as a company that we're doing enough? And the answer to that was no, we didn't feel that we were doing enough. So we created a team to do that. We still had the operations team, I just didn't have enough room to put them down there but specialty teams, we still had the operations team, we have the DEI team. And the DEI team is the first time that we have somebody who is the leader of the team that's not managing people. The leader is a front-end developer and it's a true cross-functional team where there's front-end developers and project managers and myself and UX folks all coming together to talk about DEI things. Other interesting things on this is we have a new team, Team Jupiter. We had a large project come in that we needed another team for. So we ramped up really quickly. We hired a new project manager and what we did was we took the new project manager and put that project manager and two new front-end developers and long and behold, we were able to pull out our front-end developer team lead out of team nine to five there and he was able to start doing what he does best. Leading the team, helping with hard problems. Yes, he is still booked more hours in the day than he possibly can be, but he's booked on the things that he probably should be working on. So going back to the teams and what happens with the teams. So the day-to-day of the project team we're a remote company like most folks are nowadays. And one of our keys to success that we think is communication and inside a Slack we have a Slack channel called Daily Status and the only, we don't want to put rules around it but we just ask every morning when you come in and start work just let us know what you're working on. And the idea for that is we don't want to call you before you start work. We don't want to, you know, bug you if it's like a Slack thing that you can just talk. Project managers, team leads, all know to look at that channel before they pick up a phone or try to DM you. It's really to allow the middle management to leave you alone so that you can focus on your work. That's morphed into folks do that in the mornings. When they get up to go walk the dogs, they say away from keyboard, going to walk the dogs. If they take off early, taking off early we'll be back on later tonight. And it just works great because there's been a lot of times that oh I need to talk to this person. I go look in Daily Status so they're away walking the dog. I don't bug a mother away walking the dog so it definitely gives them their privacy. Team stand up. This is one that is implemented not on all teams. Not all teams want to do a stand up every day. Some teams do a weekly meeting. Some teams will do a, these are on the project side. We'll do a weekly meeting versus a stand up. On the specialty side, the front end devs, the back end devs, they all have their own meetings. They meet once a week. UX team meets once a week. Project managers meet once a week. And the idea is they don't talk about specific projects. Projects come up of course but the idea is to talk about, look at this cool technology I used on this project. Or hey I had this problem with this client on this. How would have you dealt with it on the project management specialty team? They do client meetings of course. I think like every organization there's just way too many meetings. We really try to get rid of that and then those daily stand ups try to get rid of those. And in many situations that we can. Dedicated time on new projects and then dedicated time on support. So this is the interesting one. So at a given time a team's working, a project manager at GravityWorks is working between seven and 10 projects I would say. They're kind of juggling seven to 10 projects. What we call active projects. Those are projects that the UX team might be working on a sitemap forum. They might be in design. Maybe the front end developers are working on a project. Doing some code on it. Maybe a site's getting ready to launch. Those are active. But we still have all of this technical debt from 13, 14 years and being in business. A lot of older clients. How do we deal with support? This is something that again I'm getting a lot of pushback on recently. But right now the project stays with project team. So if Team Zeppelin created a project 14 years ago and we have new front end developers on that team, they still maintain that project. The nice thing about that is if a front end developer leaves you still have institutional knowledge of that project. It's nice that that institutional knowledge is there because where I'm kind of getting at is eventually we want to implement a new team, a support team and the support team gets all the support requests that are coming in. The problem with that is they lose all that institutional knowledge on that. A lot of times the requests that come in, two-minute fix done, two-minute fix done and they're able to push it out a lot. We have a couple teams that are really struggling with support where they have a lot bigger type issues that are coming in and I'll get to other teams hopping in to help out in those situations in a little bit. So when we first started implementing cross-functional teams there was a lot of what-ifs. What if we get a new project manager? We didn't have to deal with that until seven, eight years into doing cross-functional teams. What I learned is it's okay, right? We want to make sure that your stay at our company, you're learning as much as you can, but we understand that you're gonna move to a different organization eventually. What we found is the other team members on the team really stepped up to help fill the knowledge gap between the project manager. The project manager team lead took on that role. So he was managing his role for his team that he was still on a project team, but he would do the meetings, do the client meetings, start pushing things through, and yeah, it was more work, more incentive to get somebody hired quickly to get them on boarded. When the new project manager was hired, the front-end developers were really able to get them up to speed really quickly because of that institutional knowledge. So it's a lot of benefit with institutional knowledge having these teams like this. The team is missing dates. Yep, dates get missed all the time. Why were the dates missed? Is a lot of times we go back, we need to talk about that. Was it the client? Was it our fault? But if the dates are missed in the team, it's just a date, right? It's not affecting the whole company and it's not affecting the reputation across hundreds of projects anymore. It's just affecting that particular one. We have a difficult client. This kinda is contrary to the institutional knowledge, but a trick in project management is if you have a difficult client, a lot of times what you can do is you can just switch the project manager and then all of a sudden that difficult client clicks better, they get along better with the other project manager. So we've done that and that's been beneficial in cases where we've just taken a project, moved it over to a different team and then the project is an excellent project now. People like it, people are great, people are happy with it. We have a developer leave. Institutional knowledge, developers are gonna leave. It's okay if you leave. It's okay if you leave. I'll get to hear you, right? I have a couple of developers here and sometimes I get emotional. But it's okay if you leave. We wanna make sure that you have the best possible time while you're here and if you leave you have another front-end developer that has that institutional knowledge, you have that project manager. So we'll get through it. I mixed those up. We get a new project. So we have a project manager leave, I talked about that, but we get a new project. This really comes down to resourcing. And there's a lot of emotion that comes into it. I think a lot of it is cognitive overload and I think that the number seven feels like a lot of projects but when you put it down on paper and you actually look at the number of hours that you're actually managing maybe you're not spending that much time as you would think that you would need to on seven projects. So we look at our resourcing plan. I'm gonna show that in a little bit to see which team seems like they could have the availability to take on the new project but then also that cognitive load on the project manager. One project manager has 15 projects. Is it okay to give them another one and it's really dependent on people? And that kind of goes into we have too many projects. I'll allude to some of that in a little bit on a couple different things. Okay, cross-functional teams version three. Let's see what's different here. Remember when I said when we first implemented it that there was no way we would ever be able to get developers on a backend team? Well, look at this. We have developers on backend teams now. It's working, it just took some time to get some projects shifted and projects completed. We have a team that does web stuff but also does our mobile stuff. So the developer that is the mobile dev is on that team and he's able to get things done. The other interesting thing on here is all the way over on the right there that project manager team lead. Oh, he's not out yet. That's a different one. Can't see, sorry. The backend team lead, he got pulled out. So backend team lead is out doing what he needs to do managing careers, helping people out. And look at that UX acorn team. That one has grown. So there's another designer in there. The content strategist is still there but now there's two site builders inside of there too. So we've seen a big increase with UX and needing to do UX type things. Process team, still the DEI, same folks on the DEI team and then the operations team still kind of chugging along there. So the difference between V3 and V4 moved really quickly. As soon as we got developers on backend teams, folks really saw that we need to change things up. We need to get this back into traditionally have these crosses and have teams and have these project teams. We pretty much pulled everybody out of the UX team and we're trying something new. As in this is like in the last two weeks we started working on this plan right here. We have a dedicated designer that is shared only between two teams. So that creative director is on two teams. The designer's on two teams. Same with the site builder. The site builder is being shared by two teams. This is limiting that project management of people going back and forth with different things there. And this has definitely seemed to help. This is where we've been able to pull that project manager out of the actual team so that they're able to, if we do lose a project manager they're gonna be able to help a little bit more with the duties and work on that. And this is now getting much cleaner and where I would expect something like this. What's happening though, I'll show you the kind of ideal situation. Actually I'm gonna skip that for now. It's kind of funny what's happening as we're starting to get more people on each team here. So Harvard Business Review did a study and there's a link in the slides here that say 75% of cross-functional teams are dysfunctional. I'm glad they use the word dysfunctional and not the word failures because I think the word failure is different depending on who you ask. So the criteria is meeting on three of these five criteria they failed. Meeting a planned budget, staying on schedule, adhering to specs, meeting customer expectations and maintaining alignment with companies' corporate goals. So they fail on at least three of those. Meeting a planned budget, budgets are hard, right? And I think that one of the ways that we're successful with managing projects is we try to take money out of the equation as much as we can. Yes, we need to have money to survive and grow our company and do things but that's gonna be the biggest contention a lot of times is we come back and say we need 100 more hours. Well, why do you need 100 more hours? And then we justify different reasons for it. It's not to say if somebody changes the spec on us we're gonna go back and say we need more money definitely we'll do that in that situation. But a lot of times we're over what we planned on because software developers are not great at estimating. I don't think anybody's great at estimating. I have two children, I have a seven and a 10 year old and I've started early. I've said how long does it take to walk to school? How long does it take to get to the grocery store? How we constantly do these things to learn how to estimate because human nature we're just not good at estimating. Definitely we at GravityWorks, we go over budget a lot. Staying on schedule, I think that you have picked up that we're laxed on schedules sometimes. We're laxed on schedules sometimes because we value doing it right versus getting it out the door. Adhering to specs, if the specs are correctly collected which is tough to make sure that you're getting everything out of a client and all up front, agile, whatever. We follow specs, we'll do that. Meeting customer expectations. Yeah, so I think for the most part I think that we are functional. I would like to say that our cross functional teams are functional but I think that there's dysfunction in everything that you really do. So the keys to success with cross functional teams. You need to define a leader. You notice in the DEI team it doesn't need to be a people manager. It just needs to be somebody who's passionate and can lead the team that they're working on. Clear goals. Project teams, very clear goals. We're gonna work on projects. Front end teams, we're gonna develop your career and make you the best front end developers we possibly can. Knowledge sharing between the teams. We have cross functional meetings where back end developers are meeting with the front end team. UX teams meeting with the back end team and it's crossing over and doing these meetings. Sometimes it's very difficult to get people to give agendas on what you wanna talk about but at the end of the day when those meetings happen they're just great information to get people together and have innovation and creativity. No competition. We're one unit. We are one company working towards our goals to do great things. Let's see. The team must have both authority and accountability. Super important especially with the project managers to be able to give them authority to tell the client we'll credit you this amount or give them more hours. They have to have the ability to be able to do that. And adequate communications must exist. In essence we're building silos. We're building these silos of our front end developers and back end developers. So there has to be communication across those silos and we get that and it's okay to build silos. We're okay with that in this situation because we communicate back and forth. So kind of going into the end here, wrapping up with some of the problems that we've encountered. Team members can get bored. Making sure that they're working on projects that excite them is very important. It's not obvious when to scale a team up. We talk about a project manager can handle 10 projects but the project manager has two front end developers and they're working on things and they're light and when do you get another front end developer on the team. Sometimes it's not obvious on when to scale up can lead to many meetings. This is something that we struggle with in our organization like lots of other organizations. Support can derail a project. We talked about that. A big support thing coming in can affect timelines on things. We don't do a great job sharing the success of a project team to the entire team. So we have a weekly meeting on Tuesdays where all of us in the company get together, we chat and whatnot but we don't do a great job about project launches and the success of an individual team. So I'm gonna rush through the last couple here. We use Asana for task management and this is a portfolio for a team. This is actually team nine to five for last week and you can kind of see that it's great. The forecasting is going out great for a week but it's not six months. For an individual, we can drill into an individual. We can see we track holidays, vacation and holidays. So going to Drupalcon Europe is definitely a vacation and it's not work, it's not hard, right? No, it's definitely hard, it is very hard work. Here's maintenance. So this is a client that is a bigger type client. We forecast that this client is gonna take roughly five hours a week so we just kind of put that across there. So if those hours come in, great, we have it. If they don't, we can put it someplace else. So the last kind of slide that I have here is cross-functional of the future. I kind of laughed and kind of giggled a little bit and looks like the slide's getting a little bit cut off there. But I think given the opportunity, folks would like to have every single role on every single team. They would like to have multiple front-end developers, maybe even multiple back-end developers, a UX designer, a site builder. They'd like to have a business analyst, customer experience, a QA person. Where does it end? How much money do we have to spend to make these sort of teams on here? So I think that as the company grows and it gets into this, what makes sense? Because we are looking at hiring a business analyst but can a business analyst handle the amount of projects that we have? Are we gonna overwhelm that business analyst so fast that we have to hire a second business analyst right away and kind of do the thing that we're doing right now with site builders where they're kind of balanced between the teams? So definitely some challenges that we're looking at into the future. So I think I'm gonna add about time but I have some time for questions here. So thanks everybody for having me. How do you deal with missed deadlines with clients? How do you deal with missed deadlines with clients? Ideally we wanna have the conversation upfront and have it early as possible and have good reasoning behind it. We try to avoid things. Like if the project is around a holiday we make sure that we have conversations to say that we're gonna have these folks out when vacation comes up we let the client know. This was an interesting situation recently. We had a client where it was two months before their launch date and we told them we're not gonna be able to meet your launch date but we're able to provide you with a subset of functionality. The client called us incompetent. It was not their fault that we were missing the deadline. It was our fault because we were incompetent and what we needed to do in that situation because we couldn't push the deadline out is we borrowed front end developers from other teams to come in to meet it. But luckily we gave the client two or three months notice that we weren't gonna meet this date so we still had plenty of time to pull from those other teams which we don't like to do because it affects those other projects but we were able to shift schedules and some other things to do that. So we don't like to miss deadlines. In that project we did release with a reduced scope level but the things that we're missing were just a couple of features and we were able to get it out in the next couple of weeks. And this is the first time that the developer is hearing that the client called us incompetent. So we kind of shielded you from that. Yeah. Sure. So if a developer is on sick leave or vacation how do we handle that? Bigger ones like maternity leave and things like that we wanna make sure that we have it scheduled and we find a replacement to make sure that we're able to handle that. Short term, two weeks, three weeks we really try to focus in the project and let the client know. We know that clients wanna get things done quickly and everything but at the end of the day the sites that we're working on they're websites, they're not medical sites they're not emergencies that you absolutely have this out. So we really try to get a lot of understanding from them to say we have this person that they're out it's gonna stretch your deadline a week. We can pull somebody in if we absolutely have to but are you okay with it? But just being human and being open a lot of times handles it. Sure. So the question was do we have a solution architect that is part of a shared team that kind of goes through each one of those? That kind of goes to the back end developer role the lead back end developer role and the lead front end developer role and that's why it was important for us to kind of split those out of those teams so that when those big projects come in they have the availability to hop on that to work together as a back end developer and a front end developer develop the solution and then work with the specific project team and then move on to the next team. We do not have a lead tester. So that we like to say that if you wrote the code you should have somebody else testing it so back end developers will test their code sometimes front end developers go back and forth but that kind of goes to that beginning statement of the unique project managers that we had that they put their stamp the seal of approval on if you have good specs and the developers are writing test plans and everything a lot of situations are project managers were going through and doing those testing but I think that's a really hot topic lately especially at our organization and we've looking into that more because like right now cross browser testing is done by the developers the front end developers accessibility testing actually goes up into the UX department because we have folks who know how to do that so I think having somebody dedicated to that but then that leads to question if you have one tester are they gonna be able to handle the 30 projects you need two testers or four testers to work in this environment? Oh question, sure. So the comment was recommending against a dedicated support team keeping it inside of the teams mainly because a lot of organizations put the junior people on the support teams there you lose the institutional knowledge no I agree with that 100% and it's constantly gonna be people fighting to get out of the support role and get on to I want new projects and it's nice to have a balance you know when I was a developer I liked having that balance I liked working on a new project and then oh man this thing came in and I have to spend four hours trying to figure out something I wrote 10 years ago I used to enjoy that but not everybody's the same all right thanks everybody have a great rest of your conference