What happens in the resourcing meeting?

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:

  1. 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.

  2. 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.

  3. 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.  

  4. 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,





Consulting Metrics 101 and the Real Cost of Soda

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.  


  • 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.


  • 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?  


  • 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.




Why we make bad decisions

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,


NDAs for startups

We hear a large number of pitches here at DeveloperTown. Some weeks we only hear one or two, and other weeks we can hear up to twenty pitches. It’s one of the more enjoyable parts of my job. Everyone is excited about his or her idea. And it can be contagious. I love it when by the end of the meeting I’m excited about their idea too.

One of the most common questions we get asked before someone comes in to pitch is what (if anything) the entrepreneur should do to protect themselves and their intellectual property before the pitch. The most common way entrepreneur’s are advised to manage this risk, is to get people to sign Non-Disclosure Agreements (NDAs) before they share their ideas. There are several reasons why we believe this is a bad idea. 

You’re already not getting enough feedback.

Most entrepreneurs don’t get negative feedback. We live in a polite culture (especially here in the Midwest), where people are supportive and want you to be successful. They also don’t want to be the one to crush your dreams. So most of the time, if you pitch someone an idea, they’re going to say something like, “You should do that, follow your dreams!” or “I’m sure there’s a market for that somewhere. I just don’t know enough about it to give you valuable advice.” Or they will pick out the two or three most positive things, and focus on those.

Most people don’t want to be critical. They won’t challenge the idea with the goal of making it a better idea. If you want valuable feedback on your idea, in many ways you have to go to the people with an economic incentive to tell you both the good and the bad. Those are (in priority order): your potential customers, the team that will have to build or deliver that service, or your potential investors.

NDAs create a barrier between you and those groups You don’t want that barrier. You need the feedback. Anytime you ask for someone to sign your NDA, you’re giving them an excuse to not talk to you about your idea. But more importantly, you’re less likely to even ask them in the first place because you’ll be afraid about sharing and talking about your idea. Talk about it.

You’re protecting against one of the least likely reasons you will fail

A lot of technology ventures fail. We have seen a number of our own portfolio startups fail. One of the least likely reasons you will fail is because someone else steals your idea. It’s more likely you:

  • won’t get funded;  
  • will never actually get the product built correctly and successfully launched;
  • won’t find product market fit fast enough and you’ll run out of money;
  • will get into a big fight with your co-founder(s) and the team implodes;
  • get traction with a small segment of the market, but can’t break through and end up failing anyway due to market competition.

I know, right? This isn’t a feel good blog post. Sorry.

Bad people do steal ideas. We think we’ve seen it happen to one of our customers. But it happens very rarely. And even in the case where we think we saw someone steal a client’s idea, the person who stole it (and built it) failed. That business is gone, and they’ve pivoted into something completely different. And as harsh as it is to hear, to me that sounds about right. You need a good idea, but you need way more than an idea to be successful. 

Some people can’t sign your NDA for liability reasons

You should do an internet search for the phrase “Why VCs can’t sign your NDA.” You get a lot of results. My personal favorites are from Feld, Kawasaki, and Startup Lawyer. I love the phrase from Startup Lawyer, “Asking a VC to sign a NDA is tantamount to splitting 10’s at the blackjack table.”

If a company makes its living hearing pitches for startups, it hears a slightly different version of the same pitch anywhere from 2 to 20 times a year. Most ideas aren’t new, aren’t unique, and aren’t proprietary. Sometimes they are, but those are the exception. In cases where your idea isn’t unique (which no one can possibly know until they’ve already signed the NDA), then that firm has opened itself up to potential liability if choose someone else’s version of the pitch over yours.

That means each time an investor (or a firm like ours), signs an NDA, they are leaving a small trail of liability behind them. Regardless of if they end up working with that prospective client.

How are entrepreneurs protected in these situations? Because the person you’re pitching to in these situations is putting their public reputations on the line. We’ve build a nice successful business at DeveloperTown. It’s already a multi-million dollar idea. Trust me… we don’t need another one to manage. This one is enough. We aren’t going to jeopardize this business by stealing someone else’s idea. Not only am I fairly sure the idea isn’t unique; we’d be starting over again with all the risks a startup has. (See that uplifting list of reasons for failure five paragraphs up.)

You need to work on your elevator pitch anyway

All of that means you need to be able to talk about your idea at a high level – with a bunch of different people. In some cases just so you can get feedback. In other cases so you can hire employees or vendors. And certainly if you want to fundraise. You should always be able to talk about your idea – any idea – at a high level with out exposing the secret sauce.

If you can’t talk about your idea in 30 to 60 seconds without giving away what you think is the “magic” in that idea, then we would be very skeptic that someone else hasn’t already thought of it or could think of it relatively quickly. So think of this as your chance to get really good at telling people what you’re doing, without giving away the secret sauce. If you have something that you think is actually patentable, don’t talk about that in detail. Just give the exec-summary.  You can still go protect the IP. 

NDAs at DeveloperTown

So when do we like to sign NDAs? Once you become our client. As soon as you become a client, we include an NDA in every statement of work we send out. We absolutely want to protect your intellectual property. Because once you’re a client, there’s no longer a risk of you coming back to us years later saying we chose someone else’s version of your idea. Clearly… we chose you.

We will also sign NDAs when a large enterprise client approaches us to see if we can help them with innovation. The incentives are different for large firms. And the type of information and they way they share it is different as well.  In many cases, it’s not just a pitch. It’s real market data, proprietary data from their other existing products, and other rich sets of data we can apply to the problem they are asking us to help them solve. There are also (in most cases) non-IP related barriers to entry with the products being pitched that these companies can overcome that others couldn’t.

