The following is an excerpt from an email I sent to DeveloperTown in October 2015. 

Over the last five years, we've looked at a lot of numbers. Things like profit contribution by employee, profit contribution by client, individual point delivery, and the value of profit sharing units. To be clear, all of those are now deprecated.  :)  While we had some crazy things we measured, we learned a lot of with of them.

Sometimes we learned what not to do. For fun, ask Chris Wingate or Chris Scales to explain the first DeveloperTown compensation package sometime. You'll see "fun with numbers" hard at work. I have some killer spreadsheets on my computer. They are almost works of art.

I don't actually regret any of those experiments. We learned a ton in the early years. And we're still learning. Figuring out what metrics are meaningful indicators for your business and for performance is really difficult and nuanced. I'm sure we don't have it right yet. But I feel like we're closer?

Most firms look at three basic numbers: utilization, realization, and efficiency.  

Utilization:

• Definition: Percentage of billable hours for a person in a given period of time.

• Example: Larry works 32 hours on NewCo, and 10 hours on ZombieTown. Larry is 80% utilized. You'll notice by that math, it's possible for someone to be more than 100% utilized. You divide by the expected billable hours, not the total hours actually worked.

Realization:

• Definition: Before you define realization, you need to define Fee Capacity. A person's fee capacity is the amount of revenue you would expect to collect for that resource if they hit their target utilization at their target bill rate. Realization is a percentage determined by dividing the revenue the person actually earned, divided by their fee capacity.

• Example: Larry works 38 hours on NewCo, and 4 hours on ZombieTown. Larry's fee capacity is 40 hours times $150 per hour; or $6,000. Larry bills at $135 on the NewCo project, so at 38 hours he would bill $5,130. So his realization for that week is 86%.

You'll notice that in both of metrics, the person doing the work can't always control those numbers. In some cases, people don't have billable work. For example, if we have a sales gap, we keep people on "the bench." We don't have a history of layoffs when times get hard. Realization is also difficult, because you don't set your bill rate for clients. That's the sales guy's job. And it's not your call if some of your hours get discounted because of a bigger macro issue with the client. Or what happens if the project is fix-bid?

So what can you control?  

Efficiency:

• Definition: Efficiency is a lot like utilization, but instead of being based on a fixed unit (like a 40 hour week), it's based on how much billable work has been allocated to you. So efficiency is the ratio of hours billed to billable work available/allocated.

• Example:  Larry has been allocated 50% to NewCo and 25% to OldCo. He doesn't have billable work allocated for the last 25%. He logs 32 billable hours that week. His efficiency is 32/30, or 107%.

While you have more control over efficiency, it's still not perfect. Why isn't efficiencythe killer consulting metric? Because sometimes the work isn't that cut and dry. We might allocate 20 hours to Matt for a project, but he might legitimately finish the work in 8 hours. Does that mean he did something wrong by not billing the other 12 hours? Of course not. You only want to bill the time if that's there's real work to do.

All of those numbers are more nuanced than I've presented them. But you get the idea. These numbers are great feedback tools for consulting companies.

So how are we doing as a firm? 

<clipped from blog-post version>

Why share the novel?

We are a consulting company. We're a bit of a special consulting company, but still a consulting company. (And hopefully not like Harvest math is "special.") I think understanding these numbers are important. These numbers drive our DT economy.

I remember attending a meeting at Liberty Mutual where they listed off what various items costed in terms of insurance policies sold. Coffee for the company for a week? That's 437 policies sold. A 30 min team meeting with 6 attendees? 567 policies. (Those numbers are completely made up. I can't remember.) But the idea of doing that math was super impactful to me. It completely re-centered me on the core business of the company. I was really thankful they had done that exercise.

So, here at DT?

• Cost of a new house for an employee? 173 billable hours.

• Cost of a team kickoff dinner for a new client? 10 billable hours.

• Cost of 3rd party accounting so far this year at DT? 432 billable hours.

• Cost of coffee and soda each month here at DeveloperTown? 27 billable hours.

• Cost of domain names so far this year? 10 billable hours.

• Cost of building out a new deck on the Monon side of the building next summer so everyone can sit outside and soak up some rays while working? 500 billable hours.

• Cost of cleaning the bathrooms each month?  33 billable hours.

• Cost of Harvest? 94 billable hours. Or perhaps 90? Or perhaps 102?

• Cost of Daryn losing a fantasy football matchup any give week? Priceless.

