The panelists talk to DockYard's Brian Cardarella about the lessons he has learned building his own software consultancy.

 

Chuck said he couldn’t show up, like, 20 minutes ago. He doesn’t have a choice anymore.

Hi everyone and welcome to episode number 125 of the Freelancers’ Show. This week we have Curtis McHale.

Good day!

And our guest this week is Brian Cardarella.

Hello!

Brian, since this is your first time on the show, please tell us a bit about yourself.

I'm the CEO of DockYard, a consultancy in Boston. We’ve been around for over two and a half years now. I guess we’ll get into this more throughout the show, but it started with me just freelancing and then eventually bringing out more and more people, and we actually became – I guess, now you can call us an agency. We do full stacks, so we have designers, we have project management, we have engineers and things are going pretty good for us right now.

Well, if nothing else, you have a spectacular view out of your window there that we see on the Hangout.

Oh, it’s actually a graveyard [chuckles] – it’s the old graveyard in downtown Boston. The obelisk that you see in the middle, that’s actually Benjamin Franklin’s parents. And [inaudible] is buried in there as well.

Hence all the people walking around.

With Benjamin Franklin’s parents?

Yeah. The big triangle, you can’t see it on – the resolution’s probably too small, but it says ‘Franklin’ on it and Franklin’s parents are buried there.

Alright, that’s pretty great.

Random fact.

I know!

Where products go to die, right?

Yeah, exactly.

What’s your background and how did you get to the freelancers’ stage? And then we can talk a little bit more about how you got to the building up an agency stage.

I went to school for Computer Science; I went to Providence College in Providence, Rhode Island. I did not graduate, but I finished my major in Computer Science. Long story short, Providence College is a very religious school, and I had finished all my required classes for a major and I was stuck with a bunch of free electives, then I had to fill it up with religious classes and I was not a big fan of that. I had the opportunity to bounce out and do something else; I did that for a while, and I actually spun away from software. I actually landed, eventually, working for my father as a recruiter for electrical engineers, of all things. Let me back u for a second. During college, I was interning at American Power Conversion doing an assembler and low-level C programming for a lot of their smart cards that would plug into their batteries. This was around the time that the bubble burst – the company was still making money, but their stock price was cut in a quarter almost overnight. They started locking things up and one of the things that they locked up more or less was me [inaudible] as the intern. I went from having no chair to having an early version of a standing desk, only it was very uncomfortable. My monitor was like two feet above my head; they couldn’t buy [inaudible]. I was thinking to myself, “Is this really the industry I want to get into? Is this the type of thing I want to be doing?” and that didn’t feel like it. So I was kind of spinning and I didn’t really know what I want to do. I was working for my father, and then after about two years of working there, his company at the time was around 20 years old – close to 30 – they had a 20-year-old database of just information on companies, on contacts and such, but it was behind some really bad Visual Basic frontend. The database file was still there, the application they're using to access the data was not fantastic, so he tasked me with finding a way to extract the data and provide a new UI to it. I had probably been away from web development in general and software development for around two years, and it was around that time that the extreme programming, Agile development was starting to take off, and Ruby on Rails was just introduced. I started really diving into Rails and really liking a lot of things that were in there. In fact, when I had left software development, I was very – I'd say almost retentive about my code. I didn’t know about testing your own development at the time, but I was doing something similar to it in that I was kind of running out the assertions I would expect beforehand. I wouldn’t have an executable document or a nearlyexecutable [inaudible] but I would have my expectations beforehand and I would write the code to satisfy those on paper or in my head. When I came back to software, I'm like, “Wow, this is amazing. This is exactly what I want to be doing; this is so much better than when I left it” so I really got heavy into Ruby on Rails. From there, I got a Junior Developer position at a big Japanese company here in Boston, and then from there I moved over to a startup, Zendesk, when they were in Boston for less than six months. Maybe four months they were here, and then they very quickly got their series A, I think, and they moved to California. I had to interest in going to San Francisco. I

dabbled with it a little bit in my head because they're really a cool company and I liked them, but ultimately, I didn’t want to go. I actually ended up down in Washington, DC. I'm very interested in politics – political tech – and so I went to work at the Democratic National Committee for a year, doing Rails work. After that experience, I realized I didn’t want to work for anyone else ever again. The DNC is an interesting place to work; I would suggest everyone that has any interest in politics go and work for either side, but I don’t think it’s a place to really spend too much time. I came out of the DNC – I actually worked for Railsdog as a contractor. Railsdog is a consultancy out of Maryland and I worked there for about two months as I was transitioning back to Boston, and I just started leveraging my network, looking for connections. I had a good network in Boston already; I've been living there before I went down in DC, came back up and started working my network for finding small contracts. I eventually got to the point where the size of the contract necessitated additional resources like design. I think it’s usually when you're freelancing, as an engineer, it’s probably the first outside-your-immediate-skill-set that you're probably going to look to sell, or at least partner up with someone. I knew a designer who was freelancing as well and I didn’t really have any client-side application experience. I could hack together some JavaScript but Backbone was becoming more popular and I just didn’t have the time to go through and really learn it, so I partnered up with a Rails developer but he had a lot of experience in Backbone. From there, we decided to form DockYard out of that. That was probably end of 2011 and beginning of 2012 when that happened.

