 So, I guess just to get started, even before starting, I want to acknowledge that this is a little bit ambitious as far as the scale of what I'm trying to cover. So two things, definitely feel free to ask questions and delve in deeper on topics that you want me to go deeper on at the end of the session. Use the mic and we can get the whole thing recorded, that would be great. The other thing I'm going to do that's kind of come out of talking with this presentation about other people is between now and when I represent some sort of an updated version of this at the PM Summit in October, also here in Austin actually, is basically put together a blog post or series of blog posts on the ten or so slides that in and of themselves could be hour-long presentations. So with that, I wanted to call this, oh look, we're growing because at least the way it's happened to us is it's been a two-fold, part of it it was a conscious decision and the other part of it is you know you're doing something right when your organization feels the pressure to grow without you doing anything to it. So who am I? I'm Adam Edgerton. I'm the Director of Operations at Meadow Toad. We're out of Portland, Oregon and I have basically a project management background. I now hold the Director of Operations title and so that basically means I kind of have one foot in the internal workings of the organization and on the other side of things I manage the project management team. So the biggest piece there is as of six months ago I no longer day-to-day manage projects for our clients. So I'm curious and thank you by the way for everybody sticking around for the last session before the closing session. I really appreciate it and I especially appreciate you coming to this one. So I'm curious who in the organization is a freelancer or a sole proprietor if you could raise your hands. Okay, a few. How about the two to ten person organization size? All right, quite a few. How about let's say ten to fifty. Also quite a few. Fifty to a hundred. Okay, a few. A hundred plus. Okay, and what about say a thousand plus if there's any mega corporations. Awesome. So pretty widely represented and how about agency or service organization side versus client side? So agency side and client side. So mostly agency. Okay, perfect. So I did want to touch on what is Meadow Toad just a little bit because I realized the first time I gave this presentation at a local meetup group in Portland people came back and said yeah that was great but you know I didn't really realize how developer focused you guys were. So while we do you know essentially everything in the digital spectrum to some extent or partner with other partners on it most of our staff is development. We produce sites so we have designer on staff but often when heavy creative is called for we partner. So if you see me saying developers a lot just go ahead and insert creative or UX architect or whatever else you might be thinking that is really relevant to your organization. So some important background is where have we been and I really want to touch on this because it's really only one iteration of growth that I've experienced in three years at Meadow Toad. I joined in 2011 and we were about ten people and as of just recently we're 35 and on a trajectory to be 40 plus by the end of the year. So there's much bigger organizations out there and obviously on the smaller side of things you also have different problems to deal with and so we're kind of at the point now where I've already thought about what 50, 70, 100 people could look like but I also want to really focus on relying on the experience of what growing from 10 to 35 is meant. And so that's meant a kind of forming of a real project management team. We've gone from two project managers to now five plus myself. Our project team size or our core project teams have gone from often sometimes as little as a single dedicated team member, maybe two to three up to now three to eight seems to be the common range. Average budgets have gone from anywhere from 30 to $80,000 to 200 to 500,000 or more in some cases. And surprisingly enough average timelines for project engagement haven't stretched that much at least compared to some of the other numbers. Instead that's why you see the team size growing a little bit. So where are we going? Basically I wanted to touch on this because as you'll see in the next slide there's some good reasons to go and there's some bad reasons to go. And a good reason to grow is because you have a reason to do it and a reason to get somewhere specific. So we started as a web shop. We do a lot of Drupal still. We did a lot more Drupal in the past even compared to our current mix. But really where we want to go, I think basically our founder I've heard him put it as he wants to steal 1% of Oracle's market share using open source. So to do that obviously requires a bigger organization. To have some of the varied skill sets we're gonna need requires a bigger organization and to work on the type of projects we wanna work on requires a bigger organization. So a few asterisks because I'm sure everybody in the room who wants to grow, raise your hand. All right, so it's a double-edged sword. There's a lot of reasons you may not want to grow. When you're a service organization, I think it was Seth Brown at a Drupalcon presentation last year, said as you get bigger you don't necessarily make more money and that's very true. As far as your profit goes, the extra collaboration, the extra meeting time required on a per project basis but kind of on the organization as a whole, you might not make more in profit at $10 million than you do at $4 million. So that's something to think about. And that's where I think everybody sees the silver bullet into well, I'll just pivot into product because that scales better than linear. And that's actually a lot harder as you've probably heard at several of the sessions this week. It's a lot harder said than done. No, sorry, it's a lot harder done than said. And so kind of like I touched on growth for the sake of growth is actually really dangerous. You need to have a purpose first because otherwise if you don't have some sort of very clear focused line on where you're going, you're gonna grow in a very non-direct path and you're gonna have layoffs along the way, you're gonna have bad quarters, you're gonna have good quarters. So stay very focused. And the other thing that's a lot of, it's hard for a lot of us to grasp. It's hard for me to grasp some days is pure tribal organization at some point starts to break down. And I want to say that's around 25 people where it really a little bit more structure is called for. And the trade off with structure is red tape and bureaucracy. So I would advise you all grow to the point where you're comfortable with the level of red tape. And if you see it the next step in the next evolution in your company being just a little bit too much, you might be okay where you're at and you might want to consider turning it into a little bit more of a lifestyle. So why a project management approach? I kind of wanted to talk about this because I think project management is uniquely situated in the organization. They see the big picture. They have both the business in mind as far as project risk, project budgets, project timelines. They also see the customer needs. And in most organizations, metal to included project managers, project managers are directly customer facing. So given that it's a really healthy place to be to see what the needs of your customers are as you grow, what the needs of your business is as it grows. Project managers are often the planners, the risk averse type. And entrepreneurs who start businesses are often anything but. So it's a very healthy check to that sort of role. Project managers aren't necessarily great entrepreneurs because they're risk averse. So you kind of need that person pushing you forward a little bit uncomfortably. But the project manager kind of provides the need to balance. And kind of like I touched on, growth creates risk. Growth really is risk. It's just pursuing the unknown and trying to figure out where you might end up and predict where you might end up. And before getting to the agenda, the other thing I want to touch on is two types of growth. They're scaling organizations and then they're scaling projects. And you really have to balance the two of these as well. You can grow an organization and you can grow projects independent of each other. But the danger situations to end up in are $10,000 projects when you have 100 people in your organization. And so just the chaos and the inefficiency of even trying to collaborate at that scale is a mess. The other way is if you're a five person organization and you're working on a million dollar projects, that's a huge amount of risk to take on from a business perspective. Where if you lose that client and you don't have something else waiting in the wings, you could be out of business in a hurry. So really these two kind of go hand in hand to me. So because I'm a project manager, had to have an agenda. I want to let you guys know what we're going to look at. But I did want to touch on the order. We're going to talk teams, then people, then process, and then tools. And that's partly because I'm a big believer in agile manifesto, probably more so even than most agile practice as a whole. And one of the core tenets there is individuals and interactions over processes and tools. And if you've ever read a blog post or heard me speak, that's something that I've definitely talked about before, where you really have to get the team dynamics right. Otherwise the process and the tools, while important, don't ultimately matter. Following that, we're going to kind of talk through a little bit more of the project management approach and some specifics. And then I wanted to wrap up with kind of talking about coping with growth because growth is hard and kind of painful. So within teams, I wanted to start kind of at the smaller core level of talking about project growth when it comes to teams. And if any of you have read the book, The Mythical Man Month, one of the things it talks about is something called Brooks Law. And Brooks Law says that adding more developers to a late software project makes it later. I think probably some of you have experienced the talks directly to this. Healthcare.gov, the core cover Oregon website, where you talk about $100 million website projects and 100 plus person implementation teams. It falls down and as things get late, they've tried to add more and it doesn't help the situation. So think about this even at a smaller scale. Even if your projects are five people, six people, by the time you spread your project duration out and you have nine month projects as your average say, you know, the ramp up and the time required to get somebody on board to actually contribute to a project at seven months, I would say is probably 10 times harder than it is in two months in. And very similarly, I think it was Amazon that kind of coined the notion of two pizza teams. But basically Amazon, even at a massive scale, has always tried to stay a divisional organization. And so that's kind of what we've looked at at Metal Toad and we're getting, we're kind of in this mid transition phase where as we get bigger, this is going to become more and more of a need. Right now this is just naturally our project team size that we want to gravitate towards. But when we have 50 developers on staff, it's something that we're really going to have to reinforce for ourselves. And part of the reason I think that's been a big thing for us is that beyond that point, I've actually done some research and wrote a couple of blog posts a couple of years ago. Beyond a certain point, while you achieve scale with a project manager's time from a budget perspective on a project, as you scale of your project team, the amount of meetings and collaboration required just to get anything done also goes up significantly. So the theory is, you know, at 100 developer team, you might spend 90% of your time just meeting, trying to figure out what everybody is doing. So that's where the five to eight for us has worked really well. And that's where the two pizza essentially is a team size that you could feed with two pizzas. So it depends how hungry you are to some extent. I wanted to touch on collaboration and first acknowledge that, yes, it is a buzzword. It's almost as bad as innovation. But that said, it's an important one. And so I wanted to think a little bit about pair programming, swarming, and meetings in general, where they all have really positive impacts when they're used right. But as teams get bigger, as projects get more complex, always focus on what is it you're creating because I've seen a lot of teams devolve into essentially trying to stay organized and trying to plan what they're doing more than actually focusing on what we still need to ship something at the end of this project. So it has to be that careful balance. And with that, now I wanted to kind of take that and scale that up to the organization level and talk teams at the organization level. So kind of where I see metal toad going is teams as many organizations. And this is a concept that actually fits well with kind of the two pizza team idea. The thought is we're not there yet because we don't have enough duplication of people or I guess redundancy in roles where we can essentially create teams that are complete units. But at 50, maybe 60 people, I think we're gonna reach the point where we'd rather fight the battle of making sure knowledge is spread amongst diverse teams that aren't on the same projects and fight the battle of trying to resource and plan all of our projects from a developer pool of 30, 40 developers. At least to me, that sounds like a nightmare. So essentially what this means is at some point you have 10, maybe 12, maybe 15 person, many teams within your organization. At the top of that, there needs to be some sort of technical lead. There also seems to be some sort of a business lead. And that could very well be a project manager's evolution in the organization is into that role that sees the account side of the business, that sees the business needs and the business requirements. And it's also the experienced project manager who can mentor other project managers on the team. And ultimately what that turns your agency into is kind of a holding company. And so you diversify your risk across instead of five to six projects. At some point it's across four, five, six, seven, eight teams. Departments, departments happen, unfortunately, or fortunately in some cases. So as we've grown, we now have a true project management department rather than a couple of individuals. We have a development department, obviously, but that's now broken down into managed services, kind of our core production team. And then we also have a strategy team, which kind of serves as a stand-in for our sales team. But it's much more focused on getting up in front of a whiteboard and planning a technology solution than it is pushing a sale. The main risk to call out here and the concern to be aware of is the matrix model. And so I don't know if you're familiar with this, but essentially this is what the matrix model looks like. And in the worst cases where I've seen it employed, it means that essentially each person on a team has two managers. They have whoever their essentially vertical manager would be in their department. So a director of development say. And then they have their team manager. And so that could be the project manager or the business lead. And the dangerous thing here is you don't, you have people who don't have the autonomy they're looking for all of a sudden. You have mixed messages coming from multiple managers. So I'm really a big advocate for project managers to actually not have a people management role on their teams. I'm much more a fan of project managers being a part of the team at the same level as your developers and your creatives and really focusing on the business and the client outcomes. And that's been a really healthy thing. Yeah. Just a quick question. When you say project managers, are you using it interchangeably? Not necessarily. This is kind of the graph. So the question is am I using team lead and project manager interchangeably? That's one person who I think could fill that role depending on your organization. But that is a good comment to make because I'm also talking producers, project managers, product owners, your organization may call them something slightly different and they'll have slightly different tasks, but they do fall within a similar category to me. So metal toad, we've used project manager and we've actually talked about changing the job title but haven't figured out what we change it to. So now that's kind of the overall team perspective. Let's talk about the people on those teams a little bit starting at the project level. So I think when we were 10 people we didn't actually give enough credit to the fact that every developer's skill set or every creative skill set is a little bit different. I think when it came to resourcing and how we put people on teams it was a little bit too much. You know developers are developer and so let's stick one here and let's stick one there. You know this one needs three people so let's put three people there. So even at a young company size you can really start to think about and even label to some extent who are the junior developers who really need to be mentored? Who are your core developers that just get things done? Who are the seniors who are gonna grow into architects and really are the people who want to mentor? And we've actually as we've grown established this as a program at Metal Toad where we essentially bring in juniors in a two-year program the production and the results from their development are actually the emphasis on that is lessened. The emphasis on wanting to contribute, wanting to learn is much greater and instead our seniors who are doing the mentoring are actually responsible for the outcome of what those junior developers code. But definitely think about the diverse range of experience you're gonna get on teams and you have to end up balancing that across your projects as you get bigger because if you try to throw all the juniors at one project or even all the new employees at one project you're setting that thing up for failure. This one I actually grabbed from the University of Oregon Business School when I was there and it's really, I think it's an interesting way of looking at team dynamics and it kind of groups people into four categories. So you've got your thinkers and often these are the architect types, the maybe the big picture planners for projects. They're also often not the best at actually getting things done because they love to just sit down and plan all the time. There's the doers and these are often project manager types. They can be developer types too. These are probably as a project manager some of your favorite developers and some of your favorite creatives if you have some on staff. There's the challengers, the devil's advocates so to say, also a very important role to have on a project because if you don't have this represented you risk group think and you risk doing the same thing over and over again without really thinking about why you're doing it. And then there's supporters and this is kind of the cheerleader role. This is the person who when everybody's burning towards the end of the project is going to say, hey guys, we can do this, let's get it done and be there for the team. And I think what's really important for the project manager role to think about in this context is that your team is gonna have some of all four of these and people can shift roles even throughout the duration of a project. But as a project manager you really need to think about are there gaps in any specific time is somebody not playing one of these roles? And if so you need to embody that role. If there's no challenge or you need to challenge if there's no supporter you need to support. And I think that's really kind of a core thing to basically making sure your team is collaborating well. There's also role specialization that happens over time. So we've kind of identified some people are more focused on DevOps, some people are more focused on front end, some people are more back end. And as you get bigger and as your projects get more complex specifically you have to both identify who are the right people with the right skill set and the right background for a project. And often like at the 35 size right now, far too often we only have one person on staff who's this is the person for this specific task on the specific project. And so that's why I'd actually say 35 right now is a really awkward size for us because we want a little bit more redundancy than that. But you also have to kind of look at who's willing and excited on the project because I've seen people who don't have the knowledge yet but are excited and willing to learn do a better job just because they spend the time and they spend the extra hours when necessary to go learn it. And when it comes to people kind of at the organization level talking about them at the employee level this also applies to project managers. When you're small I really enjoyed wearing a lot of hats and being a strategist one day and a key way person the next and a project manager all the time and an account manager some of the time. As you grow you really have to focus and you're gonna have to help your team along in this focus as well because they're gonna have to pick their spot in the organization as roles get more closely defined. But as you do that it really gives you the depth of the field that you get to focus in. So I've seen people who are resistant to this and you can often find the generalist roles at any size because I'm such a generalist I've kind of forced myself up to the level in the organization where I still get to be a generalist and wear a lot of hats but it also gives you the opportunity to go really deep on a specific area. So a lot of our developers some of them go more into people management some of them go into you know what I really wanna master the backend and that's my role. You get some awkward resourcing going on and this happens in different phases. At 35 we're in this weird intermediate zone where we don't quite always get dedicated developers on projects even though that's what we strive for. But at 10 people that just wasn't even a reality. Like we either put one person full time on a project and hope they can handle everything or it was like a third of a project or sorry a third of a project manager's day third of a front end's day third of a back end's day to get the project done. So given that you have to just kind of be aware of when this is happening and try to grow past it or find ways around it. So for instance at 35 right now we're very close to almost fully dedicated developers on every project. I hope by the time we're 50 we get there but at this size we're still not too dedicated project managers which is also a really nice thing to have. And so even at a half million dollar project usually our project managers are still managing two to three projects at a time. I'd say it's probably the million dollar mark where we can actually dedicate them. So there's a good reason for growth there and that you get better quality on your project simply by having dedicated teams throughout. So talking about process now on the project level obviously this one's kind of a no-brainer but your life cycle is going to get more complex. It's going to have more defined phases throughout it. And this one's one where process is inevitable. You really need it to survive. But again this is one where you have to balance and always think about am I creating red tape or actually am I doing something helpful and something reusable and something that's not going to get in the way. Cause really when I call out what the project managers role should be it should be two things. Should be identifying risks and mitigating them and it should be helping your team work better. And yeah you might do 50 different things in a day but in theory you should be able to lump every one of them into one of those two categories. So this is a big, this is probably my biggest reach in the entire presentation but I'm going to try to solve the agile versus waterfall debate once and for all in two slides. We'll see if I can do it. So at a very basic level it's all about uncertainty. It's well-defined projects, short timelines, variables aren't going to change, business needs aren't going to change. Sure, do waterfall. As soon as you have enough uncertainty there's a high likelihood that you know what six months down the road this isn't actually what they're going to need or you know what they don't know what they want well enough to actually get started or we think we know what they want but they don't know what they want. There's so many variables where if there's any uncertainty beyond being able to essentially write a technical specification then agile might be called for. So I wanted to kind of introduce the cone of uncertainty which you may have seen something very similar to this. The horizontal access is essentially time. I don't know if this goes back as far as the beginning of time but essentially it's the beginning of the project wherever that might be. That could be a year before you've even heard of it. That could be your client's team is talking about something as just an idea and by the time it gets to you whether that's an RFP format or you get in the door before the RFP it has a lot more definition to it. So and then the vertical access is essentially the uncertainty measure. So not surprisingly early on in a project there's more uncertainty on ship day hopefully there's no uncertainty but that's never quite the case. So basically this question you have to answer for your own organization is where does your divider line happen in this? And so you can kind of see my dotted line there. That's my representation of for metal toad and I didn't put any measures on here but that's kind of our point where you know what things are well-defined enough and given this client's approach and their knowledge of what we're doing waterfall is actually a little risk here and it's gonna allow us to get the job done better. Anywhere left to that line water or agile is probably called for with the big asterisk there of if you're gonna spend more time teaching your client agile then it's gonna take to complete the project waterfall is probably called for. Otherwise you can always land somewhere in the middle and I don't think I've ever seen anybody doing pure waterfall or pure agile in an agency recently. So it's again a spectrum of more agile versus less agile. And when it comes to customization or standardization this is another reason actually why agile is hard is because when you're a service organization you really have to follow your client's process. You're always gonna find less resistance if you mold yourself a little bit to your client. I mean stick with your core process sure but find the ways to make it that much like knock down the two or three main barriers for the client simply by using their tool versus yours or by communicating status updates the way they're used to doing them internally. So you're always gonna have to have some sort of a custom process might take on it. And when it comes to process at the organization level in a very similar manner hopefully you have some sort of framework for your process. So I intentionally don't like our team documenting things down to the detail level where every step of the way is documented and there's essentially a guide that you hand to a new project manager on day one and say go just do all this stuff and you'll be fine. That's a little bit too much. I try to hire project managers who are smarter than that who want to do things custom and want to serve the client better. That said having some sort of a framework around what you do as an organization and the key things that you have to do to be successful is really important. So Metal Toad has this concept of stage gates and stage gates is essentially I think we have a couple of different versions but in one of them it's about 19 checkpoints throughout the course of a project where it's things like do we have some sort of specifications in place on a more waterfall project or on an agile project is the backlog healthy and sized by this point in the project. And that's one where we found if we don't do those sorts of things we end up failing more often than on our projects or at least it certainly increases the risk on projects significantly. When it comes to documentation I really like to take an approach of why not what because again I've seen a lot of documentation that's step based. It's basically here's the process for doing this you cover these things and you're done and the problem is documentation has a very limited shelf life in some cases and the more you grow and the faster you grow the shorter that shelf life becomes. I would say for Metal Toad right now it's about a year. We wrote a project management handbook a year and a half ago and I'd say at this point probably 40% of the information in there that we've managed to keep up to date is still relevant. So instead think about the why explain in your documentation the purpose behind what you're trying to do and explain what the outcome should be and that can be when what type of way is the client satisfied or we want to maintain like for example one of our philosophies is we want projects within 10% over budget but we're willing to go 10% over budget if it means keeping the client happy or going above and beyond to give them that extra something to make sure they come back. And so simply putting down that kind of philosophy in paper we don't need to say the process is check your budget and check in with the other project managers every other day to see if there's any new risks about it going 10% over budget. It's much more the there's this kind of line in the same we want to draw on here's why and that's probably a role that we're going to keep around for years just like documentation has a useful shelf life process decays. And so the thing I really wanted to guide project managers on here because it's one that I've had to fight myself on at times is stepping back and having the awareness of when you're holding onto something just simply because it's something you created. So I kind of I would say I'd say essentially gutted and rebuilt much of our process that metal to two and a half years ago now and the amount of that we're still using is almost zero and I like it that way but I also realized probably a year year and a half ago that I almost needed our entire project management team to push me because I can't push them as well as they can push me to show me what's broken with my own processes. So really this is a really useful thing that comes out of having teams is sitting down as a group and saying you know what what are we doing? Well, what aren't we and this thing that we've done for two years why do we do that? Again, this is where it's useful to have that challenger role come in and talking about tools I didn't break this one into projects or into the organization level simply because hopefully you're using the same for both to some extent and those of you who've heard me talk about tools before I'm kind of a little bit I don't know I probably harp on this too much but I really talk about process first and tool second and the reason for this actually it happened at bad camp a couple of years ago I sat down in a project management related bird of the feather and it kind of scared me that the question prompted was essentially like okay tell us about your process and immediately the discussion was about tools and it was really confusing to me it's like wait this isn't really process this is tools and we're trying to build process around them so the problem you run into there is as you all well know there is no perfect tool there's not going to be and so if you try to build your process around a tool you're gonna end up with something that's kind of trying to fit the mold if you really figure out you know what this is gonna this is what's going to work for this client and here's the things that work for our organization from a process level and then you say okay here's these five tools which one's going to fit that process the best that's been a much healthier way for us to approach things so I'd encourage you to do the same this one doesn't necessarily surprise me and I love to work in spreadsheets so I'm probably going to advocate for using them as often as possible even as we grow but probably at 10 people you use a lot of spreadsheets for things that may ultimately become tools that said spreadsheets still always have their place and so the thing I've seen a lot is you get kind of stuck in your tool and the way you use that tool and it's not resonating with your clients and it's not resonating with the executives and it's not resonating with the rest of your team and usually the simplest way to solve that is to take whatever data as you're trying to communicate and either pull it back into a spreadsheet or create a chart around it or create a status update around it you know with bullet lists and communicating differently with different people obviously works better but often I've seen tools actually inhibit the ability to communicate information so make sure that's not happening tool proliferation happens this is kind of a question that you have to weigh as well are you going to adopt the mega tool whether that be MS project or something like it or are you going to have a different tool for every task and a metal toad we've kind of picked the latter it's a little tricky and sometimes communicating to the organization what tools you're using and why and so one of my current projects is actually kind of creating a visual map of the project life cycle versus when we use tools and why and so again it's a why type of documentation I'm working on there but the reason we've kind of gone with proliferation again is because of that process first mentality where the tools and the tools we're picking need to support the process and so the problem is something like an MS project is really going to force us to rework the way we want to do things that we think works best to fit how this tools as we should do things and all that comes with a caveat of whatever you do if you're picking tools that aren't going to get adoption simply because they're not easy to use and people don't want to use them they're going to fail regardless I don't have a good example of complete failure but metal toad we switched from lighthouse to Jira about a year and a half ago for ticket tracking and it's one where it's a lot more clicking in Jira and yes you can customize and there's amazing workflow tools but the amount of time required versus the project scale we're working at is still not there I see even more use for Jira at million plus dollar projects or true enterprise projects but where we're at it's almost overkill and so while we use it because we love some of the QA tools it's a pain in the ass and people don't like using it so that kind of covers the four categories and now I wanted to really focus a little bit more on the project management approach and why I think project management is in the right place to steer the organization so if you're familiar with Scott Birkin he has a great blog post and I encourage you all to go Google it and read it it's called everything as a project and so the notion there is everything if you define it as such there's always some sort of an implied budget an implied timeline and implied scope so it could be the simplest project as getting up and pouring yourself a cup of coffee in the morning you can still identify that as well here's the timeline and then here's the next thing in the sequence here's the steps involved so obviously it's easy to over plan but when it comes to growing your organization a lot of planning is required and having somebody doing that planning and worrying about the future is actually pretty much a requirement project management kind of like I mentioned seeing the clients and the business side of things they also see the full landscape even on a project level you see the big picture you should understand what the goals of the project are and why but you also probably know the 10 to dos for that specific day in the project so on the organizational level same thing comes up you probably know the 10 tasks on your own to-do list and then 10 tasks on the rest of the teams list but you also really want to have and you probably do have a good vision of what is the goal and why are we growing and being able to see that as a single system really helps guide the organization from there it's kind of the role that I've stepped into where I have one foot on the client side and one foot on the internal business side you really kind of have to project manage the org at some point the operations of the company don't just happen anymore whether this becomes at 10 people all of a sudden somebody needs to stock the fridge and so I can say that up until we were 22, 23 people I was still washing the dishes before we had a dishwasher obviously stepping up to that sort of thing is really helpful but at some point it also makes sense to structure and hire around having an organization so now we actually have an office concierge who's kind of a client facing office manager and in my role my goal is essentially to be the project manager to our leadership team and to define things in our major goals as projects and to execute on them. I want to touch on due diligence which is very jargony and the way I'm defining it isn't so much in the doing diligence as you're looking to buy or sell a company it's much more the definition I would give it is the process of systematically researching and verifying the accuracy of a statement. So you're gonna get a lot of this speculation going on while you're growing and you know I think this will happen when we grow but I hate to break it to you you could have the most novel business concept in the world but there are thousands, millions probably of organizations who have already gone through the same growth process that you have so go talk to people and learn I mean even in Portland I have half a dozen mentors who are at bigger organizations than I am and they've seen the pain along the way and understood what the unexpected complexities were so there's always somebody to reach out to there's the internet and there's a lot of good information there obviously but really think about and plan for the future. Project managers I also think are best suited to really understand what's going to be best from a project perspective and so that's kind of the decision do you go for being a license plate shop and turn out the same thing over and over again and get a really efficient process or do you diversify and do completely different projects and try to figure out should we use these different technologies in this project should we be moving more into JavaScript should we be focusing solely on Drupal projects there's a lot of different ways to focus here but project management I think has a good history especially if you've been at your organization for a while of what type of project does well for us what type of project fits our developer and creative goals from a career perspective do they want to turn out license plates or do they want to do custom and depending on the day and what they've been working on the answer could be yes to both if they've been working on something where they're banging their heads against a project and they're trying to learn every day they might look for you know I really just want to brochure site tomorrow if they've been doing five brochure sites in a row it might be time for something interesting so you really do have to find that balance again Steeringwell, things that apply in projects should also apply to your organization so use retrospectives sit down every three months with your team and kind of say okay we set up this goal and how far have we gotten towards accomplishing it what are the things we've learned along the way that are going well, what isn't going well and what takeaways are we going to implement status update, same thing there becomes a lot more of a need for reporting the people, your founders kind of the principals, the leaders of the organization aren't going to have the same visibility and shouldn't have the same visibility into the day to day of your projects that they did at 10 people so it almost becomes a necessity at some point to start reporting out at least the high level status of what's going on kind of capturing those important bytes that are going to allow them to steer well and projections again, you have hopefully a lot of past historical data we end up tracking time as I'm sure many of you do and there's a lot of good information in that data so you have your historical project bias you have what's happening now and given that you can start to predict especially if you have outside mentors with where you're going to be in the next steps of your organization's growth I'm a big advocate for the project management's role to have some sort of say in the sales cycle obviously this doesn't necessarily mean doing day to day sales but in our organization that's included kind of steering things from an account perspective it's also included writing statements of work but as much as anything again you have a healthy view of what is a healthy project what is likely to be profitable what is the team going to want to work on but also really think about what are the other pieces that make a healthy project whether that is is this client going to be good to work with or not or are they going to make our lives painful for the next six months you know is it a brand that we want to put on our website if your goal is really to grow the size and the cloud of your accounts so there's a lot of different things to think about there and then as you've probably heard me say like 20 times in this presentation the word balance I think really that's what it comes down to is because growth is pure risk essentially you're trying to balance the known with the unknown and it's a really careful balance but I think it's really again the project manager is the person who can find that and really communicate that to the rest of the organization so finally I want to touch a little bit on coping and starting with coping at the organizational level because there's a lot of interesting pains that come up as you grow so sales is one thing hiring is another where take a project management approach to it so I've never been that involved in hiring beyond project managers where I do take a very close look at what's going on but I also helped shape what our process of getting people in the door looks like and right now I'm also working on trying to make sure our onboarding is improved as possible because there's a huge ramp up first of all you have to get the right people and I'm sure that's not news to anybody it's like sales and who you hire are going to make or break your organization but we've also more recently really kind of started identifying just how huge the ramp up time for even an experienced developer or an experienced designer can be that can be months in a lot of cases and project managers are no different and we kind of estimate that it's often six to nine months before a project manager is really up to speed and can run solo on projects that are big projects where there's a lot of risk involved that's almost regardless of how many years of experience they have prior certainly they can handle a client call but until they've had that year or so of past experience with the type of projects you deal in and how they tend to result they don't necessarily have the ability to steer when it comes to hiring especially there's two different approaches here and I've actually changed my tune on this one a little bit because I always found myself coming from a point of well you know what there's a lot of pressure and yes we want to hire these six different people but we can only hire two people because of cash flow and so given that I was always kind of an advocate for I'm feeling the biggest pain from the organization and I'm hearing the most pain from here so we must need another developer but I also realized that's kind of fighting from behind and fighting fires and so if you can really strive to think about and look at other organizations and say how would they structure themselves what roles did they hire and at what size you can kind of plan your hiring roadmap much more strategically I've touched on rules and policies and philosophies just a little bit but our VP of people actually has something that I really like that I kind of stole from him here which is he's a huge advocate for philosophies over policies and this is one area where you can actually hold on to some of that tribal leadership or the tribal organization even as you potentially add extra structures in management or in the way your organization operates this is one where we recently we rolled back any sort of a PTO policy in favor of unlimited PTO partly because that's an area where the industry is just shifting that way but partly because we thought it fit with our overall approach of philosophies where really we hire people who we expect will do a good job and then we trust them to do a good job and get out of the way and as long as people are then living up to that standard if they understand what the philosophies behind the rules you would want to normally set are they're going to live those out regardless and at that point it simply becomes a performance issue if there's something you need to deal with and finally and metal toad isn't even by any means beyond this because we still have plenty of people who don't pass this rule but we've used something that's kind of called the hit by a bus test which in reality it's more is the person if the person leaves the organization what would happen because hopefully nobody gets hit by a bus but basically this is or is there a single dependency on your project or at the organizational level is there a single dependency in the organization where if that person gets hit by a bus tomorrow first of all how well documented is their role and what they do and how well widespread is the knowledge of what they do so that somebody could pick it up and run like nothing happened because as you grow every time somebody leaves it's that much more of a setback versus just replacing somebody as you're turning along doing the same type of projects and maintaining your organization size this one also from a from your career perspective and from mine it's something that I've had to think about a lot where really one of my goals and the way I structure it right now is in a year I want to be able to walk away and have all of the things I'm doing today be done by somebody else because as you grow there's always something new so I've seen people kind of latch on to no this is my role and I need to make sure this is preserved and you're actually really doing yourself and the organization is a whole it is service when you look at it that way so a few last pieces kind of touching on the individual level of coping with growth because it is a hard thing for some people everybody really most people are change averse myself included some days more than others and you do get people who Michael Lopp at the PM summit last year give a presentation on the idea of stables versus volatiles and so you can probably identify the couple of people in your organization who love to disrupt the organization who cause a lot of good change some bad change along the way but essentially will cause chaos that's a good thing to an extent but by and large most people in most project management types especially are change averse and that's not surprising because you're also risk averse in a lot of cases so there's a great book out there it's a business book it's called who moved my cheese and it's worth reading if you haven't but it basically gives you a framework for understanding why it's healthy to let go of what you're doing and accept and embrace change there's also risk everywhere kind of like I've mentioned growth is risk the two are almost interchangeable when I talk about it and so this is one where it has to become embracing the risk rather than you certainly want to identify it you are the person who should say hey I see this big risk coming this is a problem we need to do something about it but don't become a blocker when you do it be very solution oriented and when your leadership team says you know what I hear you but we're gonna do that anyway because they will you're gonna have to embrace it and just go along for the ride because it'll probably make things more interesting and especially if things break down the road that's even better because you get to come and swoop in and save it your career trajectory kind of touching on the wearing all the hats again as a project manager again like I said when we were 10 people I could kind of do whatever I wanted to right up until the point where I was deploying code but that would be you know making changes on our website it would be doing QA it would be doing strategy some business development and certainly some project management involved but as you grow you really do have to define what you want to do and focus down so I encourage you especially at the smaller sizes to dabble a little bit to even if you really don't feel the need and your organization doesn't push you to do anything beyond day-to-day project management to learn the other areas of your organization it's going to certainly make you a better project manager but you may also find that as you grow and as you really find yourself more in spreadsheets and planning and tracking and dealing with customer complaints and a little bit less with say strategy that you like to enjoy or you used to enjoy so much that you actually want to shift that direction and so identifying that early is a really healthy way to grow within the organization and say you know what I'm actually I enjoy this PM thing but I want to do something else and here's the role I see for myself you're going to have that opportunity along the way and finally I really I had this notion today and so I changed this slide but think of yourself I don't know if you've ever seen some of the crazy rally car driving that they'll do like the off-roading where they'll actually I mean they'll have driven the course certainly many times before and you don't get that benefit when you're growing for the first time but you've got the driver and the driver essentially has to react on gut and their navigator and the navigator knows the course and is calling out the course because they're driving fast enough where you can't actually see around the next three corners and that you're going to be covering in the next two seconds so when you think about it that way you probably have somebody else besides yourself driving that might be a single founder it might be an advisory board it might be several principles of your organization any number of people and often it's that entrepreneurial spirit that started it so really think of yourself as the navigator and make sure that you've exeered your organization to the extent possible and you're able to step up to that level that's really what I want to make sure if you got one thing out of that be a project manager don't let your project suffer but there's certainly room to step above and really take on growing the organization from a project management level so hopefully that was informative you learned a few things and I'd love to take some questions and thoughts and please use the mic so it's all recorded first of all I just have to say that was incredibly helpful and refreshingly pragmatic as a owner of a small agency looking to grow you've totally laid out a roadmap so that was great and you also did answer the waterfall versus agile for me so thanks so my question is I'm very intrigued by the policies versus philosophies slide and I was wondering if you could talk a little more about what that looks like are the philosophies written down somewhere how does that work sure well I'll give you I think part of it is just our culture of metal toad where we've naturally found ourselves rejecting too much policy so just kind of actually uttering that as a phrase was like oh yeah that is kind of who we are one was we actually had a document that was written up that didn't necessarily get beyond the higher levels of management there was basically a policy for who gets to book meeting rooms and when and it came out of this whole notion as we've grown we've actually also run out of office space and so meeting rooms were in high demand especially call rooms and so this basically set down a if it's a in-person client meeting or an interview you get to bump people from these other things and it's like wait why do we have people bumping people from rooms and why is that down in writing this is really something that there's a philosophy behind it and it's yes obviously our clients are important and interviewees are important but it doesn't necessarily call for kicking somebody out of their meeting room and so that's one simple example but a lot of them actually there's other toads in the audience so can you throw some other ones that have been instrumental for you well taking that example how would you rewrite that policy to become a philosophy yeah but but then how's the is the philosophy formally communicated in any way like oh some are and some are clients are important the PTO policy like we we did have it structured and we have an employee handbook and in that employee handbook we had a structured PTO policy and so the new one is documented as just because it's unlimited doesn't actually mean you get to take every day of the year off here's some general guidelines for how much you should take off and why you should take off but we really focused on more of the why so it's like we do actually want you taking time off because it's healthy because we realized if you never take a vacation you're going to burn out and that's not what we want we focused on kind of some of the work life balance aspects of it but we also said you know take sick days because we realized that if you take a day off and rest up and heal up first of all you're not going to get other people sick but second you're going to be back in action quicker so it's it's really kind of identifying those things but usually comes down to documenting it somewhere as simply as possible okay thanks so at the the the business summit on Monday there was a couple roundtables for Drupal agency shops talking about scaling organizations I'll cover a lot of the same subject matter one of the things we talked about was like inflection point as you grow and determining when those inflection points are you mentioned you have like a VP of people right right I bet you didn't have it at 10 so when did you know you needed that VP of people person and when did you determine you couldn't live without that person sure yeah I think you've probably all seen organizations that staffed up at the bottom too heavily and had no leadership you've probably also seen organizations that staffed up at the top too heavily and had you know a developer for a director for every developer essentially and again finding somewhere the sweet spot in the middle is right this one for us actually it's more we've always kind of taken the approach of as long as we're able to from a financial standpoint if we identify somebody who's going to be transformational for the company we'll hire them regardless when possible so definitely look for those opportunities and our VP of people actually we didn't even hire as the VP of people he started in client services and we quickly identified yeah client service is important and you know try to hold on to parts of that they're most important but we really want you in this people role and so yeah there's a there's a lot of different ways to approach that but I'd say the inflection points for us just more than 10 people is where I kind of had my oh this is a real company moment and actually I was a little scared coming to I came from an organization about 80 to metal toad when it was 10 and it was one of those it's like okay they they've almost reached real company status this almost feels like there's something going on but it's still a little corner office and so it was risk that I suffer myself of taking on this could go somewhere or it could stay 10 or we could be out of business in two months so there's an inflection point that happens 10 to 15 where it's like okay we're stable enough we have kind of all of our bases covered there's somebody in every role I think we really stabilized in the mid 20s for a while and figure out how to make that work for us and so now we're essentially again trending up and so we're in the middle of a big inflection point right now the 30s are kind of miserable for a number of different reasons so I'm excited to get to 4045 50 and I'm I'm guessing that's kind of where our next period of stabilization happens but again it's also hard we're bootstrapped and so we have the good news is we have more work to do right now than we have people to do it and the contracts aren't an issue it's really more because we're bootstrapped how quickly can we possibly hire without taking on extra investment or extra debt because that's something we've tried to stay away from thanks any other questions yeah so first question was what is my thought on how many projects a project manager should have definitely that kind of corresponds to project size so one thing we did actually it was in our 20s we kind of took all of our small projects in our managed services and kind of service agreement and hosting and support engagements rolled us up with a single project manager who now has probably 15 projects but they're all small the real reason we did that is we were at the point where most of our projects at the hundred case size we had three maybe four projects per project manager and that was pretty healthy except they'd also often have three or four small projects that were just kind of lingering and they had the worst habit of coming back all of them on the same day and usually it was a launch day for one of your major projects and I don't know why that happens but it's a thing I've asked other project managers and so we kind of wanted to bottle up that noise both further project managers and our developers and focus that on one department so that's where our managed services team came from so the ideal to me and it's kind of where we're striving for is I look forward to the day where one project manager has one project and they manage it start to finish because being able to go that deep on a project to me personally is really exciting second question was regarding onboarding and you know the often long track for ramping up a project manager and so we've done a couple of things there we have I've outlined milestones for the first 90 days of a project managers time where a lot of that initially just involves shadowing reading existing documentation and there's kind of a transition point where we actually recently started to new project managers and so there's a great senior project manager on our team and he kind of took the shadowing and the mentoring of one of the project managers and I took the other and we're making sure that they're also doing some knowledge here but basically what we've ended up doing is week one week two week three I was leading calls and kind of leading and doing project management week three week four kind of get into the point where I'm still in all the calls to the extent possible but they're leading they're taking notes and we made it clear to the clients from the start that ultimately they were going to be the project manager for that project so it's really the they're going to have the full knowledge it worked out well in this case because we started them at the start of the projects there wasn't the mid-project ramp up but it's also an area where I really identified because documentation becomes outdated things that I did two years ago and since then our team has been really busy and we haven't quite had somebody else go in and you know fix a lot of the documentation make sure it's up to date and so where a lot of that's come from is it is more resource intensive and time intensive to properly ramp somebody up it's ultimately a decision of do you try to figure out ways to keep your documentation up to date or do you have spurts of time where from an example right now it's essentially I don't have less to do and the rest of my job it's just I also have to spend that extra time to make sure this new person is successful and that's a significant amount of time so it's for me it's kind of the question of how many more times am I going to need to do this and I don't anticipate hiring ten project managers in the next year if we did that would be an easy okay we need to document we need to plan we need to build a really big program around this and so that's where I think on our junior side like building the junior program that's a little bit more focused effort because we're anticipating more hiring there sure so the question is talking about my personal experience hiring with project managers hiring at the more senior expensive level hiring at the more junior level it's an interesting one you find people where they have 20 years of project management experience but digital project management is a practice like the longest you really could have been around in doing this is maybe 10 years and even then most of what you're doing 10 years ago isn't relevant it's two three four five years so a lot of the senior project managers I'm seeing are often they're newer to the industry but they have a really focused perspective on what's been happening recently so we've hired senior project managers or what I would consider a senior project manager even that wasn't their job title with less than five years experience we've also hired junior project managers essentially at zero experience and I tend to air towards the junior side when possible recently with these two new hires we essentially had a senior and more much more junior on the rest of the team so we were weighted too far towards the junior side and the amount of time it was taking for myself and the other senior members of the team it's pretty significant so we said okay these new hires we're willing to pay a little bit more we're gonna look for a little bit more experience but to me and actually there's a huge blog post on this one or a huge series of blog posts on this one so I do encourage you to check out the blog you are all there I basically went through and if you ever apply to a job at metal toad I kind of wrote the rubric for what it takes and so if you go through that you have the cheat sheet for what we're looking for but I started talking about you know essentially as of when I wrote that post what do we see the role as a metal toad what are the knowledge and skills that are going to be really useful to a project manager but also just simply what are the traits that somebody either has or doesn't have that's going to make them successful so more than junior senior it's often do you have those traits or not that we're looking for and even from there I actually do go on in a further post to kind of talk about our hiring process and what are even what our interview interviewing looks like any other questions all right well thank you very much and please do evaluate the session and it'll help them for next year hopefully if I hear the feedback it'll help me for next time I present which will be I do want to I'm not helping organize but I am speaking and I'll give something similar but different at the p.m. summit in October I think it's the sixth and seventh and it's actually at the high at just across the river so check that out it's dpm 2014.com thank you