October 21, 2016

How to Be a Good Client for an Agency

Today, we want to share our perspective on what makes a good client for a software development shop like Clear Function.

There are a lot of developers out there—approximately 11 million, according to IDC. There are also a lot of car repair shops. You want honest, skilled mechanics working on your car, and you want honest, skilled developers working on your software.

But that’s where the similarity between software development and car repair ends. If an unskilled mechanic makes a bad repair, he might cost you $10,000. If an unskilled software architect makes a short-sighted choice, he might cost you $1,000,000.

How to Be a Good Client for an Agency

You want to hire a world-class dev agency because you want both our skills and our decision-making; both our minds and our hunches. In software wrong hunches scale out along with everything else, which is why world-class developers save you money in the long run.

As you can probably guess, the best ones evaluate new clients and projects slowly and carefully because they don’t want to accept doomed-to-fail projects.

In fact, the best developers get more project requests than they can handle, and thus the interviewing goes both ways. We’re fortunate to be in that kind of position at Clear Function, and in this two-part series we will offer recommendations on how you can cut through the noise and improve your chances at getting a “Yes” from a world-class development shop.

#1 – Change the way you think about software development.

Thinking... please wait

Some people think software development is like manufacturing. The higher-ups hand down the plan to a manager. The manager lines up workers. The workers do their jobs with efficiency and skill, and the project comes off perfectly.

That’s not how software development works.

A better analogy is a Hollywood set. The entire crew shows up on appointed days. The name brand actors and producers have big jobs, and the grips and caterers have smaller jobs. Though a successful production requires inspiration, most of the process is simply work—unglamorous, mostly thankless work.

In like fashion, every strong development team has a moving cast. Based on their skills and the needs of the moment, a developer may have a starring role in one project and do a coffee run during the next. We’re not assembly line workers.

At some point, your project may require a one-of-a-kind contribution from each of our brains. Over the course of any given week, we solve dozens, if not hundreds, of small, interconnected problems. We’re holding a house of cards together in our collective brains.

It’s important that you understand how software development happens, in practical terms, so that you can honor the incredibly complex and difficult process and speak with due respect to people who are trying to move heaven and earth for you.

Here are some key differences among team members:

  • Technical focus vs. business focus
  • Solving “global,” project-level problems vs. “local,” in-the-trenches problems
  • Greenfield specialists (getting the project started) vs. Brownfield specialists (evolving existing projects) vs Closers (dotting I’s and crossing T’s to polish a project for shipment)
  • Technical leaders vs. strong contributors
  • Various technology specializations (Examples include Rails, Angular, and Vanilla JS.)

#2 – Prepare to spend money on consulting, not just code.


These days, software development is fragmented. Maybe it always has been. It’s easy for non-techies to assume that software developers are interchangeable cogs, but we’re not.

In fact, it is highly unlikely that you will find a single developer who is good at everything: architecture, servers, frontend, backend, quality assurance testing, and iterating. As a result, you’ll need a crack squad of specialists.

Do you have the time and the peculiar skillset needed to attract, sort through, and manage the various developers required to build one awesome product?
It also takes years to develop the discernment to see, based on the project’s requirements, which team members and skillsets should fill out the team and solve the puzzle faster.

For example, your project may need a Ruby on Rails expert and an iOS expert working in tandem. Clear Function’s Co-Founder and CEO, Colin Neller, has spent years learning how to source talented developers and build cohesive teams. Every project is a jigsaw puzzle. Unless you’ve already put in the time like Colin, you may need help solving it.

If you don’t have this peculiar skill set, then you will need someone to consult with you, point out various technology options, and help you make smart choices based on what you want to accomplish, business-wise.

At the beginning consulting is significantly more important than coding because you may still need to figure out what the outcome should be.

Don’t build something. Build the right thing.

