28
20 Comments

I co-founded a software agency 10 years ago that's grown to ~100 consultants and is now 100% employee-owned. AMA!

Hi everybody!

I'm a career-long software developer consultant who, back in late 2011 co-founded a humble consulting company named Test Double (testdouble.com). While we've grown a lot over the years, our mission has been constant: improve the way the world writes software by working with clients who are building great things and share a vision for finding ways to make software (and the whole industry) better in the process.

A few highlights follow:

No two client engagements are the same, but in broad strokes we typically start each new client relationship with a pair of our consultants joining one of their engineering teams to ramp up quickly, work alongside them getting things done, and (once we've built some trust) start identifying opportunities for improvement—whether focused on technology, process, or any of the thousand other concerns that go into building a complex software system. We've gradually built a network of clients that love working with us and it's opened a lot of doors to help awesome companies like GitHub, Zendesk, and Gusto build amazing systems and teams.

We started small and have grown steadily over the years by hiring sharp developers and trusting them to do great work and delight our clients. Our folks generally feel a strong sense of pride and ownership over their work, empathize with and adjust to the needs and perspectives others, and continuously strive to improve themselves and their craft. As a result, we trust our "Double Agents" with a lot of autonomy—they're the ones who are closest to the work, so they'll typically have the context to know the best way to solve the problems in front of them.

Because we've been fully remote (across the US & Canada) from day one (which was a little more contentious in 2011 than it is now), we've really learned a lot about building a remote organization and helping clients improve how they manage distributed people and teams.

Finally as of 2020, we're now a 100% employee-owned ESOP. Which is a really awesome way both to share the company's success equitably with our people and also a huge topic in its own right (Some more details from my co-founder and Test Double's CEO here: https://is.gd/td_esop )

Ask me anything!

  1. 2

    Hey Justin, thanks for answering some questions. On Test Double's site it mentions " employees will be allocated shares on an annual basis, these shares will vest over time, and at the point where an employee exits the company, a payout (or tax deferred rollover) can be completed based upon the number of shares" - what is the avg. amount of shares you're giving employees annually and at what price/per share?

    1. 2

      Thanks for asking! Because we're operating under a well-defined, well-regulated Employee-Stock Ownership Plan (it's a program that was enacted by the US Federal government as part of ERISA, similar to others like a 401(k)), the answer to this and most other questions has a rigorous, knowable answer that we have to adhere to (rather than just a profit sharing policy we made up). For more details on ESOPs generally, NCEO's primer is the best resource online

      To answer this specific question as well as I can, I'd say this: when the ESOP was created, all of Test Double's shares were transferred to a trust that represents the ESOP. According to the plan's rules, for the first thirty years of the program and on January 1st every year, 1/30th of those shares are allocated equitably to every eligible employee in the company. (After that, subsequent share allocations are based on share availability due to people cashing out, like folks departing/retiring)

  2. 2

    When you're starting with a new client and attaching to their engineering teams have their been any teams that are hesitant to take on an outside consultant or are they just generally glad they've found someone who can help?

    1. 2

      Great question!

      Yes, absolutely, this happens. And I think it's totally natural for team members to feel hesitant. If I were on a team and my manager announced "hey everybody, we're adding some outside consultants to the team", my reaction would start out as a projection of however I was already feeling. For example, if I was a client developer and I was already worried that management thought I wasn't getting enough done, or that my code quality wasn't good enough, or that I didn't know the right skills, to hear that they were adding outsiders to the team would likely confirm my fears & doubts and I'd react by feeling threatened or defensive.

      The approach that we've taken from day one (and improved over time) is to emphasize early on in the sales process that we do not present ourselves as "coaches" or "mentors". We also encourage our clients to introduce our people to their teams and develop some level of comfort before we get started, giving them an opportunity to raise concerns (either generally, or with the particular people we're proposing to join them) early. We genuinely want to help everyone we work with and as a result want to make sure they have a great experience every step of the way—and that starts with making a great first impression, to the extent it's within our control.

      Once an engagement kicks off, we strive to meet people where they are. Our folks tend to be highly experienced and capable in a variety of technologies and methodologies, but we try to depressurize any concerns by presenting ourselves as extra hands hoping to make lighter work of whatever the client team is already working on. Our process starts with your process. Our tools start with your tools. We go in assuming that everybody we work with is smart, and that they landed on however they're doing things for good reason—after all, nobody will have more context on the business and systems in place than the people who built them!

      This mindset not only makes us easier to work with, it also leads to better results. By actively working to deflate high-pressure scenarios, we build rapport more quickly and are able to ramp-up more quickly thanks to higher-bandwidth communication and richer, authentic collaboration. And because we hold back on spewing any context-free advice (e.g. "oh you're using X, but Y is clearly superior" or "what, you don't practice XDD?!") until we've worked together and built some trust, any ideas & advice we offer will be informed by actual experience working in the client's systems and serving on their teams, custom tailored to address their most pressing needs (as opposed to merely imposing our favorite way of programming)

  3. 1

    Thanks to the author for the described experience of working as a consulting company. Software development consulting means providing companies with IT expertise to offer solutions to their problems.https://www.cleveroad.com/blog/software-development-consulting/

  4. 1

    You mentioned meeting customers where they are in terms of technology and tooling choices. How do you balance doing that with technologies you may not have much expertise in? Specifically I'm curious about what point on the expertise scale you turn down work (if ever)? Do you do anything around pricing or expectation setting for things you expect to need more ramp up time in? Do you do anything systematic in the way of preemptive investment in technologies you expect to be asked about more in the future?

    Also, the questions and answers here so far have been fantastic so thank you.

    1. 1

      This is hard for agencies to get right because two things are true at once:

      1. Services firms are oriented around providing clients with business value (e.g. "this project will make or save you $X per year once completed") are unquestionably more impactful and successful than services firms that are oriented around implementing specific technologies (e.g. "we're a Ruby on Rails shop")

      2. No developer can possibly provide expert-level services in every single technology stack that a client might be using, and it would be foolish to discount the constraints this reality places you from recruiting, culture, and staffing perspectives. You need to focus on a subset of technologies

      So our go-to-market messaging has always been that software is broken in myriad ways and we are on a mission to help companies achieve their business goals in spite of that fact. But where we chose to spend our time (conferences we went to, meetups we networked in) was intentionally focused on the technologies we wanted to develop expertise in. We believed that the Ruby on Rails community and the (still emerging) "build real apps with JavaScript" communities were two areas where a lot of people shared our core values about building better software and so that's where we spent a lot of our time sharing that message and meeting people.

      Naturally, this strategy built our network of both recruits and sales leads alike with a similar profile of technical skills, which meant that as we got deeper into a community we'd be more readily able to help clients that happen to use those technologies. (Over time we've picked up a lot of Elixir work in a similar way) So, by picking relatively niche technology communities we tend to self-select for people who are more aligned-than-not with our view of the world, which led to shorter sales cycles, higher close rates, and more recruiting traction. All of this in spite of the fact that we went to great lengths to never talk about being "a Rails shop" or "Backbone/Angular/React/Vue/Node.js experts" but instead led with the same core message, custom-tailored to the particular pain points relevant to each community at the time.

  5. 1

    How senior (technically) did you consider yourself to be when you started? Did you just cherry pick what you were capable of and hire in any gaps?

    1. 1

      I was previously titled as "Senior Developer" when we started Test Double. I had about ~4 years of software & process consulting at a wide array of kinds of organizations at that point, had started publishing open source libraries, speaking at regional Ruby and JavaScript conferences, and identified and sold my most recent client engagement by offering a training workshop.

      I had a lot of gaps then and a lot of gaps now, and I've just approached every day with a mind to diving as deep as I can into whatever it is I'm working on and giving myself permission to not know the things that my immediate client engagement didn't call for.

      I will admit that this wasn't attainable for me in a sustainable 40 hours a week. In the years prior to starting Test Double I was probably working a combined 70 hours a week between work-work and work-related extracurricular learning/community/open source; the fact my previous employer wasn't compensating or valuing me for the latter chunk of hours is a big reason I wanted to start a company that would (inherently) value it. And after starting the company and for the first five or six years I continued to work a lot of overtime. I share this only as a caveat to say that this is how things worked for me, and my approach likely won't apply to everyone.

  6. 1

    Thanks for doing an AMA, Justin. We are a small, boutique consultancy, too, and really look up to agencies like testdouble and hashrocket.

    When you folks were smaller, how did you attract the best people and recruit?
    How do you compete now with VC-backed salaries?

    1. 2

      When we were starting out, we did a few things as we were getting started that I think increased our odds of success:

      1. We were humble and hungry. If a prospective client wanted to work with us and could pay a reasonable rate, we'd take the work if we were available and capable of doing the work, even if it wasn't particularly glamorous or using our favorite languages & technologies. Admittedly, this was easier when it was just the two of us founders and we weren't signing others up for the less desirable work, but the mindset of putting the client's preferences ahead of our own biases was a good tone to set. Everything boils down to prioritizing the customer's success as much as your own. If you can delight a customer with your work, they'll ask for more help. They'll tell friends about you. Their people will leave that company and tell people at their new company about you, putting a flywheel of referral work in motion that'll serve you years down the road.

      2. We owned our ignorance and asked for help. We asked for advice from folks like Kevin Taylor at Obtiva (shortly after we started, they were acquired by Groupon), Chad Fowler from InfoEther (same, but LivingSocial), Paul Pagel at 8th Light, Marian Phelan at Hashrocket, JC Grubbs at DevMynd (now Tandem), Carl Erickson at Atomic Object, and so many more. One thing I learned is that if you email a person that you look up to for advice about what made them so successful, they'll almost always gladly reply with useful information (people love talking about themselves—look at me, now, doing this!) A lot of these conversations supercharged our understanding of how to run an effective small services firm; everything from what rates people were selling at to what tools people were using for things like invoicing and payroll

      3. We were incredibly fiscally conservative. We had both been in sales or management roles at other companies during the 2008 crash so we knew what it looked like to go 6 or 9 months without a single paying project or forced to lay off unimpeachably brilliant developers as a result of insufficient cashflow. For the first several years of the company, our chief financial benchmark was what we called "runway": if every client disappeared tomorrow how long could we pay everyone on staff before we would be forced to let anyone go. We were incredibly fortunate that the nightmare scenario never came, but it really forced us to be good stewards of the company's resources.

      As for hiring, the most important thing we did was show up in communities of people that cared about what we cared about and shared useful stuff for free: open source, blogging, user groups & conferences. We didn't set out to write a manifesto, but in hindsight we can see a continuity of vision for how we think the industry is broken and what it will take to fix it through all of our public-facing messages over the years, and that became a signal that resonated with a lot of other people (clients and recruits alike). This was awesome not only in that it introduced us to great people, but those people usually didn't require a lot of explanation or convincing once they were talking to us, since they already "got it".

      Compensating people fairly is incredibly important. And while it's definitely challenging, it isn't quite as vexing as it might seem—as salaries rise, so do the market rates that people expect to pay consultants. While there is sometimes lag between the two and sometimes one increases before the other, they tend to rise and fall together. So whenever our rates increase, we see it as an opportunity to increase salaries to make sure we're compensating people fairly. There's no way we'll ever be able to pay the same salaries as the best-funded mega tech companies, but there's no way that they'll ever be able to create the kind of work environment we have.

      1. 1

        Thanks for the sage advice @searls!

  7. 1

    Very impressed by the transition to an ESOP, and the way you talk about software development. I'd love to hear about the path that took you into being a Software agency, rather than a marketing agency.

    I'm fortunate enough to be a successful Software Engineer with a passion for business and product, my skills lend themselves perfectly to helping a business ideate, architect and build Software to meet complex needs, which I've had some success doing, but I'm struggling to grow beyond the-guy-people-call-for-websites.

    The majority of work that comes to me is work that doesn't need Software Engineering, and so I spend a lot of time helping prospects understand that a website for marketing does not need Software Engineering, that there are many more cost-effective options available -- both in terms of upfront cost, but also the total cost of ownership. My biggest value delivered to businesses thus far has been in helping them understand that they do not need code...

    ...and that's great, convincing businesses that they don't need software is absolutely a positive, meaningful output -- if they can meet their need with an easy to manage Squarespace site, they're going to feel the benefits for years to come -- but it doesn't scratch the surface of what I can offer. I have come to believe that most businesses do not need software development, they just need guidance on how to leverage existing technology, and my challenge is to get in front of clients that are likely to need new technology.

    The landscape has changed a lot over the last decade, especially with the rise of (excellent) No Code platforms, so I appreciate that what you did a decade ago won't necessarily apply today, but I'd love to hear your insight into this anyway. Did you inbound as many prospects as you can, and filter out those that are a poor fit? Did you accept all work, and over time lean into the work that felt like a good fit? Did you have a referral relationship with other agencies?

    Thank you,

    1. 3

      Thanks for sharing a bit of your story! And I can completely relate and empathize. I take a lot of our sales calls at Test Double, and I view them as an opportunity to offer listen to people's challenges & opportunities and (if they're interested) offer some free consulting, rather than naively push a prescription that more software developers is the solution to every problem. And you're right, a lot of the time people think they need to hire an expensive software developer to undertake an expensive, high-risk custom software development project, when some off-the-shelf solutions (or No Code configuration glue) will get them what they need. I'm glad you've been willing and able to help companies in that capacity, as well.

      As for the frustration that you called out, I have seen some folks run into the same thing when first taking on consulting work, and it does remind me of one possibly useful bit of advice. A common misconception is that the only people who could benefit from outside contractors are (1) people building some greenfield application that is brand new or (2) companies that don't already have their own development staff in-house. In fact, for the entire life of our company, we have focused on helping successful businesses work improve their existing systems (getting new feature work done while paying down technical debt) and in close collaboration with their existing engineers. Because of how plentiful legacy code is and how scarce developers that can gracefully navigate it are, most development teams are spread pretty thin and eager to receive some outside help.

      So if your approach so far has been to look for brand new start-ups, you might have less luck than to look at companies showing up and sponsoring community events in the technology areas that you specialize in—it's a great indicator that they're (1) successful enough to give back, (2) continuing to invest in their product and the technologies it uses, and (3) interested in increasing their awareness with other people in that community. We spend a lot of our time meeting other likeminded developers at conferences and user groups for this reason, and it's really paid off.

      Good luck!

      1. 2

        Thank you very much, that's very insightful and actionable -- hopefully, I'll be able to return to Indie Hackers in a few years with my own story of success, shaped by your insight! See you in 2025 :-)

        1. 1

          Feel free to reach out to me any time here or on twitter if I can ever help you out!

  8. 1

    Do you ever get requests to build out an entire app and backend system rather than help refine an existing one and do you ever provide that service?

    1. 1

      Yes, absolutely. Sometimes we'll have the opportunity to help build brand new systems from scratch, both for startups that are just getting started and for existing businesses that are building something new. When we're working in that model, we do our best to help our client be an effective product owner by supporting them as they identify, validate, and prioritize the work to be done and proactively broadcast our progress, observations, and challenges on a daily basis so that we're fostering a highly collaborative, super efficient, and feedback-rich environment.

      After we've built something for a client, we want to make sure they're set up to continue to grow and succeed, so we're also happy to help recruit and qualify staff to backfill our consultants and maintain & grow the system even after we're gone. Because our folks are also very good pair programmers, interviewers, and teachers, being able to cross-fade by working alongside these initial hires as we ramp down is a great way to transfer knowledge seamlessly while ensuring the client will be able to continue making forward progress without stopping all development until they can spin up a team on their own.

  9. 1

    yo @searls!

    i'd be remiss if i didn't ask about revenue. are you open to sharing any of your financials? (no worries if not!)

    No two client engagements are the same

    this caught my eye. developer entrepreneurs are often wary of starting service businesses (as opposed to saas companies, for example) out of fear of always being on an hours-for-dollars treadmill.

    how "systematized" are you and your team when it comes to working with clients? for example, do you have documentation? standard operating procedures? any tech automation?

    or perhaps a corollary: how scalable are your operations?

    1. 3

      A lot of people's interest in starting a company is primarily driven by a desire to generate passive revenue that decouples their income from the time they expend. As a result, most entrepreneurial advice and community energy revolves around SaaS products, since they can very directly enable recurring revenue at very little marginal cost or time expenditure. There's nothing at all wrong with that, but I think it's important to understand that this coincidence is the reason "entrepreneur" has become functionally synonymous with "person who wants to start a SaaS product". Because if someone wants to start a business to decouple their labor from their income, there has never been a more successful vehicle for that than SaaS.

      But even if your impetus is passive income, you'll inevitably need other people to scale (developers, sales, customer support, etc.). I just tend to think of SaaS startups as primarily passive revenue generators and secondarily as people-oriented organizations.

      I imagine services companies as sort of the opposite: they're primarily people-oriented (literally, whatever service they provide to other humans) and only secondarily capable of generating revenue at reduced marginal cost. It's possible to get to near-passive income in services, but it's rarely sustainable and typically only achieved at pretty massive scale—so if that's your goal, be prepared to spend 10-15 years working to get there.

      We went in eyes wide open about this. We founded the company because we have a lot of empathy for developers and non-technical businesspeople alike: most software projects and teams fail and we want to help others succeed. The fact we get to spend so much time with our clients is exciting and motivating because that's the way we'll have an impact on the world.

      So to answer your question: yes, as time has gone on, we've become far more systematic and streamlined around everything from drafting contracts to sales to interviewing candidates to project onboarding. Sometimes that has been by creating processes or document templates or by finding (or building) better internal tools. But at the end of the day if your people's time is your business, any optimizations you make should be to maximize the amount and quality of that time with the customer. That's the core loop of any successful services company. I have seen some folks try to turn their services firm into a passive revenue generator, but I've never seen it done in a way that turned out to be better for their customers and as a result always failed in the long run.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 16 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments