We just brought Tim Hatherley-Greene into RIVER. Tim's background is in innovation and change management, not design, not engineering. Some people might look at that hire and wonder why a technology company is bringing in someone whose expertise is in how organisations adopt change. That's exactly the point.
The Hiring Problem in Tech
The industry obsesses over technical skill. Can you write React? Do you know GraphQL? How many years of experience with AWS? These are the questions that dominate job ads and interviews. And they're necessary. But they're not sufficient.
We've worked with brilliant developers who couldn't explain a trade-off to a non-technical stakeholder. We've worked with talented designers who produced beautiful work that ignored every technical constraint. We've worked with project managers who could run a perfect sprint ceremony but couldn't tell you whether the project was actually going well.
Technical skill is the entry requirement. What makes someone effective on an enterprise project is everything else.
What We Hire For
The Ability to Work at the Boundary
Enterprise delivery happens at the boundary between technology and business. Between what's technically possible and what the organisation needs. Between what the system can do and what the user wants to do. The people who thrive in this work are comfortable at that boundary. They can translate between worlds.
A developer who can sit in a stakeholder meeting, understand the business problem being described, and translate it into technical options without jargon. A designer who understands why the database structure constrains the interface and can design within those constraints creatively rather than fighting them. A project lead who understands enough about the technology to know when a timeline estimate is realistic and enough about the business to know when a requirement is negotiable.
Outcome Orientation
We care more about outcomes than outputs. Did the thing we built solve the problem? Not: did we deliver the features in the backlog? These aren't the same question.
The people who do well at RIVER are the ones who ask "why?" before "how?" Why are we building this? What problem does it solve? Who benefits? When the answer isn't clear, they push for clarity before they start building. That saves more time than any technical optimisation.
Client Comfort
Every person at RIVER is client-facing at some point. Developers present their work. Designers explain their rationale. Project leads run the hard conversations about scope and timeline. If someone can't work directly with clients, constructively and professionally, they're in the wrong team.
This isn't about being charming. It's about being honest, clear, and comfortable with the vulnerability of showing work-in-progress and receiving feedback.
I'd rather have a developer who can explain trade-offs to a client than one who can solve a LeetCode problem in their sleep. You need people who can be in the room.
Isaac Rolfe
Managing Director
Why Tim
Tim brings something we didn't have: formal expertise in how organisations change. For seven years, we've been building great technology and assuming the organisation would figure out how to adopt it. Sometimes they did. Sometimes they didn't. And when they didn't, it wasn't because the technology was wrong. It was because the change wasn't managed.
Think about it from the user's perspective. You've been using a system for five years. You know its quirks. You have your workarounds. Then someone replaces it with something new. The new thing is better, objectively. But you didn't ask for it, you weren't involved in choosing it, and now you need to relearn your entire workflow while still doing your job.
That's a change management problem, not a technology problem. And it's one of the top reasons enterprise projects "fail" even when the technology works perfectly.
Tim's role at RIVER is to ensure that the human side of technology delivery gets the same rigour as the technical side. Stakeholder engagement strategies. Adoption planning. Training design. Resistance management. The work that determines whether a technically successful project becomes a business successful project.
Small Teams, High Standards
We keep the team small on purpose. At RIVER, everyone knows everyone. There's no layer of management between the person writing the code and the person making strategic decisions. That proximity creates accountability. You can't hide in a large team.
Small teams also mean we can be selective. We don't hire to fill seats. We hire when we find someone who raises the standard. That's slow. We've had roles open for months waiting for the right person. But the alternative - hiring to capacity and managing the quality implications - creates more problems than it solves.
The Integrated Model
Most agencies have departments. Design department. Development department. Project management department. Work flows between them like a relay race, with handoffs at each stage. We've never worked that way.
At RIVER, designers and developers sit together from day one. The designer understands the technical architecture. The developer understands the design intent. Decisions are made together, not passed between teams. This eliminates the "that's not what I designed" and "that's not technically feasible" conversations that plague departmental structures.
It's harder to manage. It requires people who are comfortable outside their lane. But it produces better work, faster.
The Standard
Our delivery record matters to us. Every project delivered. Every one. That record isn't an accident. It's the result of hiring people who care about outcomes, keeping the team small enough to maintain standards, and building a culture where honesty is valued more than optimism.
We're not perfect. No team is. But we're building something where the standard is high and the expectation is that everyone meets it. Every hire either reinforces that standard or dilutes it. That's why we take our time.