This year’s story is one of how we nearly went out of business twice yet still managed to pull off our most successful year yet.
People
In 2013, we ended the year with 11 employees. We made a key hire at the start of the year with Robert Jackson joining us. I had met Robert a few months prior at Burlington Ruby Conf. Robert had been contributing to a few of our Ember libraries, as well as making a name for himself by quickly moving up the contributors list in Ember.js itself. Less than four months after we hired Robert he was welcomed onto the Ember.js Core Team. I’m extremely proud of him accomplishing that.
We added depth to our design team in Q1 2014 with Maria Matveeva and Tim Walsh. Tim and Maria have been invaluable for us, their dedication and ability allows you to easily forget how young they are. I’m looking forward to seeing how they continue to grow in 2015.
Early in 2014, we hired our first Project Manager, Jon Lacks. Jon and I went to college together, and historically I have not had a good run of working with friends. That has been my fault, I think I was more interested in working with people I was friends with than establishing what their responsibilities would be. Jon and I agreed that any and all potential issues that may arise that could conflict with our prior relationship should be aired out immediately. Jon joined DockYard in February and spent the first month or so observing our team more than taking complete ownership of our process. I gradually handed off some of what I was managing to Jon (running standups, getting involved with some client meetings, helping with estimations). All this to say that adding a dedicated PM was one of the highest impact decisions I made in 2014. I suspect that many companies don’t need one until they’re around 10 people in size but once you do hire one you’ll be thankful.
Romina Vargas and Lin Reid were two engineers that went through our intern program and we upgraded them to full-time as soon as we could. Both Lin & Romina have been important members of some of our larger clients projects in 2014.
Marin Abernethy, a former engineering intern, came back for her third (and final) internship with us after her graduation from college. In the Fall we hired her as a full-time engineer.
Paul Webb interviewed with us in early 2014 but we had some projects fall through and things got very tight for us (more on this later) so we had to pass. But as soon as we had the bandwidth we brought Paul onboard to our UX Development team.
Heading into the Summer, we started to get spread a little thin on the engineering team. I had come off of client work completely to focus on the business so we needed another Senior level engineer. I reached out to Estelle DeBlois, who had come to our Wicked Good Ember conference in June. She’s been lead developer for one of our larger clients over the past few months.
Our final hire starts full-time with us in January. Ashley Treni was actually tending bar at Highball Lounge right next door to our office (they can see us, we can see them). She asked what we did and it turns out that she is an amazing designer who was completing her Masters in Information Design and Visualization at Northeastern. She did a summer internship with us and accepted our offer for full-time employment just recently.
Hiring is hard
Hiring continues to be hard. We have had success by focusing on technology niches, but we may have tapped that out. Going into 2015, we will have to consider how do we reach out and attract top talent, and how do we improve the existing talent we have. Promoting from within is something I’ve talked a big game about but have done little with. This will change in 2015.
I began 2014 with the same trend I had in the previous two years: I would hire good people even if we didn’t have projects to put them on. Coming out of Q1 2014, I had to stop this immediately. While we had built up a great team, the weight of that payroll and our lack of cashflow at the time was at a breaking point where I could no longer cover the difference by taking myself off salary. Since then I have been very conservative with hiring. Unfortunately we actually missed out on some great people because of this, and I regret that as I was perhaps too conservative in our hiring at the time. Heading into 2015, this will probably continue to be an aspect of the company I will continue to improve.
Firing still sucks
I had to fire two employees in 2014. Firing always sucks and I don’t think I’ll ever get used to it. There is a guilt that is attached that at some point is out-weighed by whatever you’re not getting from said employee. So how does one mitigate the guilt? Netflix has a great policy when it comes to firing employees, giving a very generous severance package. So managers don’t concern themselves with the guilt what will happen to this employee without their job. I think this is a great idea, but not always practical for all companies. If we had Netflix money then I would definitely align our severance package with theirs.
Culture
We’ve done a lot of work to define what the culture of DockYard actually is. Until Q4 2014 our culture was never written in stone. So we took some time to put it into words:
- strong problem solvers, with attention to detail
- coachable learners and willing mentors
- professional, kind and respectful
- collaborative team players
- disciplined
- reputation
- diverse
- fun
I’m sure you’re looking at this list and thinking “yeah this is pretty much what every company will say”. That could be true, but these are going to be our hiring and retention criteria. We will be building a team around these principles and expect everyone at DockYard to live up to them.
Heading into next year
We have a goal of expanding our team to over 25 by the end of 2015. I would actually prefer to be closer to 30. Our hiring will be focused on Senior Level talent for engineering, design, and UX. We’re always interested in hearing from great people, get in touch if you’re interested.
Estimations
Our problems with maintaining our estimations were not significantly improving in early 2014. We had to eat a lot of money on contracts that was due either to bad estimations or our inability to properly manage our clients. If we ever expected to build a real company, this had to be fixed. This is where Jon came in as our first Project Managing hire. It took a few months but we’ve gone from being consistently late to being consistently early. Our estimations are currently one of the more reliable aspects of our business. This has not just helped relationships with existing clients but being able to reliably sell our services to new clients is incredibly powerful.
Heading into the next year
I suspect we will continue to hone our ability to estimate. We will also be looking to hire an additional Project Manager as we decided we don’t ever want to spread a PM over more than three projects.
Financials
In 2013 we ended the year with $1.7m in revenue with about 20% profit margin. This year we improved that to $3.1 in revenue with 33% profit margin. This is a significant jump, in many ways I’m incredibly proud of what we were able to accomplish this year. However, I also know that we (as a company) underperformed. If we had been as productive in the first half of the year as we were in the second half we should have been closer to a $4m+ company with >50% profit margin.
What went wrong
We were getting contracts coming in through the year, but nothing with the challenge or scope that I was hoping for. Small $50k contracts here and there. I like working on small projects but from a business perspective we were burning too much time negotiating contracts, balancing people on and off between contracts. I was butting heads with our business developer. He and I had different ideas on how to run the company. The funny thing is that neither of us were wrong. He wanted to reduce price due to lack of the demand we had at the time. I didn’t want to do that. I was willing to pass on contracts that we could have gotten if we cut our rate 25%. This eventually put us in a position of bringing in 0% of billings for more than 50% of the company rather than 75% of billings. Which would you rather have?
I’m sure there are people reading this was a deeper background in running a business than saying it was stupid not to take the 75%. Here is my problem: at that amount we weren’t making any profit and our people were tied up on projects. I was tired of living hand to mouth, I had taken myself off of payroll consistently for the past few years. I was living off my wife’s salary.
At the end of Q1 I was looking down the barrel of DockYard and not liking what I was seeing. Then we got a whale of a contract come our way. This was a contract that could right the ship. Or so I thought.
I was not heading up the contract negotiations. The only criteria I gave was what I thought our rate should be for this contract. When it came to it our business developer was not confident that we could get that rate. I was distraught. I was not willing to lock DockYard into a long-term contract at cost. I told my wife at dinner I was going to start looking for a “real job” and that DockYard was finished.
I didn’t sleep. I stayed up and kept mulling over the contract, was this it? I came to several conclusions:
- The client could afford our rate.
- We were worth the rate.
- Our business developer did not believe in #2
- I should be handling contract negotiations for DockYard
I came into work that morning. Within a span of 15 minutes I fired our business developer and landed the client at the rate we felt we deserved.
I realize the above might seem indifferent to letting someone go. He and I actually got along very well on a personal level. But as I mentioned previously when it came to how to run DockYard we didn’t see eye to eye. I was stressing out over this constantly and in the event I was not able to land this client on my own at the very least I could say that I went out my way. Egotistical? Yes, of course. But it is something I needed to do. If we had slowly died over the rest of 2014 due to no real profit margin I would have quit.
This was the first of two near-deaths for DockYard this year. The second would come just two months later.
The large client came with a large legal team, one that I was unprepared for handling properly. We have an excellent lawyer we’re working with but I am accustomed to contract negotiation taking maybe a week. This took months to complete.
The problem with dealing with Enterprise companies is that they can outlast you. It isn’t their intent to do so, it is in their best interest that their vendors are able to work on what they need to the best of the vendor’s ability. It doesn’t help either party if the vendor can’t make payroll. However, because of how many Enterprise companies are structured, and who has to sign off on what, an unprepared small vendor can be put into a position of agreeing to some things that are not in its best interest so it can start getting paid ASAP.
I was perhaps too risky in this regard. I held out on the contract, I put it through multiple rounds of negotionation. There was some legit scary stuff in it that I was not willing to agree to. We had started work with the client before the contract was completed. At the time I didn’t consider this to be a big risk.
What happened was that there was little to no incentive to speed up the contract signing for our client. We were working, doing what they wanted, and they had no obligation to pay us. I realize some of you are reading this and thinking “Rookie Move!” but consider the context. Starting work with large clients prior to contracts being completed is actually a common practice in the Enterprise. I hear some of you screaming “no it isn’t!”. Yes, it is.
We ran out of money. We had a payroll that we were $25k short for. I had a very difficult conversation with the client and made the tough decision to stop work until the contract was signed and our existing invoices were immediately covered. I made a personal loan to DockYard to cover payroll. (as a side-note, banks never loan you money when you need it) Thankfully the client saw the situation for what it was and we were able to move forward. This was in June.
Putting the brakes on the project and getting the contract done and getting paid was the turning point for DockYard. We went from invoicing on average $30k/week to over $100k/week. With no contract longer than Net-30 by August we had all of our debts paid off and were in a position to hire again. By November we had gone from a 1% profit margin for the year in June to over 25%.
It is actually strange writing about this now, and I’m not entirely certain I should have written all of this. In some ways it was one of the most stressful times in my life, and looking back it feels surreal.
I hope there are some nuggets of knowledge in here to help others avoid a similar situation.
Heading into next year
We have ambitious financial goals. We aim for a $5m+ business in 2015. A $10m+ business in 2016, each year with >25% margin. If we can maintain our current momentum we should easily meet 2015’s goal.
Technology
Ember.js
We bet very heavily on Ember.js in 2013. That bet has paid off very well for us in 2014. The client mentioned above hired us for our expertise in Ember.js. We landed another great client in the Summer because of Ember.js. We are seeing a steady flow of work come in because of Ember.js but I don’t think we can meet our $5m goal by relying on inbound leads from Ember.js.
One thing we’ve never dealt with is selling our services into another company. We’ve got most work by companies making a technology decision then finding who is good at working with said technology. How do you convince a company unfamiliar with Ember.js that it is what they should use to build their product with? What if this person is not technology savvy?
I came to the conclusion that you cannot sell Ember.js directly. I needed help with building a sales pipeline and sales pitch. A friend put me in touch with Lorne Cooper who I have been working with over the past two months. Lorne convinced me that I had sales backwards. We need to start with Marketing. (he also convinced me that I couldn’t sell Ember.js)
So what we built was the DockYard marketing funnel. Working backwards from Ember.js, we broadened the funnel. If the answer is: Ember.js then the question should be What is the best Single Page App framework? (let’s save tech debates for another time). I didn’t feel that selling SPAs was any better than selling Ember.js. Again, the answer is Single Page Apps so the question should be How do you provide a modern user experience on the web?. Now were had something. Selling UX as a solution to companies was tangible. If we could market that UX improvements was the way to solve common problems in modern web apps then we could hook companies on the idea that Single Page Apps was the best way to deliver modern UX. If we could convince companies on SPAs then we have the chance to convince them that Ember.js is the best framework for building out SPAs. At this point we have to make a case that DockYard is the best company as building Ember.js applications. We now had our marketing funnel. We plan on putting this funnel to the test in early 2015, but don’t expect any significant number of qualified leads to be produced until late 2015, more likely early 2016.
Elixir
While we are not currently writing any Elixir apps I think it will be part of our offerings around Q3 2015. Specifically because of the Phoenix Framework being very similar to Ruby on Rails I think we should be able to ramp upon it quickly.
The other choices I considered looking into were Go and Rust. Elixir feels like the best of the three to me. It is far less popular than the other two but considering it is backed by Erlang and boasts the most approachable syntax, has meta-programming, concurrency, and is built for fault tolerance I feel of those three language Elixir is the best suited for the future. Of course, this is a gamble and time will tell.
Ruby on Rails
Our involvement with Ruby on Rails will never go away completely but I don’t see Ruby or Rails being a serious part of our technology identity in the future. I would like to think that we were out with a bang though, in early 2014 we were selected to redesign RubyGems. We launched the redesign at RubyConf and it was a nice way to say “thank-you” to a community that we’ve benefited from for so long.
Heading into next year
I always want DockYard to be a company that does not stagnate on technology. I enjoy working with and exploring new technology and I always want to push our engineering team to do that same. In the near future I think Ember.js and Elixir will be important for us, of course we must be open-minded enough about new technology on the horizon.
Design
Design has become so essential to our process I don’t understand how we go by in the early years without a dedicated design team. We rely upon design to manage our Discovery Phase, build and inform our estimations. Design has more impact on us converting a client out of Discovery to a full client than engineering does.
UX East
This year we ran our first Design conference, UX East. It was structured as a design camp with two talks and one workshop. The conference was organized by our Creative Director Steven Trevathan and Maria Matveeva we believe we were hugely successful.
We’re already beginning plans for next year’s UX East, as well.
Team Structure
Every project is now assigned at least two designers. This is partially because the projects are big enough to merit the team, but it’s also a huge qualitative add to the final delivery. Pairing designers is really helpful for “leveling up” as well. Matching designers by their different strengths they’ll help each other grow. The concept is very similar to pair programming, however the designers go through many rounds of critiques instead of using the same computer for an extended period.
While we hadn’t previously done this, and it looks like a fairly obvious improvement to make, the result has been surprisingly positive and our most recent projects are seeing a huge benefit from it.
Setting Goals & Sticking To Them
One thing we’re very good at is coming up with ideas. Lot’s of them. There is no shortage there, however there is a real challenge in effectively using down time and DockYard Fridays to commit to delivering on those ideas. I believe this is due to not having specific departmental goals that directly fit into company annual or quarterly objectives.
An example of this challenge is Tools of the Trade. In the beginning of 2014 we put effort into creating small and novel icon packs and distrubuting them as free to use. It generated some interest, and we had fun with our icons, but we dropped the ball and lost momentum on it. Not because we didn’t enjoy making them or that it didn’t benefit our designers by the challenge, but because it didn’t fit cleanly into any company objective.
We’ve set a Q1 2015 goal to create a program and agenda for design experimentation with a focus on single page web applications. By that objective we’ll be aiming to provide more practical design tools, design and interaction patterns, and free assets for other designers in creating single page web applications. By commiting to this goal and using Tools of the Trade as vehicle, we should be able to promote ourselves, “level up” our designers, and effectively utilizing downtime.
Business
On the business side of things we’ve begun to add more structure to DockYard. We hired a CEO coach to take us through an OGSM (Objectives, Goals, Strategies and Measures) planning session for 2015. It was a tiring two days of time that helped us discover what type of company we want to be. The management team has all decided that DockYard should aim big and that is what we’re going to do.
Office Space
In Q2 2015 we’ll be moving into a new office space. Our current space has served us well but it has its problems. The new space will be modern and have plenty of space for us (we’re upgrading from 2,800 sq/ft to 7,800 sq/ft). I’m excited to share those plans in the upcoming months.
Wrapping Up
I hope this year’s reflection has been useful for you in some way. Each year’s summary has felt different and I’m sure next year’s will too. As a company DockYard has taken some knocks this year but we came out stronger for it with more focus and an actual gameplan. I’d love to hear other’s experiences as well in the comments.
DockYard is a digital product agency offering exceptional user experience, design, full stack engineering, web app development, custom software, Ember, Elixir, and Phoenix services, consulting, and training.
