Design Agencies Are Fun, Development Teams Are Stressful

“Development contracts keep me awake at night. Design contracts don’t.”

Meet Alex. Those are her words. Alex is Product Manager with a large enterprise managing digital product development.

She has grown frustrated with a recurring problem. Design agencies consistently meet expectations — they are usually on time and within budget. But mobile app and web developers often fall short, exceeding both timelines and costs.

The Problem

Alex explains that design agencies have proven to be reliable partners. They consistently meet project deadlines and operate within budgetary constraints. Negotiating a Statement of Work is relatively easy — the hardest part is keeping up with new trends and buzzwords — but deliverables and timelines are often well understood. The vendors always have grand ideas and advocate for more money but can easily reign in their scope to accommodate Alex’s budget.

And throughout the contract, Alex gets to meet the whole team. They meet regularly with her to share insights from their interviews with users, they show beautiful mock-ups, they ask for her opinions, and discuss “the art of the possible” — Alex enjoys it immensely. And as the contract period comes to an end, Alex takes possession of a neatly organized folder of design assets and slide decks.

However, mobile app and web development firms pose a different challenge. During contract negotiations, they seem reluctant to make commitments around scope and timelines. High level agreement is often easily achieved (e.g., “we will build a retail inventory, shopping cart, and payment flow”) but, as Alex can tell you, the devil is in the details. Vendors have strategies to negotiate for flexible scope — they say things like “user stories can be updated at any time” or “the acceptance criteria for each feature will be determined after the contract is signed”. Their reluctance to define the scope in advance raises concerns for Alex. She’s the one accountable for the financial risks associated with the development process.

And throughout the contract, Alex rarely gets to meet the whole team. Many weeks pass before the vendor is willing to show working software. And when she finally does see the screens, they are partially functional (at best) and buggy. She is often told “more testing is needed” or “the team will need time to work on technical debt”. Before the contract period nears the end, the vendor’s account manager calls her to discuss a “warranty period” and to negotiate a “maintenance contract” — and it seems to Alex that the vendor is trying to buy more time to complete the desired features.

The Underlying Dichotomy

To unravel this discrepancy, we must understand the nature of the work carried out by designers and developers.

Creative work abides Parkinson’s Law: a principle that suggests work expands to fit the available time. For example, if you give yourself 1 week to draw a self-portrait, it will take 1 week. If you give yourself 1 minute, it will take 1 minute. The quality will differ but, in both cases, will meet expectations. You will rationalize the low fidelity of the latter drawing. “I only had 1 minute, so, I guess it’s pretty good.”

Alex’s experience with design agencies is proof of Parkinson’s Law. She requests a few deliverables, agrees to a market-driven price, and the results are satisfactory most of the time. Behind the scenes, the designers are able to work within clear boundaries with well-known and often re-usable design patterns — they are able to focus creative energy for the duration.

I’m not suggesting that design work is without pressure. It can be stressful for the designers (e.g., “writer’s block”, disputes about artistic direction, failed experiments, contradictory research outcomes) but Alex is easily sheltered from that.

On the other hand, the plight of software developers is entirely different. The intricate nature of the technology landscape, evolving requirements, and unforeseen technical challenges make precise estimation impossible — the crucial variables are always discovered during development (not during contract negotiation).

Unlike creative/design work that can expand or contract to fit the available time, development work often simply takes as long as it takes. And while developers ought to be challenged to produce the most direct implementation (to avoid the tendency to over-engineer or “gold-plate” everything), the teams cannot simply go faster or finish sooner. The time must expand to fit the work.

Strategies To Navigate Development Work

Alex’s encounters with design agencies and software developers highlight a stark contrast in their ability to meet pre-defined timelines and stay within budgetary constraints. By recognizing and understanding this divergence, we can employ appropriate strategies and navigate the problem with a clearer perspective.

In principle, those “better” strategies are founded on practices like:

• Deploy frequently.
• Demonstrate frequently.
• Test Driven Development.
• Develop a bias toward action.
• Keep quality high — avoid defects.
• Focus the development team(s) on small batches of requirements and ask them to deliver in increments.
• Welcome changing requirements even late in development — and write contracts that encourage collaboration and flexibility.

Disclaimer: The problems, experiences, and conversations are real. But Alex is not — she’s a fictional character combining attributes and circumstances of my past clients.