Here are six things your tech consultant must address:

  • Core technology choices that take the following into consideration:
    • Productivity
    • Project & Maintenance teams
    • Scale
  • Coding organization
  • Team configuration
  • Project phases
  • Identification and availability of product owner
  • Stakeholder communication

#3 – Manage your expectations.

When you ask about timelines and budgets and we give you estimates, keep in mind that that estimates are just that: estimates. Estimates are our best guesses.

We love coming in on time and on budget. But we have NEVER seen a requirements document stay the same for the duration of the project.

For us to tell you that we can’t really gain a precise understanding of timeline and budget until we’re several sprints into the project is true. But we recognize that this particular truth is a hard pill to swallow. You’re not made of money, and you don’t have forever. We get it.

But keep in mind that we’re not trying to pick your pocket or anybody else’s. We’re not trying to create more work for ourselves by any means possible. We are honest, and we are, in fact, trying to predict the unpredictable.

If we tell you that we don’t know exactly how much the product is going to cost, that’s because we really don’t know.

More often than not, we’re trying to do something that has never been done before. We’re trying to get seven different technologies to play well together. Add to that the fact that technologies are always being replaced or becoming obsolete. One day, a function in iOS works. The next day, Apple deprecates it.

The whole problem-solving process must begin all over again.

We’re human, fallible. We want to be honest with you about our knowledge gaps. You’re human, fallible. You want hard numbers and hard timelines from us, but in reality there’s no such thing as a perfect performance from every player every day.

We may refuse to give you hard numbers and deadlines because we genuinely care about your project and your company. Clients must be mentally and emotionally prepared for peaks and valleys. So please manage your expectations.

You’ll have to be satisfied with our guesses.

Sorry. That’s the nature of software development. If you can’t stomach that kind of uncertainty, then Clear Function and other honest developers probably won’t be a good fit.

Word to the wise: Anyone who tries to tell you otherwise really is trying to fleece you.

Here are our three options for managing cost together:

  • You set a fixed cost, but we control the scope. We tell you how much we think we can do inside of the budget constraints.
  • You can set the scope, and we then estimate the cost.
  • We go the agile/iterative route together. We recommend a team configuration, and we all create milestones together. After each development sprint, we connect with you to discuss where we are. We then set new priorities for the next sprint. As we go, we sharpen the focus on the total cost, scope, and timeline.

#4 – Bring a cohesive vision.


When we interview you and you interview us, we want you to bring a cohesive vision to the table. Ideally, you will have already hashed out the major details with the other stakeholders in your organization, and you want domain experts like us to bring more definition to that vision and make it more likely to succeed.

Come to us with a cohesive vision, and you’ve got our attention.

On the other hand, if during our initial conversations, we sense discord or disagreement in your organization, then we will take a step back. When executives start drawing battle lines around a software project, we look for more favorable conditions with another client.

For us there’s a HUGE opportunity cost in investing hundreds or thousands of hours of our lives creating something that may never see the light of day.

We’re software developers, not mercenaries. We simply can’t do our best work when bullets are whizzing by our heads. Not finishing a project is a huge disappointment, so a lack of unity is a big red flag and a big turn-off.

So what we need is for your internal team to do battle behind closed doors and then come back to us with a cohesive vision. We care deeply about bringing functional software into being, and we would love to help make your cohesive vision a reality.

Come to us after you have made decisions and allocated resources for the following:

  • Single point of contact – This person should have ultimate decision-making power for the duration of the project.
  • Single product owner – This person must understand and champion the vision for the project.
  • Team configuration – Plan to keep the team configuration as consistent as possible over the course of the project.
  • Testing – Be prepared to making testing new functionality, as it becomes available, a top priority on your side.

In Closing

We hope you better understand now what the top agencies are looking for in a project and how to be a good client. In Part II of this series, we will follow up with more advice gleaned from our 150 years of combined experience in building software for clients.

In the meantime, shoot Stephen an email at [email protected] with any questions or ideas for blog posts you want us to write.

Related Posts

Posted by