So what was your biggest challenge when you moved from just you and your partner to more people?

There were two partners, rather, three. I think that the most difficult thing about your first hire is now you have to ensure their salary; you have to ensure their benefits. Up until that point, amongst the partners, there's always that understanding that if the money isn’t coming in, then there's no pot to split up amongst ourselves. You may forgo benefits and have all the partners figure that out individually, which we were doing it first – and taxes as well. Essentially just paying all the partners as freelancers working amongst ourselves and so everyone kind of handled their own taxes, but when we go and hire someone as a first employee, we cannot – for lack of an alternate swear word – we had to get our stuff together. So we definitely had some screw ups around there. When I talk about the history of DockYard, I like to talk about our failures as much as – if not more than – our successes. The reason for that is when I was starting DockYard, I went out and looked for guidance. I went out and looked for other people sharing information on how to start a consultancy, and there was nothing out there. What I came to realize is that a lot of consultancies like putting out this image of success, no matter what. They don’t like sharing their failures because, to potential clients, any failure may mean a mislead; a client’s not going to want – the perception at least, is that a client may not want to work with somebody that had a bad project or someone that had a particular screw up at some point.

Which is, of course, a total lie, right?

Success you can’t [inaudible]. Yeah, every consultancy has its problems; every consultancy has its issues; every consultancy has had failures. We've lost projects; we've had clients get really upset with us. We have done our best to adjust as that goes on and we've learned from that, but I guarantee you, at some point in the future, we will have another client that’s going to fire us because we have a miscommunication. We screw up or they screw up, but something goes wrong.

Yeah, I actually just had a client ask me that and I was telling them the most important thing is not that it happened, but what are the processes you have in place now to make sure it doesn’t happen again, right? Because they said, “Oh, this other person said they had never had a bad client.” I

said, “They're just lying to you. That’s all they're doing.”

All the big consultancies I've seen really try to put forth that image of excellence. It’s actually really frustrating, because it’s BS; it’s total BS. To go back, the reason why I like stories of failure more than stories of success is because it’s really difficult to recreate success. Success usually is one part persistence and a lot of luck. You can create more opportunities for luck for yourself by just being very, very persistent and keeping at something and eventually you'll get lucky, but failures are very recreate-able. If you do something screwed up, it’s most likely the exact same problem that someone else had. I just didn’t know about this particular situation or the proper way to handle that outcome would be, and we would learn from that after the fact. So in my blog posts, I like to share our failures quite a bit, because I feel like those are the things that, ultimately, people are interested in because they're going to be the ones that – those are things you learn from. You're not going to learn from “Oh, we got a big contract because it just landed on our lap” – that’s not really relevant to anybody. But to go back to the original question – I'm sorry I went off in this tangent for a second – the first hire was difficult. The second hire was less difficult, third hire’s less difficult – it becomes less difficult over time because we have more padding at that point; we have more people working and kind of absorb that cost. But anytime you make a first hire, I'd be very surprised that any group of people or any consultancy is coming to our agency will immediately put that person on contract work. What I've come to realize is that if you have a potential contract that comes in, they ask you if you have the staff that can meet it; if you don’t, you should not go out and just hire anybody to [inaudible]. There are some people who are fine with subcontracting. I'm not a big fan of subcontracting; I like to take ownership of what we’re doing. What we try to do is we try to find the smartest people we can and hire them when we can and we absorb that financial cost and will eventually even out for us when [crosstalk] them on something.

I'd like to ask you a little bit about subcontracting, because a decent portion of my work actually come from subcontracting – from agencies – for a specific portion of their project that I am quite good at and they don’t have expertise in. Would you subcontract in that scenario or not? And why?

I think the only situation we would be looking to subcontract right now is if we were doing something really heavy on Data Visualization Analytics. That is an area that I'd say that we are mediocre in; we don’t have specialty in doing something with our – or something with JavaScript Data Visualization. Our designers are good at coming up with visualizations, but we don’t have a lot of implementation experience on that. That being said, the reason why I'm less interested in subcontracting is because we put a lot of emphasis on trying to nail our estimates and really stick to our estimates as strong and hard as we can. What I found is that with subcontractors, we lose ownership of the estimate at that point, so we can’t reliably gave an estimate back to our client if we don’t have complete ownership of the process. That could come down to a failing of our process in just how we have organized things that have put us in the position to be stuck in that way. That is where we've landed in the reason why I've shied away from subcontractors.

I'm sort of curious –. Just to step back a little in your story – you were freelancing for a bit and you joined up with other people, and now you're building an agency. I'm curious to know why. What drove you? Was it the prospect of earning more money? Was it the prospect of working on bigger projects, being taken more seriously?

Yup, more money definitely was not it, because I have earned far less money over the past three years than I ever did freelancing. Eventually, if we become successful enough, I’ll probably earn more money, but I've taken significant financial losses over the past couple of years in order to keep the company going. Not to say that we've been completely dead in the water; we’ve been profitable every single year. I think we’ve come close to 17% profit, but that is averaged around 17% profit each year. That has only been because I have probably paid myself 25% of each year. I've taken myself off of billable work just because I found that – I think some people are very, very good at balancing the business side of things and then being able to do the mental switch over to software development. I don’t have that ability; I need to stay focused on one or the other, or I'm just ineffective at both. Right now, the most important thing for me to be doing is focusing on the business side of things. I will step in and help out some of our developers from time to time, mentor them, pair up with them – that sort of thing – but as far as scheduling meet-out on a project, it has not proven to be very successful. One of the early things we struggled with was – people around Boston knew my name, and when they came to us, they want to bring [inaudible] on Cardarella on the project. It took us about a year, a year and a half, to move beyond that, for people who are interested in DockYard being on the project rather than Brian Cardarella being on the project. I don’t scale very well; I can only be on one project at a time, and I really don’t want to be on any projects just because there are more important things at DockYard for me to be focusing on.

So what was the reason, then – if it wasn’t money – to then ramp up and have more hires and more people?

I think, job security. I mean, it’s a weird thing to say ‘job security’ in the consulting world because maybe – depending on how you look at it – we may be bringing ourselves in a less secure position, but I see a lot of freelancers that are – it’s not a regular job. It’s like they build up a cash flow for a bit and they go on vacation for a while, and for some people, that’s fine – that’s the lifestyle they want to live. That’s not my style; I need to be consistently doing something and I also like the idea of building something as well – building a company around that – that’s a particular interest of mine. My family has a lot of entrepreneurs, is the right word. My father owned his own company; my grandfather owned his own company, so I think it’s just kind of ingrained within me to do that.

One of the challenges, I guess, that freelancers have is of course bringing enough work to pay the bills. In my experience, I had at the peak of times [inaudible] and I have an employee who works for me as well, but back in 2000 just before the .com bust, I had about six people working for me. My biggest challenge was just bringing in enough volume of work all the time to pay all those people.

What do you do to ensure that you have enough flow coming in?

I think, as you grow, keeping a handle on that is difficult. Having the insight into our [inaudible], exactly who’s being billed out any given week, is very important. We built out a tool – we use 10,000ft; our project manager uses 10,000ft to actually schedule people, then we extract that data out into another application that actually pulls in our invoicing data and it pulls in money that’s going into our bank. I mean, this isn’t like a product that we put out just for our own, internal purposes but it actually shows us how we’re performing week to week on billable amounts, and it does a little bit of projection hanging out as well, knowing where our contracts currently are. But as far as [inaudible] I think what you're getting at is with generation side of things. We started out as a Rails consultancy; that’s where my knowledge really was, and I knew people on the Rails world so I would hire good ones. What my fear was at the time and what I'm definitely seeing starting to happen now, is that from a developer’s point of view, Rails is actually kind of boring to me. I think it’s super effective at what it does, but it’s not an innovating technology anymore. When that happens to any technology is when it becomes the most popular. From a contracting point of view, we’re dealing with more competition amongst potential other consultants or other freelancers to go after given contracts. So it makes little sense for us to stay as a Rails consultancy, because we’re going to be dealing with more competition, and we’re going to have less leverage when it actually comes to negotiating contracts and rate. What thankfully has happened in the past year and a half is that Blindside frameworks have really taken off and whereas earlier, I said I didn’t really get much into Backbone. I've become very heavily-involved with Ember; I found it to be a very interesting technology early on and decided that DockYard was going to be investing a lot of time and effort into Ember and through that, hopefully, be able to establish itself as some sort of presence within the Ember community or Ember world – however you want to call it. What we found is that when we are specializing in a very niched technology that doesn’t have much competition, when those that are working to work in that technology come to us, we are in a very good negotiating position. There are probably less contracts out there for Ember right now than there are for Angular, but there's also way less competition for those contracts.

I agree 100%. I've been thinking of getting into Ember. I've been starting to dip my toes into that water and I've seen exactly the same sort of thing as you, that there are probably a hundred times as many people talking about Angular, but if people want Ember and really, really, really want it and there's basically no one out there or very few people out there are doing it.

Well the other side of it too is, I also decided at some point after DockYard started is that we are shying away from startups as clients. We take them on from time to time, but only after we’ve decided that they –. I have three qualifications for whether or not we take on a client. Number one is, can they afford us? This is something that a lot of contractors, a lot of freelancers I see shy away from the money collection, and I think it’s stupid for them to do so. There's no point whatsoever for you to enter into a contract or any type of negotiation if you don’t have any concern about the client being able to pay you or pay your rate. Can they pay us? Is their budget in line with what our cost will be? That is the first concern. Number two, is it an interesting project? I think that our employees stay here for two reasons: we tend to pay them pretty well given the market rate, we have pretty good benefits; we’re also working on interesting projects with interesting technology. If either of those two things go out the window, I think that we’d start to lose employees. We’re not going to go public; we don’t have any long-term vision for IPO-ing or anything like that or becoming acquired, so there's no real reason people are enjoying working at DockYard. There's no other reason to keep them here in consultancy as I'm sure you guys know are poaching ground for startups. A lot of our developers are contacted by recruiters quite a bit because consultancies are generally pretty good bringing in smart, junior people, training them up; they become polyglot in some way or at least now a lot of full stack and we’ve been fortunate that we have not lost many people. In fact, we've only had one person quit, and that was only because he was living in Washington, DC and he didn’t really like working remote.

