Own it

The following is an excerpt from an email I sent to DeveloperTown in March 2017.

I've been thinking about ownership recently. A few months ago I listened to an interview of DHH, where he shared his thoughts on ownership. He's written about it in the past - a short article on assigning blame. I'll summarize DHH's thoughts - it's your fault

This is not a new idea. It's a fairly established leadership principle. Blame always goes up the chain of command. If a team is struggling, it's likely because they haven't been given what they need to succeed. I'm a bit of a Jocko fan-boy these days (the podcast is excellent), and in his words (emphasis is mine): 

“On any team, in any organization, all responsibility for success and failure rests with the leader. The leader must own everything in his or her world. There is no one else to blame. The leader must acknowledge mistakes and admit failures, take ownership of them, and develop a plan to win.” 

I also like SmallBox CEO Jeb Banner's short article on the topic. Jeb relates it nicely to agency life - and talks about ownership from the customer's point of view.  From Jeb: 

"Why is it always our (the agency's) fault? Because if the client is unhappy, then we have failed in one, or more, of these three ways: We failed to deliver as promised. [...] -or- We failed to manage expectations. [...] -or- We should have never taken on the work to begin with. [...]"

But it's not always clear how to apply this principle. It's easy to take blame once you get used to it. Taking blame is useful, because once the leader takes blame - everyone else stops blaming each other and they start focusing solving the problem. 

If you read the accounts of the most recent Amazon outage, you'll find that it was caused by someone making a typo at a terminal. A typo - brought down thousands of websites, and likely caused millions in damages. (I saw $150M in one estimate.) Amazon's response (paraphrase)? "It's our fault. We knew that issue existed. We even had a project queued up to put protections in place. We just didn't give it the right priority. And there are likely other steps we could have taken."

Over the years, I've heard Julie talk about assigning blame a lot. When teams get bogged down in assigning blame, they aren't fixing the problem. When you're focused on CYA, you aren't focused on helping your team members resolve the resulting issues. If someone on the team steps up and takes blame, it creates space for the team to focus on solutions. But there's an even better way. Have a team culture that doesn't worry about assigning blame in the first place.

If you behave like you own the outcome - you don't care how we go to this point. You're focused on what needs to happen to resolve the issue and get things back on track. Later, you might want to circle back and figure out what we need to change so it doesn't happen again. But even that's not a focus on assigning blame, that's a focus on fixing what's clearly a broken system. 

Ownership isn't just about blame. Ownership is also about: 

Caring about the outcome. If I own something, my first goal is to finish. To get it done. Deliver the thing that's needed. And not just to deliver the minimum, but to deliver the best version of that thing I can do with the resources (time, money, etc) that I have available to me. And to do it in the timeframe that I agreed to do it in.  

Caring about the quality of the result. This is certainly similar to caring about the outcome, and could arguably be included in that statement. But it's worth focusing on as it's own aspect. When I deliver a thing to you, I own all aspects of it's quality. Even if I didn't do all the work, I'm implicitly telling you that all of the work met my quality standards. 

Caring about the way in which we reach outcomes. In my push to deliver, I can't burn people out. I can't take short cuts that will undermine the long-term value I'm trying to create. I can't change the process - just this one time - because we're under pressure. When do pilots most need their pre-flight checklist? When they are rushed, tired, and not focused. They most need it when they are most likely to want to skip it. 

Communicating progress. If you ask me to own something - and I accept that - then I'm also accepting the responsibly to make sure you know where I'm at in my process of delivering it. It's on me to make my progress visible. If you have to ask me for an update, I've failed. 

Stepping up, without being asked. See something out of place? Fix it. See someone struggling? Offer to help. See a problem down the road that no one else sees or is focused on? Come up with a solution and pitch it to the team. If I own it, no one's going to ask me to do something. I need to know to step up and handle it. 

Giving people feedback. If I truly own the outcome, the quality, and the process - and I'm working as part of a team - than that means I need to be prepared to give the team around me feedback. If you're not meeting expectations, I owe it to you to tell you realtime. If you're deviating from the process the team agreed to, I owe it to the team to step up and say something. If you're a jerk in a meeting, I owe it to you and the team to pull you aside afterwards and say something. Did you know that own and owe come from the same root word? "...before 900; Middle English owen to possess, be under obligation, have to pay;..." Owners (leaders) have an obligation to provide feedback. 

