Landing on client

 Whenever I talk to other project leads and consultancy managers one of the commonest topics is landing on client.

This is a key scenario for good communication, and there are a few hidden traps that are really easy to fall into. I've listed some of them below as an intro of what to watch out for.

I'm looking forward to learning about...

On the face of it, a phrase like this shows enthusiasm. The pitfall is that the client is paying for expertise, not for you to learn on their time.

Try phrases like "looking forward to seeing how you've implemented X", or "interested to understand your problem domain in more depth", or even just "looking forward to seeing where I can add some value".

I've only been with the company...

This is a bit context dependent. It's fine if you've been with your firm a few months, but if you've literally just started a week ago and are landing straight on client... maybe best not mention it. Say "I joined fairly recently" or something like that, leave enough room for the client to interpret it as "I've done some training and demonstrated my competence a bit". The most important impression we can give as consultants is established competence, and admitting to being a noob doesn't build confidence.

If you have no experience at all

This is a situation we see sometimes where new grads are landing on their first client. You can avoid the question of experience just by talking about what you're interested in (as long as it's relevant to their problem or tech of course!) rather than what you've done. Simply don't bring the subject of experience up if it's going to be a hard thing to talk about. This is a lot easier if you're not the first one to speak - plan ahead and talk to your team mates.

Errr....

You are almost certainly going to be asked to introduce yourself. Have a short pitch prepared, just 1-2 minutes about your history/experience/interests. Try to make it as relevant as possible to the job you're there to do. Ideally add in a tiny bit about who you are outside of work, but the balance needs to be about your experience and credentials. Prepare this before your first day!

If you don't have much experience in the client's stack/domain, try to lean on the things that are as relevant or transferable as possible.

Conversely, there are some things that are really useful to do in your first day or two:

Learn who's who

Make some notes about the people you've talked to, what their jobs are and what they are interested in. Be very careful not to make a written note of anything negative - if there's anything like that, just keep it in your head.

Make some tentative plans

What do you want to achieve while you're here? Who can help you? What are your first impressions of the client? You'll soon be neck deep in project work, so take this time to get your plans in order.

Summary

First impressions are notoriously persistent. Think about what impression you want the client to get of you. Talk to your project leadership about what meetings are happening, and what to say/not to say.

Business development

"Everyone fights, no one quits. If you don't do your job I'll shoot you myself"**.

Starship Troopers - Robert A Heinlein.

Communication - the basics of "how"

If we think about Pareto's Law in communication skills, the 80% is covered by two really crucial concerns: narratives; and adapting to an audience. Let's take the second one first.

Understanding your audience

The starting point for any communication is to understand what your target audience will actually get from what you're saying. The classic mistake here is to go into a lot of technical detail with a non-technical audience, but we can go a lot further than that.

For any meeting where you're speaking, think about who is there and what their jobs are. Get to know people and learn about what interests them.

Communicating in narratives

Terry Pratchett once said that our species should be called "Pan Narrens" - the storytelling ape. We think in terms of narratives, with start, middle and end. Our narratives can survive for thousands of years by retelling, and a memorable narrative needs structure.

Knowing that, we can structure our own communications with narrative form. Start by setting the scene and providing context. Then go on to talk about whatever is your topic. Finally, leave your audience with a conclusion (they won't remember more than 3 points normally, so try to keep your conclusion pithy).

Keep those two rules in mind - "what story am I telling?" and "what is my audience interested in?" and your message will land well and be remembered.

Communication - the 'why'

Everything that software and IT systems do is fundamentally communication, and equally everything we do as consultants is communication of some sort too.

Everything that we do as tech workers (whether we’re analysts, devs UXers, delivery or anything else) is based around communication. That’s obvious for most of the roles - we’re about talking to clients after all. But even when we’re actively writing code we’re still all about communication.

• Software is the medium by which clients communicate with their customers
• Source code is nothing more than the most rigorous possible description of the client’s business process
• Software is built by teams, working together, communicating with each other and with stakeholders
• Source code is a message that the next maintainer needs to understand
• We can’t write code until we understand what’s needed (then we need to check that’s what we’ve created)

Consultancy is communication. We are working with new people and new teams all the time. We have to know how to settle in quickly in a new environment, learn about our new co-workers and build trusting relationships with them. We are bringing new ideas from outside, and learning about how the existing teams do things - that means understanding and communicating empathically.

Career development is built on communication. All the tech skills in the world mean nothing if no one knows you have them. To build credibility you need to not only know how to do the work, but how to communicate to people that you have that knowledge.

In the next post I'll start to talk about what we can do to improve our communication and ensure our message gets across.

Pragmatism

pragmatism

noun [ U ]

UK 

 /ˈpræɡ.mə.tɪ.zəm/ US 

 /ˈpræɡ.mə.tɪ.zəm/

the quality of dealing with a problem in a sensible way that suits the conditions that really exist, rather than following fixed theories, ideas, or rules:

The council has operated much more effectively since pragmatism replaced political dogma.

(Source: https://dictionary.cambridge.org/dictionary/english/pragmatism)

Problem space partitioning

When I started to write about problem solving, one of the first things I talked about was isolating a problem by breaking the problem space down into smaller pieces. As I talked about this with people, I started to realise that intuitively knowing where the boundaries are in the problem is an important component of problem solving skill. So I started to think about how I know where the boundaries are, and how I learned to identify them.

Problem solving basics

 Problem solving is fundamental to all the work we do, but it’s not a skill that’s taught or talked about explicitly all that much. This can be a major barrier for people in their day to day work, and also in their career development. I want to address that a little by talking through some classes of problem, and problem solving techniques and strategies.