And how many people do you have working for you now?

As of next Monday, we’ll have 19, including myself.

Wow, that’s pretty great.

I'd like to get up to 22 by the end of the year. That'll probably be more on the design side than on the engineering side, but that’s our gross goal by the end of the year.

In terms of you mentioning Rails and Ember, again, I totally agree with what you said in terms of, if you specialize in a niche technology or a technology that not many other people know, then you become a premium brand for working with that and people are going to come to you. But I found that a number of clients who could not care in the slightest what technology I use. Some of them say, “Oh, I want to come to you because you're using Ruby or whatever” and then someone comes to me and says, “I just want a solution.”

To that point, I find that the clients that are not tech-savvy that don’t – they just don’t want a great application, right? They want very good design. So what we decided early on when I was noticing that we were having less success during the contract negotiation for Rails because Boston has so many consultancies, we had several conversations where clients would play us against each other. They'd say, “Oh, we got a quote at this rate from consultancy A and a quote at this rate from consultancy B; can you guys do better?” I just was not interested in having those types of conversations because it’s a losing battle every single time. The only leverage we had is reducing our rate and putting ourselves out of business or just scraping by, so we had to come up with a differentiator, whether that was on the technology side with Ember. But you said a lot of clients may not even care what technology there is, so the other differentiator we have beyond cost is the actual design, and that’s something that is very tangible to a lot of clients. They come and they see a design, “Okay, this is something that I can grab a hold of; this is something that I want.” We were fortunate enough to have our early contract where we were introduced to a local designer, Steve Trevathan, and we worked with him on a bunch of other projects. He had his own consultancy, Dobot, and then maybe about a year and a half into it – actually last summer, probably around this time last year, we needed a creative director; we needed someone to lead our design. Him and his partner were actually looking for a lead engineer. They're working out of our office; I just took him out to lunch, I go, “This is stupid, I mean, we’re looking for each other. Let’s just partner up” and he agreed. And so we just worked out that way; we were fortunate in that. We brought him in and he has been building up the design side of DockYard, and that’s been huge for us. It’s an excellent marketing tool; its design is –. I've said many times that, and this is probably isn’t something as a consultant I should say, and not to say that we do this, but you can have the best tech under the hood and it could look like junk, and people won’t want to use it. You can have the opposite though – you can look amazing and have PHP spaghetti code under the hood, but the users won’t care. The users don’t care what the tech is under the hood; I mean, the tech, at that point, you can make [inaudible] okay, response time, the ability to quickly build other features and go down that road. But generally, people want something that looks nice, that feels nice, has a good user experience, and the design really dictates that. Not only that –.

Absolutely. I think I learned that very early in my consulting career, so probably ’96 or ’97, and I went somewhere to talk to people about doing –. Basically, I had a very early social network type of site, and so I wanted to use this framework that was known as OpenACS, commonly known as [inaudible], actually from [inaudible] from where you are. It was so incredibly powerful and came with just about everything you wanted out of the box, and was black text in a light background. I

showed it to people, and they were like, “You got to be kidding me! Why would we want to use this?” I said, “Imagine what will happen if we were to design it?” and I realized – I hit a brick wall there. So they went with the PHP spaghetti code frameworks that did maybe a tenth of it, but because they saw fonts and colors and beautiful things, that totally sold them on it. It was a very important moment, I think, for me, in my career.

Design sells. Design is an excellent lead generator for us. It has helped us increase the size of our contracts, because a good designer will be –. I think the difference between a good designer and a bad designer is someone who can actually extract the information out of the client, like the requirements of the client, and that’s become a big part of our process. We call it ‘Discovery’, but we’re probably going to change the name a bit because we’re doing a lot more than just discovering right now. But it’s our proposals and all the requirements-gathering – our design team really runs that side of it. That’s when we really started taking off as a real business, I would say. The design side, for any given contract – these are fuzzy numbers, but I would say 25% of the contract revenue is represented by design; 75% is engineering. The design becomes the lead generator for the engineering side. We get to bring in these contracts that design kinda gets the client’s focus into, and then we convert them over to engineering contracts. That process has been very good for us. We’ve been approached to do several design-only contracts, and our designers have been wanting to do those, but I've said no only because at that point, we are leaving the engineering team kind of hanging there; we don’t have anything to actually put them on. We have to make sure that whatever contracts you're bringing in are converting over to the engineering side [crosstalk].

I know I've staged my portfolio so that some of the things that [crosstalk] less technicallyinteresting and the prettier ones where the client was willing to hire a good designer or something, being a one-man shop myself, I'm not the designer, but –.

