Saturday
Nov192016

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,
Mike

Friday
Nov112016

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. 

Saturday
Jun112016

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. 
Friday
Aug282015

Advisors and Board Members

As a partner in DeveloperTown, I have an interesting role when it comes to our clients. Part of our pitch to our clients is that we are more than a vendor - we want to be a partner. In many cases we want to have skin in the game in the form of an investment, but even without an investment we really want to play a leadership role when it comes to technology and determining product-market-fit. Most of the time, this leadership or advisor role is informal. By choosing us as a technology partner, you get some portion of our leadership team engaged in your business (for better or worse). However, at times, it can be unclear how much of an advisor our client is expecting and/or looking for, and how much we are prepared to provide. When things are informal, there’s a chance for missed expectations. I hate mismanaged expectations. So occasionally, it makes sense to formalize the relationship so everyone’s on the same page. ...

Click to read more ...

Tuesday
Jul152014

Why the RFP process doesn't work

Why does an RFP process lead to increased cost? Without discussion of the many tradeoffs noted above, there’s no room for the technology team to recommend alternative methods to accomplish the end goals. Ideally, you’d like to find a team to help you solve a problem. Instead, most RFPs tend to lead to teams implementing a given narrow solution. Which assumes the problem is fully understood and adequately solved by the submitted proposal. It costs more to be wrong and have to go back to first principles than it does to move in a more exploratory way at the onset where you continuously question core assumptions and validate those assumptions over time as the project unfolds.

Click to read more ...