In our first post about how to be a good client for an agency, we shared four pointers for making yourself attractive to high-end software developers:
- Change the way you think about software development.
- Prepare to spend money on consulting, not just code.
- Manage your expectations.
- Bring a cohesive vision.
We began that post by making a point that is worth repeating: Demand for software developers exceeds supply. In fact, the best developers become very selective, and not every company that needs world-class talent will get it.
Not every client who pays for software will end up with functional, well-architected product.
We don’t tell you that to scare or discourage you. Rather, we want to give you insight into the budgeting, decision-making, and communication practices will help you be a good client and attract an excellent agency. Before money ever changes hands, you can send the right signals, and get a “Yes.”
If that sounds good to you, keep reading.
5 – Set aside more money than you think you’ll need.
We mentioned in Part I that world-class developers want you to come to the table with a cohesive vision. For your internal team to have already reached an agreement about what you want to build helps us to understand the project’s scope and give you a more accurate estimate.
That said, it’s normal for everyone’s understanding of that vision (and how the project makes it real) to morph and evolve as we build the software.
For example, down the road, your team may have low-grade disagreements behind closed doors. One person believes that a small feature is critically important for product-market fit. Another person doesn’t see the evidence to support that conclusion and counters, “Let’s get this first build out the door and see if any of our early users asks for that feature.”
Let’s say that in this case the person with the loudest preference wins, and you then deliver the news to us: “We need to add this feature.” For those of you new to software development, this is called scope creep.
Good developers respond to scope creep in one of two ways:
- The team talks over your request, and based on the size and significance of your change order, we conclude that the budget has some cushion left. The cushion can “absorb” the new feature. We get back to you and say, “No problem. We’ll add that feature build-out to the next development sprint.”
- Or, we might ask you to sign a change order and produce extra budget to cover the added scope that the new feature represents.
And honestly, response #1 or #2 is what you want. Both of those options mean that your team is still engaged. They care enough about you and about bringing the project to a successful conclusion that they’re willing to have a potentially awkward conversation about money.
There is a third option: The lack of clear direction has demoralized them. They know the change request will eat into the budget, but they now believe the project is doomed to fail. Their primary goal becomes sucking it up and surviving the death march.
Simple change orders are often more complex than they seem, and as a result, the costs of a change order might be off-putting at first. If you already have extra “rainy day” funds earmarked for the project, then we simply get back to work. But if you tapped out your total budget with the initial scope, then scope creep can thus create an awkward situation.
You say, “Well, I just forgot to include this. I didn’t remember until just now.”
Or, “My boss says we have to include this feature.”
Or, “I had an idea in the shower this morning, and I don’t think we’ll have a marketable product unless we add this extra functionality.”
We want to make you happy, but by not coming up with the extra budget, you would, in effect, be asking us to pay for your oversight.
The best way to avoid most of this awkwardness is to budget for multiple versions or iterations instead of a single scope document. No one likes being over a barrel, and the worst that can happen is you get to the end of a successful project with money left over.
6 – Over-communicate, and when in doubt, pick up the phone.
Our favorite clients and favorite projects all have one thing in common: clear, copious, and consistent communication.
During a custom software development project our conversations will touch on many areas: expectations, scope, cost, timelines, your internal decision-making process, product ownership, and project requirements. And that communication will happen in a variety of ways—for example, email, project management software, Slack, and texting.
No one expects perfection in any one of these areas, and hiccups both in communication and in the software development itself do happen on occasion.
When things get emotional or when a big decision needs to be made, let’s get on the phone. Email is seldom the best medium for expressing frustration. In fact, it seems to compound rather than alleviate frustration. In our experience a quick call helps us avoid miscommunication and get on the same page again as quickly as possible.
7 – Establish a clear chain of command.
It is really helpful for us to know who is going to have ultimate authority and make crucial designs along the way.
The buck must stop with a single individual who is personally engaged with the project. That individual must be the keeper of knowledge about high-level stuff like vision and mission, as well as knowledge about day-to-day concerns, such as development sprints and deliverables.
Some of our favorite clients have been owners and executives. If the CEO brings us in, it tends to be easier to make judgement calls about what needs to be done.
For example, sometimes we might see potential waste in a project where a client wants to spend $10,000 worth of development time reinventing something that we can buy off the shelf for $500. But if we’re dealing with a CEO accustomed to using balance sheets and ROI to make decisions, then he or she will be in a better position to make the cost-effective choice.
By contrast, people a couple of levels down in the organization might approve the $10,000 spend in order to not rock the boat. And in fairness to them, they may be unable to pull certain levers and make certain decisions.
That’s why we prefer to work with a product owner who understands the full business from end to end, as well as the budgetary and speed-to-market implications of paying $500 for an off-the-shelf license.
What we’re really after is alignment. We like to be confident that the decisions we’re making at the code level align with your company’s best interests. We’ve seen situations where the true decision-maker, who was never present at meetings, shows up out of nowhere and decides to kill a half-finished project or do a major course correction.
This is very frustrating. We want to do good work for you at a good price, and any factor that unnecessarily inflates a project’s cost can, by no fault of our own, hurt our reputation. If you want to hire the best software developers and stay on budget, then please ensure that the ultimate decision-maker is a part of the process from the very beginning.
8 – Be as transparent as possible.
The best software developers find more fulfillment and happiness in projects that are moving in the right direction—at least to the degree that we can understand that direction.
We developers value transparency because we’re engineers and we like for things to make sense. But you may be contractually obligated to not disclose every detail and decision to your developer team.
So what does healthy compromise look like?
Trust goes both ways, and you will earn ours by inviting us into your decision-making process as much and as often as you can. Developers make dozens of micro-level decisions every day, so knowing the macro will help us help you. If we don’t know what stakeholders are thinking, we may lead the project the wrong way!
So bring us into your decision-making process at the macro level. Give us insight into your constraints and deciding factors. This enables us to plan better and to communicate more clearly with you in the future.
We may still disagree with your project-level decisions, but we’ll do our jobs. If that’s a direction you want to go and your organization has hashed everything out internally, we’ll get on board.
Final Thoughts
You and your developers have more in common than you might think. You both prefer to work with fair, reasonable people. You both prefer interesting projects.
We would love to build an amazing product for you, and the best way for you to be a good client for an agency is to give us a really long leash.