We have a very large project happening at work right now - it's actually been underway for over half a year. Still - I noticed how hard communication haed been around the project for months.

Teams outside engineering would (reasonably) ask when they needed to deliver something we need, and I had a hard time coming up with an answer. We would end up just staring at each other, trying to be helpful.

This led to the project seeming kind of 'stuck' - no one knew what was supposed to happen next, and it was impossible to put deadlines on anything.

If you feel like this is happening to you on your project, you can try what helped me to navigate the fog:

• First, get away from your normal workspace
• Take some time to think
• Question everything
• Specifically think about how you are breaking the project down in terms of communication
• If you need to change how a project is framed, have the courage to suggest the change to others - even if it means walking back a way that you were originally working

I got up from my desk, went to another room with only a notebook and pen, found a comfortable chair, and settled in for an hour and half to think and write. Was this a lot of time to spend on this? Yes, but I also think it was time I spent now to avoid spending a lot of wasted time later. I thought a lot about how I was communicating, and what other teams were asking for.

In our case, we have a large React project, and as such we engineers were thinking about the work in terms of components. React sort of enforces that habit.

However, no one else was talking about the project in that way. It led to a lot of confusion. It's like a carpenter talking to an architect about how to build a house, and talking in terms of the length of pieces of lumber. (@TODO come up with a better analogy.)

As the engineering leader, I had been the one driving the conversations from the viewpoint of components. I had to take a step back, and approch the situation with humility. What made more sense?

In our case, since we're building a site with many pages, I proposed that instead we break the work down by page. That is, in terms of how we 'bucket' the work, and discuss it. This then allowed us to establish an order of pages that we would build.

That last point was crucial. The actual order didn't truly matter - it was arbitrary. But it at least gave some semblance of order and structure. This way all the teams knew what was being worked on now and what was coming next.

It's still early days for this new way of organizing the work - I'll come back here and do a post on how it went. But already there seems to be less confusion and more focus.

So, if you find yourself in the middle of a project that seems to be stuck, in a swirl, and having a hard time moving forward - take a step back. How is the work being organized? Is there a better way? And have the courage to change.