What do you own right now at DT? A project? A process? A story? A feature? A client commitment? Nothing? 

For the things you own, are you stepping up, caring, communicating, and providing feedback? If you aren't, who's to blame? 



The Value of a Company Meeting 

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

As I'm sure you've noticed, the company meeting has fallen off your calendar. We're moving it to once a month. This email provides a bit of background around why we have the meeting, why we've moved it, and what we hope to accomplish with it going forward.

The $115,000 meeting

Let's do some math. We have around 40 billable people right now at DeveloperTown. Let's assume that when they bill, they bill at an average rate of $100/hr. That's lower than we typically charge, but if we use that rate we can assume it accounts for things like discounts, bench time, etc.

If we wanted to pull those 40 billable people into a room together for 30 minutes, it would cost us $2,000. If we then layered on all the other folks who attend the meeting who aren't billable, and what their time costs in hard costs, you might get to $2,300 for the total cost for that meeting. If you hold that meeting 50 times a year, that's $115,000 annually. Gulp.

Do you feel like we got $115,000 in value over the last year? I don't.

While the math isn't really that simple, it's a great little thought exercise. It shows how small things add up over time. And it also illustrates how we've grown as a company. That same meeting, in 2011 would have cost the company something like $35,000 annually.

Spec night, Five Guys, and a company-wide Scrum

Let's go back in time. My memory isn't perfect for things like this, but I'll do my best. If I get some of the specifics here wrong, you can fact-check with Please forgive me if it's not 100% accurate. The spirit of this history is correct.  :)

Our first informal company meeting started happening within the first few months of DeveloperTown opening. We started going out for drinks at Rock Bottom one night a week. It was always a very late night. We'd close out the bar most times we did it. It was a chance to review the week together and share some laughs. It was a completely informal event, where whomever was available and was working late attended.

Our first regularly occurring company meeting was a meeting called DT Pitch Night (sometimes called Spec Night). It also started in our first year, and occurred after hours. We would provide beer and food. Everyone would pitch different product ideas that we considered building as a firm. There were some small firm-wide updates that would happen at this meeting, but it was mostly about pitches and collaboration. Pitch nights died off after about a year. We didn't end up doing most of the projects, so people lost energy. Dave Christiansen morphed them into Hack Nights - which did survive for awhile. But those were much less formal.

Our second informal company meeting took the form of Five Guys Fridays. These all happened in 2011. Each Friday, whomever was around would go out together to break bread. No agenda, just food and catching up. When we switched offices, we tried Boogie Burger for awhile. But it wasn't the same. They died off after only a year of all-day awesomeness.

When we moved to the new building (where we are now), we started our second formal company meeting. You'll love this one. We did a company-wide daily standup, and it was in the classic Scrum format: What did you do yesterday? What are you doing today? Any blockers? This was actually kinda awesome when we started doing it. We were a smaller firm, so it probably didn't take us much longer than it takes the Tyco team to do theirs today. But - as you can imagine - as we grew this became unsustainable. A really great idea, that became a bad idea over time. It died in 2013.

In 2011, we started a meeting called the DeveloperTown Retrospective. Playing off the theme of doing Scrum activities firm-wide, we did an all hands retrospective once a month. This one didn't last long. As you can imagine, it also got too unwieldy as we grew.

Finally, we have the actual Company Meeting. The one we all know and love. It started off in 2010, and it was monthly. Here's one of the early agendas I sent out for that meeting. I found this randomly while doing my history research:

Company Meeting Agenda

1) Quick "state of project" updates

2) Current "active" sales leads

3) Housing Update

4) Financial Summary/Highlights

5) Questions

6) "Get ready to be social."[4,10].sub(/a/,'e').delete('').split('dyto').join.reverse.capitalize

Heh.. I'm a dork.

The format and the frequency for the core company meeting has changed from time to time, but some basic themes continue to come up:

 financial updates
project updates
housing updates (*sigh*)
introduction of new team members

What's the real goal?

At this point, you might be wondering what the real goal of the meeting is? Why experiment with so many formats? Why does it change? How did it get to be so ineffective? I think there are a number of reasons why companies like ours hold all-hands meetings:

  • Community

  • Culture

  • Information

  • Education


One reason is to build community. That's what you see in Rock Bottom, Five Guys, and Spec Night. Those were community building events, where we got to know each other. I see Peter Lockhart about three times a year, and each time I see him I kinda want to hug him. That's how close we were as a team.

