So you started a new role

Some thoughts on getting started

Sep 27, 2024

Starting a new role or project can be tricky, whether you are a leader or a do-er then starting somewhere brand new is bound to get butterflies going in your stomach. As a consultant I've started a number of roles unfamiliar with the organisation and project and so I wanted to share some thoughts on how you can start and hit the ground quickly. This isn't a comprehensive list of ideas or approaches, it's more a few random thoughts.

The Big List of Questions (BLoQ)

There's no shame in starting a project or role and not knowing the lay of the land. Why is it then that when we start we almost feel apologetic about not knowing enough? People know the acronyms, they know how things work so well that they take it for granted. What's left for you to piece together is a jigsaw puzzle of information and you've not been given the picture on the box.

In the past my approach has been to assume the answers will come with time. I'll ask questions at the right points in meetings but generally my assumption has been that people know what I'll need to understand and through the initial project meetings I'll gradually get answers and become clearer on where things lie. However things rarely work out that way, and things take time. Knowledge is assumed, or missed, and without realising it you can be left with big knowledge gaps. As such you remain unsure if the knowledge gap is yours, or if it's a blind spot in the project.

This is where you can use the Big List of Questions to great effect to help on two fronts. Firstly, the BLoQ assists you with your own organisation and fact finding. It lays down everything you want to know and keeps you sane. Secondly, when you share it with people, it helps them understand right up front what you're trying to understand and where your knowledge is at. You also create a shared understanding of the gaps.

Let's get more precise with an example. I recently started a transformation project, I'd not been working with the organisation long and I didn't have a lot of background. The data portion of the project was just kicking off but some of the team had started long before me on other aspects of the project. I'd been invited to Daily Sprints but beyond some rough background I didn't have a lot of details. I set up a meeting with the lead Business Analyst on the project and the day before I laid out every question I could think of, first some standard questions:

Timelines - what were the existing timelines and expectations, when might any POC and Go Live be expected?

Existing work - what was already done of the data aspects, who'd worked on it?

A KDD had been written on the high level data architecture, what was the approval process for this, who had seen it, when would a decision be made, how?

What's the standard project process - gateways, approvals documentation, etc

Who's who on the project team? Who are the steering board?

How is the project resourcing expected to change over time?

Then I dived into detail focusing on the each area of the project, any integrations, the legacy features, things I needed to know more about, etc.

My questions ran into three pages under various headings. It was a lot of questions! I sent it to the BA before the meeting to give her a heads up, and set the expectation I wasn't expecting her to answer everything but I wanted to help her understand where I was at. I also shared it with key members of the Data Engineering Team with a longer tenure to ask them if they had any questions I wasn't asking.

The reaction was very positive. The Data Engineering Lead came back explaining this was exactly what they needed to know too, and they'd love the answers. The BA, far from being frustrated by my simple questions, set about answering with relish. The questions gave us a great foundation for the discussion. We only got perhaps half way through the answers in our meeting, but it was really helpful for us both.

The answers fell into three types:

an immediate, clear answer to the question
an immediate, clear acknowledgement that there was no decision or clear path to understanding the answer at this stage
"it's complicated"

I was therefore able to very quickly sift through what was known and what wasn't.

Without getting all Donald Rumsfeld....

the Known Knowns (i.e. facts)
the Known Unknowns (i.e. things that the project team knew they needed to find out)
the Unknown Knowns (pieces of information I could help bring to the project)
the Unknown Unknowns (things we didn't know we'd missed - obviously we needed exploration to find these)

The BLoQ sits there with my notes on it, covering most of the questions now. Some answers remain blank and its these that I focus on finding answers to from the project team. I add more questions as time goes by too, just to map my knowledge.

As the project expands the document will also act as a great tool to bring them on board. "You’ve probably got questions, I did...here's some answers".

The BLoQ is not only a very empowering mechanism to quickly build up capabilities and knowledge, but it also gives people confidence in you. Walking in with a great big list of questions makes people sit up and take notice; "this guy knows what he needs to know, and he's very quickly identified all the things I've been saying have been missed up to this point".

Are you a fan of the BLoQ? Please let me know if you've other ways of quickly getting up to speed.

Find your Claire

Every organisation has a Claire*. Someone who's been around since the early days. Whether that's twenty years or five they have the history on why things are like they are. They've probably worked in several roles in the organisation and know everyone.

*Your Claire obviously won't be called Claire

I think it was my second day when I met Claire in my current role, it was immediately useful because knowing her background I can quickly ask any questions if I can't find the background. When I first arrived at the office and couldn't find a hot desk, Claire helped. When I needed some documentation from a project a couple of years ago, Claire helped track it down. Claire knew the people to ask and helped point me in the right direction for several queries.

So quickly find your Claire at your next organisation and it'll make your life a lot easier as you try to join dots.

As a leader get involved

This is perhaps a controversial view but I'm a big proponent of joining a team and getting stuck in. I guess to a point this is just Servant Leadership, but I think it's important as we understand the stressors and pressures in teams to spend time getting stuck into the nitty gritty of their day to day.

I’ve seen teams complain about admin overheads, and processes that drain their time. As a leader the only way you can understand those painpoints and whether they are genuine is to get stuck in and work through the process end to end, like the team. Understand their pain.

Similarly with data processes, dig into the lifecycle of a project, the documentation. What's done when and where. How are things promoted and checked?

Getting stuck into the detail is essential if we're to understand the bigger picture.

Quick Wins (but not too quick)

Obviously it's great to make an impact and look for quick wins as you start somewhere, however the temptation to start solutionising from day one should be avoided where possible. Observing and working with the team is much more important.

This is especially true when bringing in tools or ideas from previous roles. There can be a temptation to preconceive solutions well before you've started and immediately launch into them. Personally I don't think this approach serves anyone too well. Existing team members can feel alienated and ignored, there may be good reasons certain tools and approaches won't work, right from people through to process.

That said do make hay while the sun shines, your first few months are the time when no questions are too stupid, where you've not got so ingrained in the culture that you become part of the furniture and your inner voice pipes up "but" every time you consider a change. That time is precious and those small quick wins (implemented after a few months) will help bring about more considered change in the long term.

There's a wider discussion here on the Data Leaders Collaborative on the first 90 days as a leader that nicely expands in more detail on some of these points:

https://www.dataleadershipcollaborative.com/

I'd love to know your thoughts on fact finding techniques, how you settle in to a new role and whether anything I've written here resonates.

Love Data, Love Growth

Discussion about this post