(For those playing at home, all that math assumes 30% profitability on an hour billed. You don't apply the full rate to the client, just what DT would net on that hour worked. I'm ignoring the possible double-dip on overhead calculated into the profitability ratio. It's not perfect math... but you get the idea.)

It's a great way of looking at the costs of our firm. Because that's how we pay for things. This is the fuel that our engine runs on.

We are not expecting anyone to start tracking individual utilization, realization, and efficiency. As a leadership team, we don't really look at these numbers on an individual basis unless there are concerns. They are great heuristics and top-level metrics to assess the health of the business. They are also great tools for long-term planning.

Have a great weekend. And a huge thank you to everyone coming in tomorrow to help with the house move.

-Mike

The following is an email I sent to DeveloperTown in February 2016. 

Here’s the short version. It’s a quote from Julie’s whiteboard, “Only a fool thinks he can see through a small slit into an enormous space with clarity.”

That’s a great quote. I often think I’m that fool. But we all are. It’s easy to forget you’re not seeing the entire picture. That’s an important and difficult perspective to keep.

Now you can bail if you have to. This week’s email is very long. This is the draft email I mentioned that ended up being six pages long. Someone convinced me not to shorten it or break it up, so my apologies for the short book.

For those with a strong cup of coffee and a few minutes of quiet time this weekend, here’s the long version...

Do you ever look at something we do at DeveloperTown and think, “Why did we do that?” I’m willing to bet that you do. I know I ask myself that question. Sometimes it’s difficult to understand decisions that happen through the fog of war. You’re looking through the small slit and you can’t see everything.

When I see what I perceive to be bad decisions, I get frustrated. I think, “How did that happen?” Or in my better moments, “What did I do that either caused that to happen or let that happen?” And in my best moments, “What don’t I know that would explain why we did that?” Okay... Honestly? I never do that last one. That's what I want to do. It's so hard!

We have an absolutely killer team here at DeveloperTown. We have literally handpicked many of the people who work here. And for those that self-elected into our tribe, they earned it. We get unsolicited resumes every week – for all roles. So all things being equal we have talented people, right? And I don’t think anyone at DeveloperTown comes into work on any given day thinking “How can I do the bare minimum today?” Or “How can I piss off Eggleston today?” (Well, Nick might ask himself that one… but mostly just for fun.)

So if we have talented people who care about what they do, where do bad decisions come from? It can be hugely demotivating to be working on a project where you’re impacted by a decision that you not only don’t agree with, but you simply just don’t understand it. It’s one thing to disagree with a decision, but you understand why it was made. It’s another to just be left shaking your head wondering, “WTF?”

So, to be clear, I’m still figuring all this stuff out. I have (almost) no idea what I’m doing. However, I’m not operating without a net. I have some of the most experienced and accomplished people I know surrounding me. But I think it’s an important thing to talk about. I think it’s one reason why good people sometimes leave, and I think it can sap energy from projects and teams.

So, in no particular order, here’s why I think bad decisions happen at DT:

It was just a bad decision

Yup. Reference above where I said I have (almost) no idea what I’m doing here.  :)  

While several of us have started businesses in the past, never one like this. And while many of us have worked for consulting companies in the past, never one like this. And many of us have managed projects before, but not in this kind of environment with these customers and this team. So we’re kinda just figuring it out. We are gonna make mistakes. Lots of them.

It’s not an excuse. Call out a bad decision when you see it. Just recognize it may have been a genuine mistake. Give us a chance to make it right.

We created space for someone to fail – and they did

This is similar to just making a bad decision, but it’s a bit different. When we create space for someone to fail, we’re creating space for bad decisions to happen without the rest of the company knowing the reason why. I think everyone here would be supportive of, “Oh yea… they are learning.” But it’s hard to recognize that in the moment.  

Sometimes we might even want someone to fail.  It’s part of their growing process. To be clear, we aren’t going around looking for ways for team members to fail that are going to have global impact on the company, but you don’t always know what failure is going to look like.

I think one of the things most people at DeveloperTown value is a relatively high level of independence when it comes to decision making on projects. As we grow, that will obviously change a little. But I hope it’s always a part of who we are. When you ask someone to make hundreds of small decisions on their own, you have to recognize that sometimes they will make a mistake. And sometimes what they thought was a small decision (and thus a small mistake), will turn out to be a large decision (and thus a large mistake). And we support that.

The trick is to figure out how to add the appropriate processes to allow us to make those mistakes safely.  :)

A decision wasn’t actually made