Going out for burgers is a great way to build community with ten people, but it doesn't work with 50. Don't get me wrong, it's huge when Julie or Korey organize a cookout. And I know the marketing team has a regular monthly outing. But it's almost impossible to recreate that level of intimacy when you reach our size. Donuts and Kolaches on a Monday morning just don't cut it. I want them to, but it's not the same.

Community is also built when you know who everyone is. It's intimidating to join a new company. And I think our company might be more difficult than most if you're new. I suspect houses don't help when you're first trying to get to know people. Having people introduce themselves is one small way we can help folks start to get to know who the new folks are. And at a minimum, you know you'll get a chance to run into everyone at least once a week.


Most consulting firms take steps to recognize top performers. It's not always by calling them out publicly at a meeting, but recognition is an important part of building the culture you want. By highlighting the behaviors you want others to exhibit, you can signal to the rest of the team what are viewed as effective behaviors.

The company meeting is also where we (the leadership team of DT) get to visibly show who we are. There's something special about watching Jason Vasquez do live coding. I think in that company meeting you could see how approachable he is, how humble he is, and how measured he can be with his responses. I don't think he could effectively communicate those traits through email or Slack. You need to see those traits in action - interact with them. For most of us, when will we have time to do this with Jason outside of the company meeting?


I think we'd love to do open book accounting. We've flirted with it over the years. It turns out it's really hard to do. It takes time, attention, and consistency - none of which Michael or I possess. :) So it just never happens. But we've always been fairly open with the financials here at DT. We think that's part of building the culture we want - where our consultants understand the core numbers and metrics that move businesses.

We also think people want to know what each other are working on, and what future projects are coming that you might get a chance to work on. It's fun to hear stories about what others are doing. It's nice to see something cool, and say "Wow! We built that?" Sharing project results and sales efforts can help build pride in the work that we do. Hopefully that helps with retention - and helps keep folks motivated even when their current project maybe ins't the most exciting.


One of our values is Level Up. While that's about you as an individual getting smarter, better, faster, it's also about us as a firm getting smarter, better, faster. How do we actually do that? It's easy for any one of us to pick a topic and get better at it. But how do you move a firm to change? How do you roll out something new company wide? How do you introduce a new idea?

One of the things you've seen over the last year was an experiment to give each team focused time to dive deeper into their practice area. This resulted in educational and working sessions focused on trying to level up the company. I think we had some winners and we had some losers. It's a hard thing to be entertaining and enlightening at 9 AM on a Monday morning when people are still rolling in ten minutes late and you can't hear more than ten feet away.

Fixing what's broken

I'm aware that many people are frustrated with the current meeting. There are good reasons why we try to hold the meeting, but they are (currently) ineffective. We can do better. We will do better.

Here are some of the changes coming, and why:

  1. Moving to Monthly: The meeting will be going back to once a month for 45 minutes. This is partially due to physical logistics - we're going to do a venue change. But it's also because we want to spend more time prep'ing as management team. This should hopefully translate into more crisp and meaningful content.

  2. New Location: We're going to try to hold the meeting in the Starts space (2nd floor - big blue building). The goal of the venue change is to make it a bit more of an intimate setting, and to make the remote experience better. This should make acoustics all around better for all.

  3. New Format: We're going to experiment for a bit, but the idea is to lock into a fixed agenda for topics going forward. No more team-specific meetings. We'll move back to a standing agenda format. (Have some patience as we attempt to settle into a routine.)

  4. Meeting Notes: I haven't decided if this will be actual meeting notes, or if Aaron and I can rig up a recorded version of the meeting based on fancy new technology. Either way, if you miss the meeting - we will have either the cliff notes version available for you, or a recorded session you can watch in between episodes of the Walking Dead.

  5. Better Participation: This is where you come in. As a leadership team, we're going to up our game. Here is where I ask you to up yours. Participate. Get there before 9 AM. Try to engage with the topics - when appropriate. Be supportive. Not asking for you to become a cheerleader. Just asking for you to engage in the same way you would if a client were in the room.

We have a number of methods of communication: company meeting, team meetings, these emails, newsletters, etc.  Our goals for the company meetings are (in this order) Community, Culture, Information, and Education. The first two only happen with your help. The last two should start to go up in quality now that we're back down to monthly.

Looking forward to seeing you at the company meeting on the 10th.



The following is an excerpt from an email I sent to DeveloperTown in December 2016. 