Going back to a point early on was that, if you are a freelancer individual, you should find a good designer and that's not to be an exclusive partnership, but work with that person. You're going to find that you're going to have a lot of regeneration between the two of you.

Absolutely [crosstalk] and she works with WordPress, mainly, or only, and she understands enough of the technical aspect that when I say, “No, no, no that is astronomically – you don’t understand the technical aspects of it” and we’ll talk about it and she’s like, “Okay, we [inaudible] a better solution together.” And my clients love her too. I would get clients, I'd say, “Talk to Vanessa, she’s awesome” and they’ll get off the call, they’ll be like, “She is awesome. I love her so much.” That’s good. We work well together; we feed projects back and forth.

Wow, that’s great. I'm still curious – you mentioned this a little bit in terms of use design as a lead, and this helps you to distinguish yourselves from the other development shops and other agencies –.

I want to [inaudible] that point just really quickly. Especially in the Rails and Ruby world, every – are you guys Rails developers [crosstalk].

I do Rails.

I used to do Rails [crosstalk].

Curtis was a former Rails developer.

Okay. You guys know everybody does the exact same process – everyone does TDD, everyone uses the exact, same tools, everyone has the same code guidelines in Ruby – there's absolutely nothing that distinguishes DockYard from any other consultancy. There's absolutely nothing that distinguishes us from another freelancer. There's no leverage there whatsoever. The only distinguishing factor we can have that is our [inaudible] is that we can produce a better design to build an application around. That was kind of the revelation that I had and why we pushed so hard on design.

So is that how you avoid some of the problems of commoditization and people outsourcing to cheaper countries as well, where you basically say, “Look, you don’t just want cheap software; you want this really good design in the holistic approach that we can provide”?

Yeah, there's some of that. I'd say that we were hitting that probably about six months to go, eight months to go, when we were more of a Rails shop. Now we’ve gone full-blown Ember; all of our applications are Ember, and we’re kind of doing really well in that space. Because we’ve been specializing in that, the contracts are coming to us are Ember-specific. We don’t have anyone coming to us right now that we’re working with, that have asked us for a Rails application and then tried to get us to justify to build the Rails application versus some place overseas and compete against that rate. [Crosstalk]

You said you picked Ember, but how did you get your guys trained in it and everything else? Because that’s the cost you have to pay. [Crosstalk]

It’s really interesting, because I see a lot of shops and some people that will immediately – boom! We’re moving over to a new technology right now and we’re going to just start telling everyone we’re expert’s in it. For example, when Swift came out – the new iOS language, the objective-C, micro-compiled language – I think within a week, I was seeing Swift training courses being advertised. I mean, that’s insane. There's nobody in the world that even knew that this language existed except for some team in Apple, and then within a week, people are claiming to be expert enough to actually justify charging $2,000 to people to be trained up in Swift. For me, I don’t operate that way. I like to be as – going back to the previous point, we’re only as good as our estimations. If we are not able to really understand how a language or framework works, we can’t estimate reliably around it, and then that just puts us in a bad position. We can say, “Oh, this contract’s going to cost $100,000” and then we’re $50k into it and realize we don’t know what the hell we’re doing, then it ends up costing $200,000 or $300,000. That’s not [inaudible] because that’s ridiculous. The way we transitioned over to Ember, where I discovered it, was first off of fanboy-ism. Yehuda Katz is the lead developer on the project and he was very involved. I don’t know what his core team’s status is for Rails and jQuery but, at least, at the time he was Rails core team and he was previously jQuery core team. He may still be; [inaudible] I'm not certain of his status. And these are two core components that I've been using in web development. I figured that if he’s introducing this new framework – that alone was enough to pique my interest in it and look at it. I had looked at – for those that don’t know, Ember is actually a fork of a framework called Sproutcore, which was an attempt to build a web version of the Cocoa framework that Apple has for OSX. Sproutcorewas, I would say, a spectacular failure. I don’t know if people really call it a failure, but it was almost ahead of its time; it was very, very complex, very, very advanced, but it was also very, very slow. They forced you to build out widgets in network – I won’t go too far into it. Anyway, they forged Sproutcoreto the Sproutcore2.0; they realized that it was divergent enough that they just broke the project off in Ember, and this was when I became interested. I had written a

library for Rails called Client Side Validations and I noticed that Ember didn’t have any validations in there. I had the test suite for all the validations already, so I was going to write a library. And then EmberCamp, which was the first, unofficial Ember conference [inaudible] by Tilde San Francisco – it wasn’t the first; it was like 150 people. I submitted a talk, like “Oh, I can talk about Client Side Validations” and they miraculously accepted my talk and I decided that “Okay, I'm going to implement this library in about 24 hrs.” My talk did not go well because of that. I was live coding; it kind of blew up in my face, but regardless, at least that kind of established me in that space. From there, we would do side projects. We would really kinda write blog posts; we would release some open source software around it. I would say maybe six months after we really played around with Ember before we started confidently using it in client projects. We got involved with the Boston Ember Meet-up and eventually took over that from the guys who were running it previously. I had experience running meetups; I ran the Boston Ruby Meet-up or many years, and so we kind of – for lack of a better term – cornered the market in Boston on Ember and got in before other people. That wasn’t the intent, but that’s what happened. We are very much wanting to share our experiences; I think that is, for developers that really worked pretty well and kind of created a name for ourselves, no one really knows about DockYard outside of Ember, but I think people inside of the Ember world have an idea of who we are because of that.

