Bees, Experience, and Craftsmanship

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

This week I purchased bees for the farm. It's a bit scary for me. But Patrick decided that bees would be this year's farm experiment. (That's the last time I let him choose.)

You know the security questions for username and password verification on websites? The ones where they ask, "What's your greatest fear?" Guess what my answer to that is? Bees.


Like with any new animal experiment, I have to immediately read four books on the topic before I feel like I'm even remotely prepared. Bees are no exception. I've already read most of Beekeeping for Dummies and a few months ago I started listening to a beekeeping podcast.

Yup... There are beekeeping podcasts. God bless the internets.

In the Beekeeping for Dummies book, the author makes an interesting point around getting started. The book covers everything you'd ever want to know: bee biology, the hive, basic tools, lifecycle, selling product, etc. Some of it's actually awesome. Did you know that bees breath out of a bunch of little holes on the sides of their bodies?

In the "Getting Started" section, the author mentions that, for most beginners, no matter how closely you follow the "instructions" for getting started with bees, it's likely that for the first few years you're going to fail. He points out ten or so small nuance mistakes you will likely make, even though you're "taking all the right steps" that will likely result in the death of your hive. And he then points out that those are simply ten out of hundreds of those small mistakes.


This is experience. It's the difference between knowing the "steps" to doing something, and then getting the actual desired results from following those steps. It's the same with many nuanced tasks (think baking, playing music, or fishing). You might know exactly what to do, but that doesn't mean it will work.

The crappy thing about experience is that there's only one way to gain it. You have to do that thing. You have to plan to make mistakes. To fail. And to learn and grow. That means, if you want to raise bees, you have to be ready to kill a lot of bees through trial and error. (This process sucks for the bees. But this email isn't really about them.)

Think about what differentiates DeveloperTown from our competitors. Many consulting firms do work with startups. Many many more do work with large companies trying to launch new products. All consulting companies sell their "processes" and their "people." And we're no exception: "Hire DeveloperTown, we have a killer process refined over a 100+ projects, and we have a team of people who specialize in the art of the start."

That's not much different than the pitch other consulting companies make.


In 2008 Richard Sennett published a book entitled “The Craftsman." In that book he lays out his theory for what sets the craftsman apart from the "average worker." For Sennett, craftsmen "complete their work with abandon and always want to do well for their own sake.” For him, the craftsman stands for “the special human capability for committed conduct”.

The fundamental idea for Sennett is that expertise (aka experience) - not accomplishment - is what differentiates the craftsman from the "average worker." Many people accomplish tasks and projects, but not everyone gains purposeful experience in doing so. It's the craftsman who thinks about growth through experience as a "way of life."

Back to bees... If you want killer honey, I've read that you need to move your hive throughout the summer. You need to expose the bees to different types of flowers, trees, and conditions at different times of the year. If you want "okay" honey, you can just get bees and figure out how to not kill them. But if you want truly great honey, then the creation of truly great honey has to become a "way of life."

You have to beecome a craftsman.

What will truly differentiate DeveloperTown in the long run? Are we here to knock out client projects, and maybe gain some experience for our resumes? Or are we "completing our work with abandon" and being purposeful in the way that we learn so we can get better and better at the "thing" that we're specialized in? Do we really view our role in "the start" as a special thing?

We aren't always craftsman all the time. I'm trying to learn to be a better leader. I have a lot to learn, and I'm trying to take a craftsman's approach with my learning. But I'm not trying to be a craftsman in all aspects of my life - with other tasks. I don't think that's possible.

In most ways, my experience is average. In some ways, my experience is special. When it's purposeful, it's not just "accomplishment", it's growing me to become better at my core.

I think we are craftsmen at the start. And I believe we can (and will) get better at it. But to do that, we need to become purposeful in our learning. That means we need to be purposeful as individuals, and as a team.