Sometimes things just happen. They happen because someone took the initiative not because a group of people came together and said “We should do X.” An example of this is just about anything Korey does related out space (kitchen, printers, conference rooms, etc). Korey cares deeply about our workspace and how it looks to our clients. I think that’s awesome. He and I regularly chat about ways it can be better - but we don’t have a formal “plan” for making it better.  Korey just takes initiative to make it better - mostly in small ways, but sometimes in big ways. We don’t want Korey (or anyone else) to stop taking initiative. But it’s important to recognize that when people are taking initiative, it’s not always coordinated with a “master plan” of some sort. They’re just trying to make things better.

Another way you can see this is if you start to recognize a pattern that starts emerging over time. It can look like an intentional decision was made, even if no one made it. It’s just a pattern. An example of this is that DeveloperTown is a dog friendly work environment. We had dogs showing up well before we ever had a policy for it. And we still don’t really have a policy outside of “Yea, bring them in unless they bark or make a mess.” It just kinda happened. Digby started showing up, then others. I love it. But it wasn’t intentional.

Finally, sometimes we aren’t making a decision on something simply because it’s not a high-enough priority. (That’s kinda a decision in it’s own way. Meta.) When are we going to address some of the fire code issues at DeveloperTown? Well… you know the answer to that one now.  When it becomes a priority to do so. :) When are we going to “fix” the wifi? It becomes a priority in spurts… then dies down because it stops being the squeaky wheel. It’s not because of bad decision-making. It’s just a handful of really really busy people juggling priorities as best they can.  

It’s a consequence of another decision

Events can occur where it seems like a conscious decision was made, when in fact what you’re seeing is the result of some other very well reasoned and intended decision. Consequences can happen, and they can feel intentional.

Here’s a recent example. You may or may not have noticed that DeveloperTown has been largely silent on doing PR and marketing for ourselves for last year or so. Believe me, this isn’t because we don’t have a marketing services team dying to jump in and start dominating the conversation – moving all eyes to DeveloperTown. And it’s also not because we made a decision as a management team to “not do marketing.”

About a year ago, I went to Nick and said “Build a profitable and scalable marketing line of business for DeveloperTown. You’ve got a relatively short runway to figure it out. Go.” So Nick, Matt, and a bunch of other folks buckled down and started solving that problem. Guess what happened?

There’s no right answer

Our experience – at the end – with <HR COMPANY> was not good. Like… really not good. We then tried <ANOTHER HR COMPANY> for a year. That was also not a good experience for anyone. This year (hopefully more than a year?) we’re trying <YET ANOTHER HR COMPANY>. Guess what? It’s not good so far.

We’ve had other health care and benefits options. But they all suck. It’s just a really hard problem. There’s no answer that doesn’t suck outside of building a for-realsies HR department. And then you’re still hoping you hire the right people with the right experience.

You might read the recent press about <YET ANOTHER HR COMPANY> and think, why did we choose them? Shouldn’t we have known better? But sadly, in some ways they have already been better than our last two providers. But there are still very real problems with them. (Aka… support at <YET ANOTHER HR COMPANY>sucks.)

Did we make a bad decision? Yup. Was there a good decision to be made? It’s not clear to me that there was. Was there even a better decision to be made? It’s almost impossible to know. It’s just a situation where you need to select from a bunch of really really bad options.

We tried and failed, but you don’t know that

As a DT old-timer, this is a fun one. There are many times when people say “Why don’t we do X? Almost everyone does that.” Or “Why don’t we have Y?” Sometimes the answer is, “We did. It just didn’t work for us, so we stopped.”

For a trivial example of this, someone said they were going to figure out or start an employee directory. I then showed them our first failed attempt at such a thing from 2010. And I’m fairly sure I could have shown them another separate failed attempt from 2012.  

For those of us who remember those failed attempts, it’s not like we made a decision not to have an employee directory. We tried and failed. That doesn’t mean we shouldn’t try again. It simply means that when people with different tenure look at a decision (or lack of a decision) it can look very different.

Error of omission

Very similar to the last one. There are many times when people say “Why don’t we do X? Almost everyone does that.” Or “Why don’t we have Y?” Most of the time, there’s a great chance we should change in some way. We should start or stop doing something, or at least talk about how to do it better. But sometimes the answer is, “We do – you just aren’t aware of it.” That sucks.

Why don’t you know? Most likely because we just didn’t communicate it. We need to get better at that. It’s one of the things I know I struggle with. And it’s one of the things that sparked these emails.

