Between the fee earners and the technical team: turning what people say into work that gets done

Lost in translation

Fee earners and technical teams are rarely short of goodwill. What they are short of is a shared language. A fee earner says the system is slow, the case and matter management screens are confusing or the reports are wrong. The technical team asks: slow doing what, confusing where, wrong compared with what? The conversation stalls, the fee earner builds a workaround, and the problem disappears from view while it keeps costing time.

It works the other way too. “We are upgrading the database server on Saturday” means nothing to a conveyancer. “Save your work by five on Friday; on Monday searches will run faster” does.

In our experience the firms that get most from their systems have someone, formally or not, whose job is to translate in both directions. The rest of this article is how to do that well, whoever does it.

The four-line request

Ask anyone raising a problem to answer four questions. It takes a minute and changes the conversation.

1. What were you trying to do? “Record a call on a matter while the client was still on the phone.”
2. What happened? “Four screens and about two minutes, so I wrote it on a pad and typed it up later.”
3. How often? “Ten times a day, and the rest of the team does the same.”
4. What would good look like? “Under thirty seconds, from the email I am already in.”

Now it is not a complaint. It is a problem with a size. A team of eight, ten calls a day each, ninety seconds lost on every call, is two hours a day, or around 450 hours a year. That is something a technical team can prioritise, fix and prove it fixed. It may also turn out to be a training point rather than a system change, which is the quickest fix of all.

The four lines also stop requests being written as solutions. “We need a new button” is a guess at the answer. “It takes four screens to record a call” lets the people who know the system find the best one, often something it can already do.

AT A GLANCE

From “it doesn’t work” to “it’s fixed”

Five steps that turn what people say into work the technical team can deliver.

1. 1

   Hear

   One front door for every request and idea, from anyone in the firm.

   Nothing lost in an inbox

2. 2

   Translate

   Four lines: what you were doing, what happened, how often, what good looks like.

   A problem with a size

3. 3

   Prioritise

   Value, effort and risk, scored together and the list published.

   Decisions people understand

4. 4

   Deliver

   The technical team builds; the team who asked tests it on real work.

   Fixes that fit the work

5. 5

   Reply and credit

   An answer on every item, and the person who raised it named.

   People keep raising things

One front door

Requests and ideas arrive by email, in corridors, in partners’ meetings and through whoever happens to sit near the IT team. Each route has its own memory, and most of them forget. Give the firm one simple place for any request or idea, from anyone, and use the four lines as its form. Support tickets can stay where they are for things that are broken; the front door is for “this could be better”.

Prioritise in the open

Once a month, the people who run operations and technology look at everything that has come in, together. Score each item on three things: the value to clients, colleagues and the firm (the four lines give you the size), the effort, and the risk. Then publish the list, so people can see where their item sits and why.

Open priorities do two things. They make decisions easier to accept, because people can see the reasoning. And they protect the technical team from whoever shouts loudest, so it can spend its time on the changes that matter most.

Reply to everything

The fastest way to stop people raising ideas is to ignore them. Every item gets an answer within the month: yes (and roughly when), not now (and why), or no (and why). “No, because” is far better than silence; people accept a reason far more readily than a gap.

When something goes live, name the person who raised it. In a firm owned by its people, or any firm that wants its people to care, that credit is worth more than the fix.

Translate the other way

Every change the technical team makes should reach the people it affects in their terms: what changes for you, when, and what you need to do. Three lines, sent by someone they know, beat a release note nobody reads. For bigger changes, ask a respected person in each team to test it on real work first; they will spot what a test script misses, and their colleagues will trust their view.

Start this month

Put the four lines on a simple form, tell the firm it is the one place for ideas and frustrations, and hold the first monthly review with the technical team. Reply to every item, publish the top five, and deliver one of them quickly with the person who raised it. None of this needs new software.

It pairs with building workflows around the results each team needs and the first 90 days after go-live. Our free workflow capture tool helps when a request turns out to be about a whole process rather than one screen.

We help firms set up the link between the people who do the work and the people who run the systems, so improvements land and keep coming.

If you think anything here is out of date, please tell us and we will correct it.