That’s great. I saw in one of your blog posts that you guys were doing weekly billing and you're billing out at least, when you wrote that blog post, $4,000/week. First of all, are you still doing weekly billing? I wouldn’t be surprised, based on what you’ve been saying, that you probably upped that by a bit, but I'm sure [crosstalk].

We’re at $7,000/week/head right now. We will probably try to bump that up to $7,500 after the New Year. The weekly billing has been pretty good for us. After about, I'd say, the first two months of DockYard, I came in one day and I said, “We’re no longer doing hourly billing.” I was getting so sick of being on everyone’s ass to actually get their hours in. It’s the same complaint that everyone always has about hourly billing; there are people that are very good about it and the ones that aren't just end up being more of a headache. It’s almost like they're completely wasting your time, if not recording what they're doing. At the same, that may not be with their personality, because they may not be very [inaudible] at being able to micromanage their time: “I spent thirty minutes on this, I spent an hour on that,” and you're asking them to –. I think for software developers, once you get in that flow, if you're taking yourself out of that flow, it actually ends up costing more time for implementation. So we moved over to weekly billing. The way we do it is we say that it’s about 32 hours/week; generally, that’s Monday through Thursday. This gives us the ability to have open source day – or we call it DockYard day – on Friday. That means you're writing blog posts, you're writing open source software, contributing something back in some way, or doing something for the company – it’s not a day off. But if there's a Monday holiday, like Martin Luther-King day or something like that, then our workday will be Tuesday through Friday. We only try to get those four days in as much as we can. If worst comes to worst and we can’t, we’ll just prorate it, so we’ll just take the weekly rate, divide it by the number of days, multiply that by a number of days that was actually worked [inaudible] billing for. Our clients have been pretty good about that; I actually found that the bigger clients that we go after are bigger fans of the weekly billing than they are of the hourly billing. I think that you can probably really rack up more time on hourly billing than weekly billing. Weekly billing can sometimes almost feel like fixed bid/week, but the sample size is so small that you don’t really [inaudible] into the problems you would if it was like a multi-month, fixed bid contract. And we’re very protective of our developers as well; we’re pretty hard of that 32-hour rule. Our developers do put in time after-hours sometimes, but I don’t like it; I try to avoid it as much as possible. The thing that I found personally about hourly billing is that you become very much aware that when you're not working, you're not making money and that, I found, to me, when I was freelancing by myself, became very problematic. I was putting in 60 hours/week just because I could bill every single hour, and it’s not a very healthy way to live.

I'm curious a little bit. Curtis, I know you do weekly billing and you have people pay you in advance. Brian, do you also do it that way where people pay you in advance or do you just bill them afterwards for however many people or how many weeks?

Typically we’ll do a 25% deposit. A [inaudible] that came to us, we will get a general assessment on what ‘Discovery’ will take. If it’s two or three weeks, we’ll say, “Okay, it’s going to cost you about $21,000 to do discovery.” We've had discovery sometimes go up to $100,000 for a minimum $1.5million we’re working on; that was easily a six-figure+ discovery. We’ll get a sense of that, then we require that to be paid upfront, and then from there, we will get an estimate on the visual design and engineering fit, because our visual design estimate will be very accurate from the discovery; our engineering estimate will be very ballpark-ish. From that amount, we require a 25% deposit upfront before we begin to work. Typically, we do net 15 on our weekly invoice.

[Crosstalk] Oh, you are sending an invoice every week. You send the invoice every week?

Yup, every single week. Every single Friday, we do [inaudible]. We try to keep it as granular as possible. We were doing monthly invoicing early on, and even though it ends up being the same amount, sometimes clients don’t like seeing a huge number on a single invoice, so we try to keep it as small as possible. The numbers end up being the same but I guess it’s a matter of perception.

[Crosstalk] you leave an invoice too, right? If you're doing a flat rate as soon as the project’s done, like the day it’s done, the longer you leave it, the longer it takes to get paid as well.

Yeah. Oh yeah, totally.

One other question and it goes way back to the beginning of what you were talking about in your personal life that you said you went to college and you took computer science courses then you didn’t graduate – has this affected your view of when you hire people, what you're looking for in terms of their educational background? Do you care if they graduated from college? Do you care if they even major in computer science?

I don’t. I actually think that for web development, if you have a PhD and you're doing web development, you're probably in the wrong the business –.

Reuven just finished his.

Oh. [Laughs]

Just finished it. [Crosstalk]

Do you have a PhD?

Literally, today, my adviser sent me an email saying that he had submitted the form. But it’s okay, it’s okay. [Crosstalk] [Laughs] But it’s been fun, guys.