How do we efficiently communicate things to people that they should know, but that it’s not easy to communicate? Examples:

• What’s discussed at a company meeting for those who are remote and/or out of office for a good reason?

• What happens in a project team meeting for those who needed to be in two places at once, or for people who join the project at a later date.

• What decisions were made around client experience that are going to impact my sales cycle with the client?

• What decisions were made with the client during the sales cycle that our team is going to have to deliver on and weren’t captured in the statement of work? (Maybe for good reason.)

• How does everyone else on the team solve this problem? It seems like we’d come across this type of problem a lot.

This is an issue all companies struggle with. The answer is normally a pendulum that swings back and forth between over communication/documentation and under communication/documentation. Sometimes it feels like we’ve simply chosen to peg the pendulum on the under communication/documentation side. It’s not on purpose. (See “A decision wasn’t actually made” above.)

In a rare set of circumstances, we did make a very good decision. We just didn’t tell you about it. That’s still an issue. It’s just a different type of issue.

We did make a better decision, but we didn’t execute in time

Remember the Christmas party two years ago? Not the general awesomeness of the 2015 Christmas parties, but the more quietly-understated-awesomeness of 2014… no wait, 2015… no wait… Yea. It’s not because we didn’t make a decision. It’s an execution issue sometimes.  :)

Other examples of this can include tactical decisions on projects where we run out of time or resources. It’s not like we don’t know what the better decision is, but sometimes it’s just out of our control. Time gets away from us all. Again, not an excuse – it’s all of our jobs to execute – but it happens. I believe most of us know what we have to get done most of the time, but it doesn’t all get done.

Sometimes when something doesn’t get done, you just accidently made a decision you didn’t intend to make.

It was actually the right decision, but not for any reason you can recognize

This last one is difficult to understand sometimes. The easiest way to illustrate this one is with an extreme example. Let’s imagine for a second that I got really sick.  Like – life threatening sick. (I’m not sick. Well… at least not that I know of.)

If that happens, there’s a great chance I won’t want to make a public announcement of it until I figure out what that means. Can I recover? If I can’t, how will we handle the logistics of a transition of me leaving DT?  If I can, what’s the plan for the short-term while I’m distracted with taking care of myself?

Outside of the management team, I wouldn’t want to communicate anything until I have answers to those basic questions. Then I’d talk about it at a company meeting, and together we’d figure out the rest of it. But I promise you, if something like that happened, there would be this awkward limbo period where you’d see a number of very odd and in some cases potentially painful decisions getting made by the management team. And they wouldn’t really be in a position to disclose why. You’d have to trust us.  

Last aside: We do have some plans in place for when a partner dies or leaves the business. But we don’t have good plans in place for when a partner gets sick and/or can’t work at full capacity. That’s mostly because it’s never clear in those situations how much they will want to work, or maybe even be able to work. We will have to figure that out when we get there. So Wingate, when that happens… just be prepared to help “resolve” the issue.  

Now that we have a team of almost 50 people, this happens. And it happens more than you think. Sometimes people are public about challenges happening in their personal lives, and sometimes they aren’t. If they aren’t public about it, then we – as an employer – can’t be public about it. So we make decisions and organize teams and work based on insider information that we have – that you might not have.

And you shouldn’t have that information. It would violate someone else’s privacy. In those cases, you may hear us say something like, “I can’t tell you why. You’ll have to trust we’re making the right decision.” Sucks right? But that’s the law, and it’s the right thing to do.  

Want this one to become even more complicated? Sometimes it’s an issue with our client’s personal life. And in those cases we sometimes step up and help too. When we can. And even then, sometimes we can’t talk about it.

…

I’m sure there are more reasons. But I think that’s good enough.

So why the short book? Simply for perspective. I’ve been thinking about this a lot lately. I know we’re not perfect – and you guys know it too. As we continue to grow, I worry about past decisions not getting revisited, decisions by omission, and many of the other issues noted above. Change is hard. And we are changing.  :)

It’s easy to get frustrated at the pace of change, at decisions you don’t understand, and that frustration can sap energy. When you recognize something that’s bothering you – a decision, a lack of decision, or a problem – speak up. Grab one of the managers and vent. Grab me and vent. Heck, grab Kim and vent, and then she can vent on your behalf and keep you anonymous.

We might be able to shed light on the situation, we might be able to fix it, we might be able to distract you with a shiny object so you look the other way, or we might just say we’re sorry. And sometimes a good sincere apology is all you need to hear.  

Have a good weekend,
Mike