Last week I finally had a chance to read (listen to) The Obstacle is the Way by Ryan Holiday. It's a highly acclaimed book - especially in professional sports. I'd classify it as a modern (almost pop-y?) look at stoic philosophy. It was a good read.

There was a particular quote that jumped out at me while listening. It's from the chapter titled "The Timeless Art of Turning Adversity to Advantage:"
"It’s okay to be discouraged. It’s not okay to quit. To know you want to quit but to plant your feet and keep inching closer until you take the impenetrable fortress you’ve decided to lay siege to in your own life - that’s persistence.” ― Ryan Holiday
I'm a quitter

Before DeveloperTown, my longest job out of college was two years. That was at Liberty Mutual working with Julie. Before working with Julie, my average time with a client/employer was probably five months. Now, in my defense, I was mostly a consultant. So I'd jump in, work to solve a problem, and then jump out. But I was good at what I did. Many companies asked me to stay longer. Why did I always leave?

Because it was always easier to find a new gig than it was to figure out how to change the culture of the team I was on. Changing culture is hard. Arguably one of the most difficult things you can do in an organization. Someone on the team who acts like a jerk? Cool. I'm only here for two more weeks. Management keeps failing to communicate why seemingly arbitrary deadlines are set? Cool. I've already committed to start that new project in Chicago next month. Stories getting delivered where quality was so poor I couldn't even exercise the basics of the feature? Cool. I'm going to work with CompanyA/CompanyB/CompanyC in two weeks. They will be better, right? (Wrong.)

I'd quit. I didn't leave after I had changed the thing that was bugging me. I left before even attempting to. This has resulted in a critical problem for me - lack of experience.

Over the last seven years, I have been figuring out how to really influence others for the first time. I acted like a child in early partner disagreements. I had never really had to argue with someone for something I wanted. I don't really know the right ways to hold someone who reports to me accountable and how to coach them to higher performance. Coming into DT, I really only had four years of management experience. I still struggle to detach myself from a situation and look at it objectively. Something you have to learn to do if you really want to identify systemic issues so you can pull the right levers to influence sustained change. 

" plant your feet and keep inching closer..."

I've decided to plant my feet here at DeveloperTown. I'm learning a lot, but it's still hard. So how does one develop persistence? Some un-researched ideas:

  • I think stoic philosophy is a good place to start. I have a dog named Seneca for a reason. Maybe I'll name next year's pigs Marcus and Aurelius. Is that wrong? If you want to give stoic philosophy a shot, I'd recommend either Gates of Fire (a super fun read, with some deep meaning hidden in the story) or On the Shortness of Life (my first read in stoic philosophy, hugely impactful).
  • I also think you need role-models around you. People whom you see persist in the face of adversity. For me, that's many of my peers here at DeveloperTown. I'll resist naming some of them, because all of them have at one point or another shown me persistence in the face of adversity. I also see persistence in many of our clients. Sometimes I may think that persistence might be wasted on a particular product - but it doesn't negate how inspirational it is. To see someone pushing their idea/business/goal forward in the face of overwhelming odds is simply awesome.
  • Practice persistence in smaller ways by doing other things in your life that are hard, but not quite as hard as what you're trying to do at work. I've wanted to quit aikido a couple of times now. Early on it was because of the pain from my back injury. And later it was because of frustration with slow development of technique. There were two times I drove away from the dojo thinking I was done - never going back. Both times I ended simply deciding I wouldn't let myself quit. Not for those reasons. Once I have my blackbelt, if I want to quit then - I'll let myself. For you, it might be the book you've been working on. It might be a personal fitness or health goal. It might be a broken relationship in your family or past friendship you've been putting of mending.
  • Find someone you can talk to about the challenge you're facing. I still want to quit DeveloperTown when it's hard. Michael - almost annually - has to talk me off the ledge. I know that sucks for him. I'm sure a third of those gray hairs on his head are from me. Even though I know it's difficult for him, when I need that annual pep talk it's critical for me. He provides a perspective I often forget. He reminds me of why I want to gut it out. That's immensely helpful. When you have someone to talk to, you're not alone.
  • Breakup the journey into smaller victories. We will likely never finish "changing DeveloperTown's culture." That's an impossible goal. Because our culture is an amorphous thing that changes over time and is impossible to fully understand and measure. However, I can affect it (hopefully for better) to move in a specific direction for a period of time. I'd love to see us get better at giving each other feedback. (reminder: When you do X, I notice Y, going forward can you Z?) I might win a small victory by beating that drum over the next year, but while I'm focused on feedback, I'm not focused on other aspects of culture. I need to focus on that small victory. As Holiday puts it, that's "inching closer until you take the impenetrable fortress" of company culture. Win the inch. Over time, you'll win the fortress.