In the coming months, as we look to better define our processes for innovation and how we build products, an underlying part of that process should include defining how we learn and adapt. I think this type of learning is easy to do as individuals, but it's much more difficult to do as an organization. And it's really hard to make it a "way of life."

But I'm looking forward to the challenge...

Have a great weekend,





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

I think most of you know that we're currently targeting Innovation as a key selling point to larger clients. It's a bit of a trend right now. Many of the larger companies we're exploring working with have Chief Innovation Officers, Directors of Innovation, and Innovation Review Committees.

No joke. That last one is real. Is there anything that sounds less innovative than an Innovation Review Committee? It sounds like a parole hearing for ideas. "Nope. Not ready for release yet. Send it back!"

Okay... focus...

Consumer product companies do innovation as a standard part of business. It's core to new product discovery and development. If you look at iconic companies like 3M, Nike, P&G, Sony, and DuPont you'll find time-tested processes that they use to develop and launch new products. They don't think of it as "innovation." It's just their job. That's how you stay alive as a consumer product company.  

If you look at the largest and most innovative technology companies (think Google, Apple, Pixar, Intel, and others in that class), then you'll see a slightly different innovation process. But at the core, even though they are focused on different types of products, they are doing many of the same things. Those companies - just like the consumer product companies - know how to develop and launch a product. It's their job too.

But there are different classes of companies out there where either innovation hasn't been their job, or they've forgotten how. Some simple examples of this might include:

  • a monopoly (natural or regulatory) who is no longer a monopoly (think electric companies)

  • a one-hit-wonder who now has to come up with the next generation product (think TiVo)

  • they became too focused on protecting market share (think Microsoft)

  • they are historically a services company (think Ameriprise)

  • they have pockets of innovation, but it's not something propagated across the company (think TaTa)

  • they acquire all their innovation externally (think current Yahoo)

  • etc...

