The following is an excerpt from an email I sent to DeveloperTown in October 2015.
It's Friday! For me, that means it's resourcing day. I have a small number of weekly meetings (the company meeting, a manager's meeting, a biz dev meeting, one on ones, etc), but I view the resourcing meeting as the single most important meeting for DeveloperTown. If you want to know how we're doing in every aspect of our business (sales, hiring, delivery, quality, etc) it will come up in the resourcing meeting. It's the heartbeat of our business.
What happens in the resourcing meeting?
From time to time, you may wonder why you get assigned to certain projects. Or perhaps why you are dropped from one project and added to another when it seemed like you were only half-way through what you were working on. I promise, it's not because Nate traded you to Julie for a first round draft pick. (Even though I think he may have tried that at one point.) Resourcing is one of the more difficult aspects of our business. Here's why: we aren't like other firms...
To understand how we're different, you first have to understand how most of our competitors work. In general, there are two models for selling services like ours: staff augmentation and project work. If a vendor is selling staff augmentation, they are putting a butt in a seat.
Most staff aug sales folks will recruit you a candidate, do a small amount of technical vetting, and present that candidate to you for final qualification. If you take on that candidate via a contract, they are basically your employee. You direct them, you manage them, you do performance management, etc. The staff augmentation firm will provide you air cover from time to time, but for the most part they are hands-off once the contract is complete. For the next 3 to 24 months, that person is your responsibility - not the staff aug salesperson's responsibility.
Clearly, we don't do that. We've done it a couple of times in the last five years. But we only really look at doing that under two conditions. The first condition is when times are tight and we need the work. We have never had to lay people off, which means sometimes we take on less desirable work. The second condition is if we feel it's a good learning opportunity. If it gives one of our team members a chance to learn a new technology or process, see how other teams work, develop a relationship, etc - then it might be a good fit for a short-term engagement.
Project Work
If you don't sell staff aug, then you're doing project work. Project work can take shape a couple of different ways. In some cases a firm will come in, look at what you want to build, and give you a fixed bid for what it will take to build it. In this case, the bidding firm is taking on delivery risk. But the bidding team often gets to make all the decisions about how they work (process, tools, etc) so long as they deliver what was committed in the timeline that was committed. We've done this a couple of times, but it's very very rare for us. There are some good reasons why we don't like these types of arrangements. I wrote about that in a blog post on RFPs.
Another way to do project work is to do something closer to what we do. You help the client understand the scope of the project, then you give them a good faith estimate for what it will take to get it done, and then you partner with the client to deliver the work. In some cases, this can mean creating a blended team of the consulting firm's resources and the client's resources. And collaboratively they work to deliver the project objectives. They have to agree on processes, tools, hierarchies, communication methods, etc. We do that occasionally, but that's still not what we do most of the time.
Most of the time, we help the client understand the scope of the project, then we give them a good faith estimate for what it will take to get it done, and then we take on the project in a way that looks a lot like what we would be doing if it were fixed bid. More often than not, we are using our tools, our processes, and only our team members to deliver the project. That doesn't mean we don't often have dependencies on the client (or perhaps the client's team), but it does mean that we ultimately have ownership over how we do our portion of the work.
In many ways, this is the best of both worlds. We don't have the risk of a fixed bid, but we also don't have to give up any control around how we get the work done. We can do the work the way we want. Sounds great, right?
In some ways it is. Our clients give us a ton of autonomy. I appreciate that autonomy, and I'm sure all of the more senior folks here at DeveloperTown appreciate that autonomy. It allows us to experiment, take risk, and work in the way we want to work. But it also comes with some downsides:
Difficult to manage expectations
The way that we structure the work can sometimes set up difficult expectations with the client. To them, it can feel like we've fixed bid the work. Even if we haven't, the relationship can morph into that type of dynamic. They don't have team members involved, so it doesn't feel like a collaboration.
We aren't using their tools, process, or working out of their building, so we don't feel like employees. So as a client it's easy to fall into the trap of, "I expected this..., you've not lived up to those expectations, so it's on you to make it right." That's the fixed bid mindset.
There are other expectation gaps that can emerge from the way we structure our work. We tell the client they aren't getting a fixed team. We tell them that we will adjust the team as needed based on the phase of the project. Need more design early in the project and more testing towards the end? No worries... we have Magical (TM) EMs who can manage all of those resourcing complexities for you. So you always get the team you need at the time you need it!
Crazy right? But that's what we sell. One reason we sell it that way is because of price. We charge a relatively high dollar price per hour for Indianapolis, and one of the ways we justify that is that we will spend those dollar as efficiently as possible. You could hire a team of 10 people for $70/hr, or our could hire our flex-team of 6 people for $145/hr and know that you won't be paying for idle resources.
Another reason we do that is efficiency internally. Imagine if Chris Wingate were sitting idle on a project where he was "locked in" and being paid for by the client, even if there wasn't meaningful work to do. Meanwhile, the team assigned to Project X is working around the clock trying to hit a deadline, and they could really use his help. If we didn't have the ability to shuffle Chris around, we'd have to watch Project X struggle, while Chris gets so bored he eventually quits.
Okay... I'm being a bit dramatic there. But I know I left a project at Eli Lilly after three months because I had surfed the entire internet (all of it) by the end of those three months. Good people don't want to sit idle. And good leaders don't want to see a team struggle if there's a reasonable way to shuffle resources to make the team and the project run smoother and be more successful.
We have tremendous ownership around tradeoffs and quality
Our clients put a tremendous amount of trust in us. And for me - that feels so awesome. I love the level of autonomy we enjoy, the freedom we have to guide the client through technical decisions and tradeoffs, and the ability that gives us to create growth opportunities for our staff. What we have is incredibly rare in the world of consulting.
However, that freedom and trust come with incredible responsibility. If it turns out we steered the client down the wrong path, many of the leaders here at DT feel a high sense of ownership that we should own part of fixing that mistake. It means that if we feel our team has underperformed for a period of time, that we owe it to the client to make up for that in some way.
You'd never see either of those in a staff aug engagement, and rarely in a traditional project engagement. Julie, Jason, Randy, all of the engagement managers, and many of our senior staff spend a lot of time worrying about "doing the right thing" for the client.
Our resourcing meeting
Here's what's supposed to happen in our resourcing meeting:
-
We walk a list of every DeveloperTown employee, and we review what projects they are assigned to. If an engagement manager thinks they need more or less of a person for their project, they speak up and the team works to figure out a solution if there's a conflict.
-
Once we've walked the list of "in flight" projects, we then talk about what's been sold. This is where we try to figure out the best fit of kickoff timelines to available staff, and again the team works to figure out a solution if there's a conflict. For new projects, there are always conflicts.
-
Once we've discussed what's been sold, we talk about what might be sold soon. This gives us the ability to forecast our people against projects that are wrapping up and what we think will be starting soon to replace those holes.
-
After all of that, we talk about staffing levels. Do we have enough people? Do we have the right mix of skills? What happens if we do end up selling that giant project? Can we bring in some staff aug folks to help us instead of hiring? This is where we all give Jason the evil eye and tell him to go find more rock stars. Because, you know, rock star developers are just sitting around waiting for DT to call them. :)
Most of the time, that's what happens. Those meetings also include a ton of bad puns, some very funny jokes, and the occasional heated discussion around what's the right thing for us to do to deliver the best solution for a client or to give one of our employees the right growth opportunity.
Those heated discussions don't happen often, but when they do - in a very odd way - they make me happy. Because people only have heated discussion if they care. And it's very easy to see in that meeting that everyone involved cares deeply about what we do. It's so cool.
After that meeting is over, I have no idea how you guys all find out what you're working on. That's just more engagement management Magic (TM). :)
I'm sure it can be frustrating to be shifted on or off of a project mid-flight. It's always done for a very good reason. And if it's not obvious why, you can always ask. I'm sure we make mistakes sometimes, but hindsight makes it easy to see mistakes. When we're in the moment, trying to do what's best for the client, our people, and the firm... it's hard to always make the right call. And worse, many times there is no right call - we just have to choose from a pool of options no-one likes.
Resourcing will get more and more difficult over time. Resources for 13 people was easy. Resourcing for 40 people is... interesting? As we continue to grow, add additional technologies, new products (hello marketing team!), and take on more audacious projects, then it becomes more challenging to solve the Rubix Cube. This is why I'm sure most of you are feeling some sort of pressure to learn other technologies and skills. If someone knows Rails, iOS, and Android, it makes it easier for us to slot that person into any team as a flex player.
It's an awesome problem to solve.
Have a great weekend,
Mike