You don’t have to find a new job now, so, but it’s almost like for a lot of what we’re doing though, it’s just architectural implementation, right? There's very little [inaudible] work; there's very little stuff that I would consider that would justify a PhD, unless you're doing some massive scalability concern things. But this is the project that we worked on at Greenfield, and so it’s sometimes going through the motions. I almost look at someone who has a very deep computer science background as being overqualified for that type of job. Not to say that I wouldn’t accept somebody like that, just that I also don’t want people that are getting easily bored. I want people that find this type of work engaging and challenging. But as far as who are ideal candidates for working here, if I'm talking about – there are three levels: junior, middle, senior. Junior engineers, we always look for people – they don’t have to have a specialty in what we’re doing. I want to find people that can learn fast. If you're hiring a junior engineer, the mentorship can be very draining on you and it can be very timeconsuming. It actually hurt a lot of your estimations in a lot of contracts, and so if you're wasting time on a junior hire that is just not getting it, is not moving along fast enough, you should move on and find somebody else. The way that I have vetted that, I typically will look at their educational background to see if they come from a good school – I think that is a good indicator that they are quick at learning things, that they're quick learners – but that’s not a good indicator that they're going to become a very successful senior engineer. For example, one of our most senior engineers on the Ember.js core team, he didn’t even go to college, and he’s one of our best people. I think if you're looking at mid-level to senior, you need to assess beyond that. You know that this is probably not the – there's been a lot of backlash against the GitHub resume type of stuff lately, but I will look towards open source work just because it is an inexpensive qualifier for us. Hiring and vetting candidates can be very time-consuming, and sometimes you just don’t have the time to really dig deep into them. We’ll look at whether or not they work for us culturally – if we’re a good cultural fit, they have a good personality. Bringing somebody on to the team that’s toxic for the environment, especially for a small company – I definitely don’t want that. We have goals as a company too: we’re attempting to become as diverse as possible. I would like to be gender-neutral sometime in the future. We have about two-thirds male right now, one-third female, and we’re trying to get to 50-50 between design and engineering. I think we’ll get there in another year or so, but it is a challenge because it’s no secret that the pool you can draw from for female candidates is much, much smaller than what you can draw from for male engineering candidates right now. If you're going to go down that road, you have to be really dedicated towards it and really believe in what you're doing, or else, you can get frustrated that there just isn’t enough opportunities or enough candidates out there. We are primarily in-house. I recently went on a trip to the West coast, San Francisco, San Diego, in Austin – Austin’s not West coast but that was my last stop – and we’re looking for a new senior engineer, in Ember, specifically. A lot of people wanted to work with DockYard; not a lot of people wanted to move to Boston. I've stayed away from remote engineers, not because I'm trying to be controlling and I want everyone here, but only because we just are terrible in managing remote engineers. If we were a product company and we had one long-term project to work in, having remote engineers would be easier to manage. But when we’re working on a project that lasts three or four months, the ramp up service is so small that any time wasted is a real killer. If we have someone that’s a 12-hour difference, regardless of how great of an engineer they are, sometimes the time difference is enough to really [inaudible] out that advantage of having a senior engineer. If you're waiting on that person, if they're waiting on you, it can be really, really difficult. There are probably people who are much smarter than me that are much better at managing remote developers, but it’s not a skill that I have developed to date. It’s probably one that we’re going to have to focus on, but we just haven't really gone down that road yet.

Would you consider having another office, a satellite office?

We’ve been talking about that as well. I think that is something in our future. We tried it, kind of, and experimented down in Washington, DC. We had two people down there – one was a PM, the other one was an engineer – but they weren’t even working at the same place; they were working at their houses. I think that when we do it, it’s most likely going to be someone that we've had here in our Boston office that we transplant to another place and kind of start another DockYard elsewhere. A lot of other consultancies have done that and it seems like a good process.

Brian, anything that we didn’t cover that you think would be useful for people here to know?

Going back to the money side of things, the most important lesson I learned recently – and this is a little bit, kind of a dramatic side to it as well. We had a business developer, in-house, for about a

year and he was a really good guy, but he had a different vision for the company than I did and had a different way of selling the company than I did. My plan was, we’re going to specialize in Ember and we’re going to get some really big contract because of it. So we specialized in Ember, and we had a potential for a really big contract and that business developer was not able to secure the payday that I had in mind, or at least the rate that I knew that we were worth, and we kind of came to blows because of it. I actually was willing to fold up my company. I told my wife that evening, “Look, I'm not willing to continue scraping by. I'm going to fold up DockYard. We’re done. I'm going to have to go and get a new job.” I stayed up really, really late that night; I was pretty depressed, it really sucked, and then I just came up with a plan. I came in the next morning, in 10 minutes I fired the business developer, I contacted the client and I sold him on the rate that I knew that we should be getting. The lesson I learned out of that was, in order to sell your business, you have to believe in what you're doing. You have to believe that you're worth the amount that you're asking for. You can’t go into it saying, “Can we get this amount?” or you say, “This is the amount we’re getting,” or “This is the rate” and really hold yourself to it. If you find yourself negotiating your rate, you’ve already lost. Never, ever negotiate rate. There are other things you can negotiate – you can negotiate IP handoff; you can negotiate time; you can negotiate on deliverables a week, but never, ever, ever negotiate your rate. There will be times though when the market turns and you're going to have to come down, but you should go through losing a few clients before you decide to do that. I find that a lot of software developers are excellent at engineering and sometimes terrible at sales, and I was terrible at sales. I think I'm okay at it now, but I'd say, it’s a difficult thing to learn. When it comes to negotiation and really leveraging and getting the rate they want, there's an excellent work out there. I know this is getting into where you guys want to tie up and have suggestions, or picks, I just want to bring a special note to this. You guys may have talked about this book previously; I