For the first batch of companies (the ones who know what they're doing), we can add scale. For many companies (including DeveloperTown), the key limiter to growth is finding enough qualified people. For companies who know how to innovate, but they just don't have a large enough team to do what they want, we can help them as a partner.

For the second batch of companies (the ones who haven't mastered innovation), we can show them how. Here we can be a partner and a coach. Teaching them the principles behind what we do, so they can (maybe) someday do it themselves.

Focusing on this trend in the market is a great place for us. It allows us to leverage our story to serve a larger and growing market. "We've grown out of working with startups..." "We know what's possible with technology..." Etc... We have an authentic pitch for these prospective customers.

What we don't have, is a nailed down and easy to communicate process. In the coming weeks you'll see more focus on that. We'd like to define our "official" take on a process for innovation, and for building great software.



Start Something 

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

Not everyone may be aware of our tagline. If you’re not, it’s “Start something.” If you don’t know this history of our brand as communicated via our website, here’s a quick snapshot:

Caps and punctuation are what we posted on the website. There’s a story behind each of those taglines and where we were as a firm. Perhaps some time I’ll force Michael to write about the original vision behind “a venture development firm.” It was an awesome vision. But for now, let’s focus on “Start something.”

We have roots in startups. “Start something” is a great call to action for the entrepreneur on the fence. “Hey you! Stop thinking about it. Do it. Start something.” And maybe we can help you do it? In my head, I read it as a passive aggressive call to action. Or maybe aggressive - Start something!

Now that we work with larger companies as well, we can’t talk about co-founders, ideas, and venture development. Start something is a great call to action for someone within an organization who might be wondering where DeveloperTown fits relative to all the other consulting firms in the market. When do you choose DT? When you’re starting.

Let’s call someone (or a group of someone’s) starting something a Start. (I’m borrowing heavily from Cloran here. That’s his language I think. And I like it.) The reason DT exists is to support Starts. We try to hyper focus on saas and mobile Starts – but you’ll occasionally find us helping other Starts as well. We help not-for-profits, we coach entrepreneurs who aren’t always in software, and we will occasionally provide space (if we can) to all sorts of Starts.

The reason DeveloperTown exists is to support Starts. I once saw Michael write that as “…to encourage Starts of all sorts.”

This week, someone asked me why I was at DeveloperTown. I’ve been asked that a lot in the past, but I’ve always given a crappy answer. Or at least, the answers all sound crappy to me. I normally make something up on the spot. And while it was likely true, it’s never the real answer. This is my attempt at a non-crappy answer.

I originally joined DeveloperTown because I was bored. When Michael approached me with the idea, I was just getting ready to go back into independent consulting as a software tester. In the world of software testing, I was a big fish in a small pond. While I still have much I could learn about that craft, by any objective measure I was on top of my game, and I was getting bored. I was ready for my next challenge. DeveloperTown came along at the right time in my life when I needed a new challenge.

At the time, DeveloperTown excited me for three reasons: sales, finance, and impact.

Sales: As an independent consultant I had done sales, but it’s a very different thing to sell your skills versus selling the skills of someone else. And while I might have sold a $60k to $200k project as an independent, with DeveloperTown I’ve learned how to sell million dollar projects. I love it. It’s like chess and poker mashed together. And I’ve developed my own style that works for me. My style isn’t like any of the other partner’s sales styles. And I like that. I feel like I’m reaching a point where I’m experimenting with nuance in my technique. I feel like I’m starting to reach the end of my “journeyman” status. Someone go put on a pot of coffee…

Finance: I knew nothing – nothing – about venture capital six years ago. Because I never had a dry spell as a consultant, I never really had to manage cashflow. I also knew very little about structuring and managing debt within an organization. And while I could read financial statements, I didn’t really understand them like I do today. And you know what’s scary? I still don’t know all that much. And I love it. I love learning this stuff from Michael. This is his 10,000 hours. And there’s nothing cooler than learning from someone who’s on top of his or her game. And while I feel like my apprenticeship with Michael is almost at a close, I know that in the next five years I’ll learn as much or more about finance as we continue to grow this business. (Don’t read into that – Michael isn’t leaving and neither am I. It’s simply a statement on where I view myself on my journey.)

Impact: This isn’t going to be some flowery exposition on how one of our clients is going to someday change the world. In all likelihood they won’t. Not in the way people like to think about changing the world when they think of one-time startups like Facebook, Apple, or Google. That would be awesome if one of our clients did that. We’d have fun. But that’s not the impact that motivates me. I also don’t get really excited about increasing quality of life through the process of value and wealth creation that is capitalism. I love capitalism – and I believe in all that crap. But it doesn’t excite or motivate me. What motivates me are people. I get excited about the direct impact DeveloperTown can have in the individual lives of our clients and employees. The favorite part of my job is when I’m sitting in a room one on one with someone. I love to coach. When I was a consultant, I would coach other consultants on how to grow their business. At DeveloperTown I coach our clients on how to grow their business. My work – and your work – has direct impact on the lives of our clients. Not their customers. Not their investors. Not the other people in their organization if they’re an established company. Them. We get to make them successful. We get to be a shoulder to cry on.

With my background, I can’t think of a better way to have a larger direct impact.  It’s also why I prefer to consult – rather than work for a product company. If I just built software and sold it to people, I would lose the thing that’s most fulfilling to me. I wouldn’t get to form a relationship with my customer and see how my work directly affected them.  

The reason DeveloperTown exists is to support Starts.  

The world is better because our Starts create value. Our Starts are better because DeveloperTown makes their journey just a bit easier – and increases their chance of success. DeveloperTown is better because I can form deep relationships with its clients and employees. And I’m better because DeveloperTown gives me a bigger platform to help people. I think that’s why I’m here.

Why are you here?

I’m guessing you like the work environment. And I’m guessing most of you like the people you work with. I like both of those too. And maybe you’re learning something new. (You had better be learning something new.) And I bet – like me - you have your own vague and incomplete answer why you’re here. Take the time to find a better answer. It’s worth the thought experiment. The exercise has helped me.

Have a great weekend,




Who's your favorite entrepreneur?

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

About a month ago, I attended a workshop where we were asked to introduce ourselves by sharing who we were, and who our favorite Indiana entrepreneur was. It was cool if the same entrepreneur was repeated more than once, you just had to say their name and one or two sentences as to why you liked that particular entrepreneur. There were about 30 people in the room. So it was fun to learn about some local entrepreneur's I hadn't heard of.

I took the sappy route. (You'll notice that theme with me.) I said my father was my favorite Indiana entrepreneur. My dad ran four different retail businesses in my lifetime, all of them here in Indiana. I started working for him when I was nine years old. And by the time I was 13, I felt like I was working with him instead of for him. He taught me an enormous amount about business, without ever once making it "a lesson."

I'm interested to know who your favorite entrepreneur is. You work at DeveloperTown. And DeveloperTown clients are entrepreneurs. So it stands to reason that you relate to entrepreneurs somehow. Many of the DT family are entrepreneurs themselves (Matt, Jeff, Nick, Brian, and many more) and/or their parents/family were strong entrepreneurial influences on them. That was the case for me, and I'm guessing that might be the case for Devin, Kim, Daryn, and others.

If I weren't able to give my sappy answer, my (current) favorite entrepreneur is JW Marriott. If you don't know the Marriott background, there's a nice summary on Here are the cliff notes:

  • He was born into poverty.

  • He raised sheep. (I mean seriously... that's my ultimate goal with my hobby farm.)

  • He purchased an A&W Root Beer stand.

  • Through that A&W stand, he figured out that people who were flying needed food. Airlines did not provide food service at the time.

  • Most entrepreneurs would at that point go open a bunch of A&W stands around airports. JW Marriott did that, but he didn't stop at doing that. He asked himself what else might this underserved customer need?

  • Based on that question, he opened his first motel.

  • You know the rest of that story...

Very few entrepreneurs would do that. Most people - when they have success - do only that one thing. And that includes my father - and largely it includes me. It takes tremendous courage to step outside of what you know and to just follow a customer along their journey.

I love the JW Marriott story because it challenges me to think about DeveloperTown and what I want from my time here. We've had success helping startup founders. (We've had heartache too... but I'm looking past that because I want this to be a feel good email. Stay with me.) As a company, we're now fairly deep in exploring not just the startup entrepreneur's journey, but also the established-company entrepreneur's (aka intrepreneur's) journey.

Currently, we are meeting those customers where we have had success - designing, building, and launching great web and mobile products. And we're doing okay. Our A&W stand is successful. We have a great customer niche. Our job in the next two to five years is to grow that niche. We need need to "open more A&W stands" for our entrepreneurs. We need to serve a product as good as it is now, or better. I want all the airports.  :)

But I don't just want the airports. What else does our customer need? How else can we help them on their journey? Here are some easy answers:

  • Capital

  • Office Space

  • Education

  • Advice and Coaching

  • Introductions to Partners

  • and Help Hiring

Why were those easy for me to rattle off? Because at some point we've helped some subset of our clients with all of those. They are additional pain points on our customer's journey. Imagine a future 15 to 20 years from now (it was 30 years for JWM) where we are purposeful in trying to solve some of those problems for our clients in addition to helping them design, build, and launch great web and mobile products.

I love that idea. It inspires me to see where the DT journey leads. I want to do what we're doing now better than we do it today, but someday I also want to see what else we can do. The JWM story gives me that perspective.

So... Who is your favorite entrepreneur? Why?

If you're willing to share it with this thread, that would be awesome. But it is not required. I decided to share this story because it's meaningful to me. I have a favorite entrepreneur right now who's inspiring me. You may not. That's cool. But if you do have someone that comes to mind, I'd love to learn about them. Who are they, and what makes you excited about their story?


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,