Why talk about persistence?

As we grow, I'm sure we all see things that we'd like to change, we wish things were different, or we hit a wall on a specific project, team, or relationship. The easiest response is to get frustrated and checkout. Even if you don't move on right away, you can be checked out for months. Sometimes that instinct might be the right answer for a very short period of time (calm down, detach from the situation, reflect on your own behavior in the situation), but you need to check back in at some point. When you do, how will you respond? Will you keep inching closer to the outcome you want? Or move on?

I hope you inch closer. I plan to.

Feedback welcome. (See what I did there?)

Researching an Idea

The following is an excerpt from an email I sent to DeveloperTown in September 2016. 

As most of you know, we hear a relatively large number of ideas for products and businesses. This week I thought I'd share my process for how I do research for an idea, and maybe share some examples from the past.

Each of us who hear pitches have our own process, but most of us run a quick checklist of questions (no particular order):

  • Is there an obvious market for this product? How big might that market be?

  • How would/could it make money?

  • What are the complexities of a product like this?

  • Is it technically feasible?

  • Is this a zero to one product (aka the iPod - your entire music library in your pocket)? Or a derivative product (aka Uber for lumberjacks)?

  • How would you have to market or sell this product?

  • Can this product "work" with a small number of users or data - like what you'd see when first launching?

  • Are there eventual network effects for a product like this?

  • What might it cost to develop this kind of product?

But by far, one of the most important questions is:

  • Is there anyone already doing this?

And the answer to that drives a couple more important questions:

  • If someone is already doing it, how have they performed?

  • If someone isn't doing it, has anyone tried it in the past?

  • If someone isn't doing it now, who would they be displacing in the market even if they aren't a technology competitor? (Think Uber vs. taxi companies and municipalities.)

Researching competitors and finding traction

There are a number of ways to do research on competitors. Google is an obvious place to start. And you may be surprised how many ideas pitched to us fail the basic Google test. But let's assume you've done a couple of obvious searches and not turned up a competitor. Where would you go next? Here's a short list of places I often search...

I use these the most:  

These can sometimes be useful or have hidden gems. This is the list if you need to go deep:

Or, sometimes you have to check specific accelerator portfolios. I like checking,, and

If you find a hint of a company that might have been a competitor in the past, but is now defunct, the Wayback Machine is a great place to do some research on them: Another great place for dead startups (with some details around the failure) is Autopsy: (I only wish they had more companies listed.)

