I recently read a piece from the June edition of ACM, Q&A with Erik Meijer, which I found quite apt as it speaks to my current situation at work. Whilst Meijer talks specifically to software projects, we can apply this to any kind of topic, be it personal or professional, work & life - everything we encounter when it comes to dealing with change & uncertainty (career, new teams, family, new projects, etc.).
This is especially relevant to the period I'm in now, a leader driving change - i.e. changes to the way we working, kicking-off a focused management war room, and the recent announcements around delivery priorities for the next three months. This is a large corporate, multi-million dollar industry, the amazing part is that things are so fast-paced and always changing that one can argue that the only constant in this company is one that of Change!
So we need to deal with this reality, it's not going to go away anytime soon. My experience is pretty much aligned to Meijer: try to manage the level of uncertainty (balanced by one's appetite for risk) as quickly as possible through communication & stakeholder engagement, converge on well-bounded known-knowns based on the information we receive, agree to execute & deliver within the binding time constraints. Add to this is a sense of measured calm and patience, start practising ways to control your default responses too...
Below is the excerpt of the Q&A:
What is your team process? How does work get done? How do you communicate status?
A lot of what you read about process and agile has very little evidence behind it. I don't believe a lot of process is scientific. Instead, I define general guidelines about what I want to see happen, and within those I don't care how things happen.
My thinking has two main sources of inspiration: the military and the hacker way.
Over thousands of years, armies have figured out how to get things done and achieve their goals in an environment that is really chaotic and unpredictable. That is the environment we live in as developers as well. If you read the U.S. Marine Corps Warfighting manual, and replace the word war with software, everything in there holds true.
So how do you deal with uncertainty? When people attempt to solve with process, they are trying to fight or control uncertainty. For example, someone can say just adopt zero inbox and your life will be awesome. In reality though, that isn't really the case.
One of the things I like about Facebook is "the hacker way". It is an approach to creating software that involves continuous improvement and feedback. It is about computational thinking: how do you program the system, and how do you make the system do things that no one thought possible?
Being agile is about communication.
The process needs to change with the situation. You have a big picture of where you want to go, but any plan or process will shatter immediately when you hit your first bug or something happens out of your control.
In most projects there are two phases: an exploratory phase and an execution phase. Your project should progress like a damped sine wave, where the amplitude gets smaller over time (see picture above). You have to figure out what to build, and figure out what question you are trying to answer. In the beginning you want to increase the vertical velocity to get the uncertainty under control, and then you want horizontal velocity to increase when you get into execution.
With prescriptive processes. people are looking for a silver bullet to solve problems, but it doesn't exist...the world is super-confusing, and you have to embrace it and work with it.