This is my final blog post for DockYard as this Friday is my final day at DockYard. Let’s discuss what brought me to this decision and what I’ve learned over the past decade from running a software consultancy.
First, I’ve skipped a few of these blog posts. The last one was published in 2014 yet I still have it in my head that I published at least one or two more of them. I think that has mostly to do with how exhausting it is to write this type of post and why I stopped doing them to begin with. I lean in the direction of transparency but as I’ve come to realize over the past few years my personal resources are finite and reflecting upon the truth can be exhausting.
A Bad Year
That year I stopped posting was also the beginning of a slide for DockYard. How we recovered and overcame that is part of this story that I will cover. This being my final post I also plan to reflect upon the technology decisions and missteps that DockYard made over the years at my direction. Everything tends to overlap but I’ll try my best to have mostly discrete sections to this post.
This post will also go over how we eventually grew into a 100+ person software consultancy. How we became trusted by companies like Apple and Netflix to work on mission critical software. And how we forced ourselves to adapt over time.
Heading into 2015 we were seeing problems across the company. Revenue outlook was very poor. Morale was suffering. And I was not in a personal space to make things better. Up until this point I mostly leaned on my own ability to just put my head down and barrel through things. I know people don’t like to hear about management types glorifying lack of sleep but my personal take on it is that I actually perform better when tired. Each person has their own methods for getting the most out of themselves. For me I focus best when I’m tired. However in 2015 my wife and I had our first child and things changed. It didn’t matter if I stayed up to work because most of that time I was no longer the only one up. As if running a business that was slipping and having a child wasn’t enough to put on my plate we also decided to buy a house that year. One that needed some fixing up. So I pretty much took on more than I could chew and when push came to shove things that I normally could manage and maintain oversight of began to slip.
I recall one evening having to tell my wife that I believed the company was going to go out of business. I’m not one to accept defeat very easily and I actually cared more about what people would think of me for having a company that failed than the actual failing of DockYard. This was the lowest point for me by far. And there is truth in that sometimes you have to face and admit these things before you can move forward. For me moving forward meant changing my approach to how I ran DockYard. Up until that point I was essentially a one man show. And this will likely really upset some people but most of my management group at the time was reinforcing that. I promoted based upon tenure and loyalty to the company rather than ability and willingness to actually manage. With the lone exception of Jon, who at the time was our head PM, the entire management team was one that I put into place and was constantly at odds with on trying to take work off my shoulders. I’m sure those people have their own perspective on things and they’re welcome to share that perspective but for me I was left with departments where I could not trust those that I put into place to run and I didn’t have the operational experience and frankly the guts to either demote or let those people go. But again, this was old me that faced problems by just putting my head down and pushing forward.
That doesn’t scale well.
For a few years we were trying to grow beyond 20 - 30 people and in 2015 if I recall correctly we were on the high side of this number. There are certain milestones where you grow to a number of employees and managerial overhead becomes a necessity. I’ve generally resisted this because I tend to project my own abilities as an engineer onto others. I prefer less oversight but as I’ve come to understand most people are actually the complete opposite of this. This resulted in multiple problems across the company: lack of personal career growth, lack of upward feedback, lack of downward feedback, lack of fulfillment, etc.., etc.. the morale of the employees was suffering and compound this with poor revenue projections and you begin to see why I felt we were going out of business.
What changed for me was that people started to quit. I think part of reasons were due to fear about our business pipeline. But ultimately the majority quit because of me. Including almost all of the management team. Somewhere in this mix I had promoted Jon to COO and thankfully I now had a partner in the company that I could share and plan how to properly manage this burden with. Slowly we began to put the right people into place on the management team.
I forget the exact order of each department but I wanted to take a moment and highlight Estelle Deblois who took on running the Engineering Department. She was pretty much starting from scratch operationally and built around her a team of her own and grew a department of single figures to one of over 60 engineers within five years. Due to my own personal experience of managers at companies I always wanted to make sure that the engineer running the department was someone who’s skills and abilities as an engineer everyone respected. With Estelle we get both an excellent engineer and an excellent manager.
We also have Michael Dupuis who took over Business Development. This position has historically been a revolving door for us. And that was mostly due to me not really understanding how to fill the role. I tried to bring on traditional sales people and that always failed. Mike’s career path went from software engineer into project management and some operational responsibilities. I believe that this is what made him effective in the BD role. When selling software services you need to know what you’re talking about. More often than not you’re going to have a potential client on the other end that has some engineering or project management background. It’s true that some firms have sales engineers, and we now do the same, but knowing when to bring in those people is also a skill. More often than not I found some sales people to try and code-word their way through conversations. They would want a short list of terms and basics for what we did and I would sit in on calls when these terms were misapplied. Software consulting above most other things is about trust. The client wants to trust your ability to spend their money wisely. If you start to erode that trust on the first few calls you’re hurting your chances of landing the contract. This is in part what Mike was able to do differently. I’ve also come to believe that for software services a big part of BD job is process and ensuring that things are getting done and moving forward. This is where more of the PM aspect of Mike’s background came into play.
Maria Matveeva took over a Design Department that was in a tough spot. In short order she was able to build a foundation that was not only reliable but also brought back processes to allow design to collaborate and receive feedback from other departments during design phases of contracts. This was critical in the months to come as it proved time and again to win us additional work from clients. Furthermore collaboration between design and engineering has consistently been cited as one of the most enjoyable experiences for our own people over the years. Unfortunately (for us) Maria was scooped up by one of our clients where she has had great success as their Director of Design.
As an aside, most other consultancies I’ve spoken with over the decade also struggle with BD as a role. And most have had the same problems that we’ve had. When I’ve spoken to ones that have found the right people for the role the story is usually very similar to our own. Promote from within, someone with either engineering or PM experience. If you are struggling with that position you should consider this perspective.
The point in which many of these changes began to manifest was actually during a Quarterly Business Review, or QBR. I don’t recall the specifics of what was being discussed but I just told everyone that I am terrible with people and I don’t want to be the people-person that was expected of me. (I may have actually said “I hate ‘people’”) I think there was a good 5 seconds of silence following this. It upset some people in the room, maybe everyone. For me, it was the moment that I was willing to start letting responsibilities go and allow others to take ownership. In other words, I was ready to start delegating. More than five years into being a CEO. Yeah.
There were many turning points for DockYard during this time. However, if I had to point to the most significant one it was this moment. I don’t scale and I was no longer able to fall back on just staying up late to get everything done. Beyond that I’m just not a people person. It is not a strength of mine, admitting that I was trying to fit the round peg into the square hole was obtuse for some and they let me know about it then and after but I know now it was the right move.
After this I began to step back a bit. I allowed others to take some of the hats that I had previously been wearing and as it turns out people who are hired specifically for a job are better at doing that job 100% of the time than I was trying to do that job 10% of the time. Go figure.
Things began to fall into place, in the moment of that year it didn’t feel as if this was the case. But looking back I can see how one good thing led to another.
The people who stuck with DockYard during that year are the ones I have to thank the most. They had every right to jump ship but they stayed and are a good reason why we not only survived that time but thrived.
That summer we received leads from Netflix and Apple. Now this part may seem bogus to you but from the day I started DockYard I was building it to capture a lead from Apple. It took us five years to get it but it finally came in. I had aligned our messaging and some of technology choices with what would be an obvious decision for Apple. The surprise was that the same month Netflix contacted us. I flew out West and landed both contracts in the same trip. We’ve been partners with Netflix and Apple ever since. Our Netflix projects are being moved in-house towards the end of Q1 next year but we remain on very good terms with them and I hope to see DockYard and Netflix working together again in the future.
Technology
This brings me to technology. I bet the company early on Ember.js. I can say now unequivocally that this was a bad bet. I’ve been vocal on this, more so as of recent, because I believe the Ember core team is selling unrealistic promises to an audience that buys into their cult of personality. This doesn’t mean that I think Ember is bad technology. I actually believe it is the best in class JS framework on the market. However, there have been too many missed opportunities, wrong decisions made, and empty promises. When you are building a company that sells software services at some point you have to accept that you’re fighting an uphill battle because the people you put trust in want to treat their project like a piece of art rather than a tool that people use to get shit done. I could write an entire series of posts on this subject but I don’t want to let it overwhelm the rest of this post. I’m happy to debate the merits of this topic elsewhere.
A technology choice that has worked out for us was Elixir. I’ve been through the language/framework lifecycle a few times in my career and by far the most fun I’ve had is with the Elixir/Phoenix ecosystem. I’m happy to say that DockYard’s investment in Elixir will continue without my being here and I’m very proud that we’ve been able to contribute to Elixir in a meaningful way. In addition to this I have to give special thanks to José Valim for not only creating Elixir but his approach to allowing companies like DockYard, which in many ways is a direct competitor to José’s own Plataformatec, to feel welcome in the Elixir ecosystem. That approach has encouraged us to continue to invest in Elixir.
My personal and professional frustrations with Ember and the JavaScript platform and community in general led me down the road of trying to find an alternative that I can live with. I played with Elm and it has too many strikes against it. I dabbled with TypeScript but that just kicks the can of problems I have with JS down the road. This lead me to dedicate significant DockYard financial resources to the effort of porting the Erlang VM, BEAM, to WebAssembly. The project’s name is Lumen and it is something that a team of our engineers has been working on for nearly a year now. While most of the public facing effort behind Lumen will happen after I’m gone it is my hope that in a year or two Lumen will bring a fresh perspective on how to build, maintain, and extend complex client side projects on the Web. Time will tell and because of experiences in other frameworks I’m being very careful not to make big promises on what impact Lumen will have. I much rather it speak for itself when the time is ready rather than me build it up without getting it into people’s hands.
On the matter of Open Source development I will take this final opportunity to reiterate something I said in a prior ‘Lessons Learned’ blog post. Something that several “thought leaders” reached out to me directly to ask that I retract: Open Source development has had no real meaningful and direct contribution to DockYard’s revenue. Ever. If you want to stretch the meaning of “direct contribution” and say that because of our contributions and support of various projects it has raised our profile and of course that is why we land projects, fine. But that is marketing. Marketing is not sales. We primarily capture sales leads because of our expertise. We demonstrate and defend our expertise in various ways, one of them being OSS development. At that point it becomes a bit muddy when trying to pinpoint the most direct reason a client comes to you. I personally have always believed and will continue to believe in contributing to OSS. In my future entrepreneurial efforts I hope to build teams that continue to participate and contribute to the language and framework ecosystems that are important to me.
Going Remote
Up until our bad year DockYard was always a Boston based company and we had hired in Boston or in special cases relocated people to the Boston area. We had an office space in Downtown Crossing that was meant for 40(ish) people. It was costing us about $35,000/month not including utilities. One day I looked around the office and there was maybe five people in that day. More and more often people were working from home. In some cases we had people that very much wanted to move away from Boston. While this wasn’t lost on me the idea of getting rid of our office was not mine, Jon is the one who pushed for it. I had recently promoted him to COO and one of the earlier tasks he took upon himself was to establish an operational expense baseline and the office space was a line item that very much was a luxury. This along with Jon’s experience as a PM gave him confidence in not only advocating to get rid of our office but that we could absorb this change and continue to properly manage the company. The collaboration tools that exist today are great, Slack, GitHub, Google Hangouts, Zoom, Google Docs are among the few obvious ones that allow teams to be productive without having to be face to face. I believe it was Fall of that year that we were able to negotiate our way out of the contract and begin our remote company experiment.
I have to confess something, despite many of the benefits of going remote that I’m about to discuss I’ve never personally acclimated well to it. I haven’t spent that much time thinking about it but this could have contributed in some way to my decision to leave DockYard. That decision unto itself is a complex one that I will dive into later in this post but I cannot deny that working from home has been difficult for me.
While being a remote company hasn’t been great for me, it has been great for DockYard. We did have some turn over, as expected, with the move. Those that stayed had to adjust and put up with this transitional period for us. This effort was led almost entirely by Jon and it has been a major reason for DockYard’s turn around and success. Removing a $400k+ expense had an obvious impact to our financial situation. This also opened up our potential talent pool to… anywhere. It took time to build out the process and infrastructure to properly support hiring remote. But a hire we made the year after was one that in my mind was one of the best hires we’ve made in the past few years and that was our head of Employee Happiness, Sarah Woods. Sarah came to us by way of GE and began to take many of the HR duties that has fallen primarily onto Operation’s plate. Over the past few years we built up a very large team for one client that had multiple products that we managed. Developing a potential talent pool to tap into when scale was necessary was managed by Sarah. Managing and mitigating our risk as we continued to build a remote culture was managed by Sarah. Building career paths, tracking and responding to employee performance and happiness was managed by Sarah. She had help for certain and each department was responsible for interviews, reviews, feedback, etc… but if Sarah didn’t oversee the implementation of these efforts she most certainly managed the scaling of them as we doubled in size two years in a row.
Hiring good people from wherever we want is a powerful tool that DockYard can use, it gives the company a distinct competitive advantage when it comes to the business of hiring experts. This brings me back to Boston. Maybe the timing was just right but Boston has become an impossible environment for many to work and live in. Most cities have congestion problems. Boston has been scored to have the worst traffic in the US two years in a row. The Boston Globe Spotlight team, the same one that had a movie made about their child abuse investigations of Roman Catholic priests, recently published an exposé on just how bad commuting in Boston is and how difficult it will be to address. Add to this that Boston regularly scores in the top five most expensive cities to live in the US and what seems to be worse and worse weather each year you can start to understand why there was a desire from some of our employees to work from home and in some cases get the hell out of here. I sympathize, it’s no way to live and certainly incredibly difficult to thrive.
Leaving DockYard
In 2016 I made the decision to leave DockYard and pursue other efforts but I didn’t communicate this to anyone until the summer of 2017. I wanted to get the company back on track. I also wanted to fulfill my goal of either running DockYard for 10 years or generating revenue of $20M in a single year. As luck would have it both of those goals are being achieved this year. We made Inc. Top 500 companies this year. We crossed 100 employees. Even in 2016 I could see the path towards these milestones it was just going to take time. My role at the company during this time changed from overbearing CEO to one that is nudging the company one direction or another and allowing others to get the work done. And while I am confident that my vision for what DockYard could be was more often correct than wrong I actually prefer to be hands on. There were most certainly moments of regression where I would just jump into something and do it over the past few years but I’ve gotten better about it.
The company was also turning into something different. A software consultancy at some point always becomes a people management firm. The headcount is much higher for revenue than it is at most other types of companies because we are directly selling our people’s time. The only way to scale that is to either find more time to sell, which we try very hard not to do, increase the cost of that time to our clients, which we have more or less settled in for the past few years, or add more people, assuming you have the projects to put them on. As I previously indicated: I’m no good with people. The prospect of continuing to build a company who’s management was primarily tasked with people management responsibilities holds no interest to me.
Changing to a remote company also affected me. It was a difficult time as I already mentioned with our first kid, buying a house. And we started a full house renovation. While it could be said these are things I signed up for, they’re not abnormal life events. Balancing this with working from home was something that was difficult for me. There is also just how accessible I was at home for my wife. Something that we have never gotten past is how to distinguish me being at home and dad/husband and me being at home working as CEO of a moderately sized company. Why not get a co-working space? Well, we have a small office. In my town. I just don’t like going there. I preferred the energy of the office of my company rather than surrounded by strangers. Take that for what you will but it’s my take on it.
Having to balance all of this led to burn out. While in the past I was able to find a way to make it all work and balance I just couldn’t continue. However, I most definitely did not want to just ditch the company. So I gave it some time and decided I would wait out the entire 10(ish) years I originally planned on. In the summer of 2017 I notified Jon of this decision and told him that I wanted him to take over as CEO. Jon and I have very different management styles and his was better suited for the direction the company needed to move in. Mine is better suited for a more volatile environment that moves fast, like an early stage for a company. I’ve also had a few ideas on product companies I want to try my hand at. I’ve done well at DockYard and am now in a position that I can take some risks.
The two and a half years of ramping me down was likely a year too long. It took some time to properly detach me from many of the duties at the company and I eventually settled into more of a high level advisory role that happens to have CEO powers. This allowed me to start some R&D projects that otherwise likely wouldn’t have happened.
Lessons Learned
Over the past few years I’ve had many people ask for advice on starting and growing a consultancy. The idea that people view DockYard as a success story is still a bit foreign to me. I don’t know if I’m just never satisfied or if I just know how the sausage is made. The reality is that the brand a company projects outward is never what is happening internally. Consulting is a messy game. There are cut throats. There are clients that want to steal. There are jobs that can allow your company to grow one day and nearly put you out of business the next. There are often many and conflicting roads to success and there are even more to ruin.
One lesson I have learned that I think applies not just to consulting but business in general is that you have to be lucky. I have spoken to and heard from too many “business success stories” people over the years and the common thread is that at some point they got lucky, especially the ones who don’t want to admit it. No matter how they try to spin success is tied to luck more than anything else. However, your chance at getting lucky is where the skills of running a business come into play. The longer you can stretch out your business strategy then you increase the potential of luck playing out in your favor. Sometimes it is a contract going your way. Sometimes it is an early investment paying out. And sometimes it is just sticking it out until your message has gotten across. I see so many companies that focus on the VC style of burn through as much cash as possible as quickly as possible because they need to make a big splash. Maybe that is fine for pump and dump style businesses but if you want to build something that is going to persist and thrive you have to think about the long game. Where do you want your business to be five years from now? Ten years from now? Figure that out and work backwards from there. The mental exercise of going backwards from the potential of success allows you to develop a proper strategy to achieve it.
I got lucky with DockYard. But I also went out of my way to become lucky. I stretched money, I made bets that seemed risky, I got involved to ensure those risks paid off. I’m opinionated and divisive. I made good friends and lost friends. I made some enemies and I also built something that has provided for me and my family. DockYard has been more than what I originally bargained for yet it is also what I was trying to achieve. I can walk away feeling that I accomplished something and knowing that the company is in good hands. That’s the best I could have hoped for.