haven't heard all your podcasts, but there's a book out there called The Win Without Pitching Manifesto. Have you guys heard of that book before? No? Okay.

No, no [crosstalk].

It’s winwithoutpitching.com. You can read it online for free; you can buy a hardcover for 25 bucks, about 125 pages. It’s an excellent book. It was suggested to me by Pete Ford who used to run Unspace up in Canada, and he actually reached out to me on some of the blog posts I've been writing and we chatted about it. That was a book that he read that helped him build his company. In it is a bunch of stories or at least direction on how to create leverage for yourself, because that’s what it all comes down to in contract negotiation, is establishing leverage and being able to use that leverage to get the rate that you want or at least get a favorable outcome in negotiation that you want. I don’t have all the book memorized, but I was happy when I read it, seeing that we were doing some of the stuff discussed in the book and the other things, we started bringing those in our process. It’s a pretty simple read; I read it on an airplane, a three-hour flight. I usually ask people to check this book out. Some people may read this and go, “Oh this is sales or business BS, but for us, it’s really resonated and it’s really helped us with our sales pitch.”

That’s awesome! [Crosstalk]

That’s great! I don’t really read many books unless they're really small.

I'm just looking at the table of contents and I'm saying, “Ha! That seems really good.”

[Crosstalk] obvious, too. There are some stuff in there where I go, “Oh, I knew that, I knew that; that seems obvious” but it’s the combination of all in one spot that really gives it its strength/

Very good. Well tell you what? Why don’t we move into the picks? Brian, you’ve already given us one good one even without intending to, perhaps. Do you have any other good suggestion you can pick for us?

Future pick, future pick! I'm actually writing the Ember.js way for Addison-Wesley. It will be available after I finish it, but there's no – I don’t know [crosstalk].

[Crosstalk] notified about that, or –?

Well that would be really great.

I think you can do it on Amazon. You can preorder, but I don’t know if Amazon has a way for you to watch a book. Probably.

No, but I can tell you from experience – granted that things have changed since I wrote my book back in 2000 – all of [inaudible] in terms of –. Because they get the dates from the publisher, and the publisher is of course giving a gross estimate based on what they're hoping you will actually do, and so you can preorder books and it might be completely off the mark.

Yeah, the publication date on Amazon is sometime in September and that’s not going to happen, I can tell you right now. We wrote about 50% of the book, and then there's been so much movement in the Ember world that we decided to pull back and wait for some of the things to solidify before going –. Whenever you write a technical article or blog post, right when you write blog posts, within a week, it’s out of date; when you write a book, you're even taking a bigger risk, like before you go to print it’s out of date. But things are moving so much faster in the Ember world that data would have been completely irrelevant, so if we’re going to put out a book, I want to at least have some relevancy for whatever period of time it takes to get to the next version.

That’s great. Curtis, do you have any picks for us this week?

Sure. For my blog post, I often always find [crosstalk] like them and I use Flickr – the open source or the creative commons photos. It’s on a Chrome plugin called Download Flicker Photos, so you can simply visit the photo, click on the Clicker button in the top of Chrome and download the photo instantly, full-size. It is excellent, makes a lot of things much faster for me.

Excellent. I've got two picks for this week as well. The first is a book that I've been reading through called, the great title, How Not to Be Wrong: The Power of Mathematical Thinking. It’s by this mathematician named Jordan Ellenberg. He’s written a bunch of articles for Slate over the years. I think it’s a collection of them plus a bunch of additional chapters, but he basically tries to explain how mathematics is not equations and craziness and things that are unrelated to life, but it’s a way of thinking about the world and a way of reasoning logically so that, as he says in the title, you cannot be wrong, or at least you can understand where you are and are not wrong, so I've been having a lot of fun. It’s written really, really well; a lot of [inaudible] I'm probably halfway through at this point. The other thing is, because today I actually got signed off on my dissertation – woohoo! Finally, it’s official: I'm a PhD. If anyone out there has ever been curious to know what a dissertation looks like and is having trouble falling asleep, you're welcome to email me and I’ll be happy to send you a copy of the dissertation. I actually think there are some interesting stuff in there, whether it was 11 years worth of interesting stuff, it remains to be seen. But I'd be happy to share that with listeners of the podcast and anyone else you know who cares. Anyway, I guess that [inaudible] for this week. Don’t forget that next week, we’re going to be talking to Daniel Pink about his book, To Sell is Human, which is sitting here on my pile of books next to my chair. Read it, enjoy it, join us for the book club.