All of those above sites can also provide traction information, but I also like Startup Tracker ( which has a fairly nice Chrome Extension. It's not super helpful in helping you find competitors, but once you've found a company you want to research, it's great at providing a summary of where they are at.

A quick example

Here's a fairly solid recent example from Jacob Cloran. I asked for his help in researching an app idea that I knew wasn't great, but the person who had the idea has some serious credibility. So while I suspected that Jacob would end up killing it with his research, I wanted the prospect to have a great experience with us. I wanted him to see that we took him seriously, and that we did our homework.

Here's the idea:

<removed from the blog post version - sorry> 

Here's a summary of Jacob's findings (using some of the above resources, and some of his own):

<removed from the blog post version - sorry> 

Killer right? On multiple levels. Great research, and killed the idea (for now). The entrepreneur has gone off to do more research. I hope he comes back in a few months with his next idea - because I definitely want to work with him.

Outsourcing some of the hard work (Fancy Hands)

Sometimes this kind of research is easy to handoff to a transactional service. There are a lot of them, but I'm a fan of asking Fancy Hands ( to do research for me. I've had them do research similar to what Jacob did above. It wasn't nearly as comprehensive. But for a "fast" low-cost search, it can be a nice place to start. A better way to use a service like Fancy Hands is to give them a spreadsheet of companies and ask them to fill in the blanks around traction data. Or you can ask them to hunt down a specific detail across a number of companies (like pricing).

Here's an example from about a year ago where I asked them to help me run down competitor pricing:

<removed from the blog post version - sorry> 

Pro-tip: If you want to get really fancy (see what I did there?), you can ask them to take a data dump like that and try to turn it into a chart of some sort. That kinda of chart can look awesome in a deck or business plan.

What does traction look like?

Once you've found a competitor (or twenty), how can you tell if they matter? Here are some things I typically look for:

  • Funding - Have they raised capital? How much? When?

  • Users - How many page views do they get? How many app downloads? How many reviews?

  • Marketing - I've seen Briggs (and Eggleston before him) produce killer reports and data around SEO rankings, AdWords traffic, referral traffic, and ad networks.

  • Social - Do they have followers? How many? Are they still active?

  • PR - Are they ever in the news? How often? When was the last big PR push? Where did they get traction (local, national, niche, etc)?

  • Pricing - What do they charge? If it's free, is it obvious how they make money?

It's hard to put hard and fast rules around how much traction is "too much" to compete with. But I feel like you know it when you see it.  :)

Have a great weekend,




Billable Expectations: 40 / 168 / 1,800

The following is an excerpt from an email I sent to DeveloperTown in April 2016. 

Let's start this discussion with some magic numbers. Most professional services firms run off of the same set of assumptions when it comes to billable resources.

Keep in mind, we're talking about billable hours. There are billable hours (we can charge out clients for that time) and there are non-billable hours (personal development, time off, team meetings, time spent moving houses, lunch with me even though it feels like work, etc). And some weeks, you don't always have line-of-sight on 40 billable hours. Ignore that complication for this discussion. This all assumes there's 40 billable hours of work available for you to do.  :)

40 billable hours in a week

The most basic magic number is the 40 hour work week. This one likely doesn't need much description for where it comes from. It's eight billable hours in a day, five billable days a week. If we were a staff aug firm like Anchor Point, the expectation would be 40 billable hours minimum - no exceptions. On the other side of that, we know of several consulting firms that do fixed monthly fees for their people where they bill out a "full time" resource with a 36 billable hours per week assumption. That four hours of slack provides a placeholder for company meetings, personal development, etc.

Here at DT we've been historically silent on defining a hard rule around 40 billable hours. We've always said that should be the target, but that you're mileage may vary based on the project, overall workload, etc. As a general rule, if you bill between 36 and 40 hours in a week, you're likely going to be okay. Over the long run, the expectation is that you should be averaging 40 billable hours a week - assuming you have productive work to do. If you don't have client work to do, escalate to your manager or to an engagement manager for any projects you're on.

What does a perfect week look like? It might look like this...

You should see a solid chunk of billable hours (north of 36 hrs), and a couple of line items related to the company or your team.

168 billable hours in a month

Most consulting companies estimate that there are 168 billable hours in a month for each billable person. There's some fuzzy math to get to that number. But most reasonable measures will get you to something close to that. A quick example:

  • 40 hrs per week x 52 weeks = 2,080 hrs in a year

  • now divide by 12 months to get 173 hrs per month

  • now give someone two weeks off (so [40x50]/12), and you get 167ish  

This is the first time you see an expectation of utilization come into play. Quick reminder: utilization is the percentage of billable hours for a person in a given period of time. While we ignore an expectation of utilization in the weekly number, 168 has an expectation of 97% utilization. Here you see the first baked in assumptions around time off, sick time, and slack.

This number can be a nice number to look at to see trends. In any given week someone might be sick, have something odd happen on a project, etc. However, when you zoom out and look at a month, you can see the trends. For example, last month no full time employee of DT logged less than 172 hours for the month. (Yea! Go DT!) However, there were only 10 people with more than 168 billable hours.

Again... not necessarily an issue. This isn't a hard and fast rule - it's just a heuristic. Some roles (like mine) aren't expected to be full time billable. Some people were between projects for a week or so. It's a useful number to watch at a macro level.

1,800 billable hours in a year

Most consulting firms estimate around a 90% utilization annually. That's around 1,872 hours annually, or about five weeks non-billable. Notice I didn't say five weeks of vacation. That might be the reason. It might also be that people are between projects or we assign people to non-billable work (like our very own DT website). It also includes holidays.

We're actually a bit more conservative here at DT. Given the nature of our projects, we've recognized that we actually tend to average more like an 86% utilization. Obviously we'd like to raise that up a bit over time, but it means we're averaging around 1,800 billable hours per year for each billable person. It's a great number to track at the firm level. And this means that there's a bunch of time "budgeted" for vacations, holidays, team events, people getting sick, and bench time between projects.