So schedule some time to talk with us, know that we put our reputation on the line each time we sit down with someone, and we’re excited to give you both positive and negative feedback. We love helping people start businesses. In many cases we view it as part of our role in the Indianapolis startup community to give feedback to startup ideas, knowing full well that we aren’t likely to be the partner you may choose to build with. It’s just part of what we do. 


How to become more offensive

Two weekends ago I listened to the Tim Ferriss interview of Chris Sacca. Sacca is an early-stage investor in companies like Twitter, Uber, Instagram, Kickstarter, and many more. He's a fairly well known dude. The best audio I've ever heard from him was of him crushing Alex in the Startup Podcast, where he perfected Alex's own pitch for him because Alex was too nervous, and then told him it was a horrible idea. 


In the Tim Ferriss interview, Sacca explained why he moved away from Silicon Valley. Sacca moved to Lake Tahoe at what many would have considered the absolute worst time for him to leave the Valley. He had just lost a ton of money, he was still relatively young and unknown, and he was leaving the most connected area in the world for software startups and investors (aka his job). 


While Sacca was living in Silicon Valley, he had to be defensive with his time. He constantly had people asking him to grab a cup of coffee, to hear their pitch, to give them feedback, or to attend an event. All of his time got sucked up by other people. Even if he said no to the obvious events and people that were a waste of time, his time still got consumed by "legitimate" events and meetings with people he knew and trusted. He was just too connected. While he was being defensive, he found that he wasn't actually getting anything done. 


Part of the reason Sacca moved away was to get the time back, so he could be more purposeful with what he did. He called it, "playing offensive." Instead of constantly defending your time, how can you make space in your life to move to a purposeful offense. If you had more time, what would you do with it? What's your highest and best use? 

Lake Tahoe is around three hours from the Valley. That turns out to be the perfect response to people asking for coffee, drinks, or time. Sacca still said yes, he just told them they needed to travel to him. It was the perfect filter. Most people won't be willing to make that type of commitment. So only the most serious people followed through on the trip out there. 


With his new found time, Sacca pulled himself out of dept. Doubled down on startup investing and advising, and is now running what might be the most successful investment portfolio in history. He's crushing it. And he points to figuring out how to "play offensively" as one of the most important factors. 


Since hearing this podcast, I've been thinking about this a lot. I'm very defensive with my time. I have a never ending stream of meetings, requests for time from clients, requests to pitch from prospects, meetings to explore partnerships, networking events to attend, etc. Never-mind the emails that go with all of that, the commute, and trying to find time to workout. 


I'm guessing I'm not alone. I can imagine you have tasks and activities that make you defensive with your time. I know you have emails, meetings, and I know each role has it's own set of tasks that take up time, but aren't the "core" way that you think you add value. It could be as trivial as time entry, or it could be a regular report you need to put together (ems), a pull request (devs), a regularly scheduled Twitter post (marketing), or something else.  (I just assume that the designers love everything they get to do.) 


We all play defense. It sucks. But it's certainly part of the job when we work as a team. As we continue to grow, the more defense we will all have to play. So how do we handle that? 


At the last Monday morning meeting at DeveloperTown, Aaron Lerch shared some of his strategies for how he manages some of his time and attention. It included tips for email, Slack, meetings, and the dangers of multiproject multitasking. (Side note, I just changed my preferences to disabled emails from Slack. Thanks Aaron!) 


As for me, I'm not sure yet. I've been thinking about it for two weeks now. I don't have the answer yet, but I have some ideas. Here's what I'm doing to try to become a bit more purposefully offensive with my time: 
  • I'm going to reread The Effective Executive by Peter Drucker. I first read this book over ten years ago. I remember the themes, but not the specific details. I think it's time for a refresher. The basic premiss of the book is that all knowledge workers are executives. And executives need to prioritize effectiveness over efficiency if they want to be successful. 
  • I'm going to only check email a couple times a day. While that turns out to be very difficult to do in practice, I'm trying out a new tool called Handle that I think will help me do it. It integrates with Gmail, and has a view that completely hides your inbox while still allowing you to work on tasks and priorities. I've been using the free version for a couple of days, and so far I really like it. I hit inbox zero for the first time in over two years, and I have a clear list of to-dos that have been prioritized and assigned due dates. 
  • I'm going to try to be more purposeful with my days. I'm planning to start each day by listing the top three to five things I want to accomplish that day. And then my plan is to not leave until those tasks are done. If I can't manage to that effectively, I'll shorten the list to the top one or two things. My goal isn't to end up staying at the office later, but instead to train myself to remain focused on those goals throughout the day so I become more protective of my time to actually get them done.
  • I'm going to experiment with sending my peers a short email status each week. No one has asked me to do it. But I think if I can come up with weekly goals, it will help me figure out what my daily goals should be. I'm thinking a short list of bullets - nothing fancy. If I have to take the time to report progress to my peers, then I think it will help me remain focused on those top priorities. Ideally, most of what I'm reporting on each week should roll up into the larger plans we set as a management team. 
  • I'm going to start to ask for help more frequently. I don't need to do everything myself, and in many cases I'm not the best person to do certain tasks. I'm going to try to be more purposeful in handing off tasks and responsibilities to the people who are best equipped to handle those tasks. This is very difficult for me. I suspect it's difficult for all of us to ask for help, and that none of us is doing it enough.  
So that's my starting plan for my new offense. I doubt I'll stick with all of those, but hopefully I'll make some progress in figuring out what works for me. 
If you have some techniques you use to better manage your time/attention/focus, you're welcome to share it below.