Putting Ideas in the Rock Tumbler
Making sure expectations are aligned
Earlier this week I was surprised to learn about a difference in expectations on a product capability I thought was well defined and well understood. I was wrong. There was a difference in understand the capability between people on the same planning team. Fortunately, implementation was still at a point where we can reset expectations without any damage to the product or organization. Most important, we could reset expectations without damaging egos. What follows is a summary of organizational collaboration, and steps taken to remediate the misunderstanding.
Delivering business value in large, complex software projects involves a lot of planning. In larger companies, there is organizational separation between planning and implementation. Product management is separated from software development. Product management works on strategy and planning. Software development implements the work defined by product management, feeding input back into the planning organization. A strategy and planning organization takes input from “the business”, however that is defined, and turns it into a prioritized roadmap. That roadmap is broken down into prioritized units of work. Those work units should break down into customer-facing deliverables, leading indicators, and release dates.
The planning organization works ahead of the development organization. Sometimes this feels like a long-form, highly-compensated game of telephone. Conversations happen and ideas are thrown over the wall to the next person. At each hop down the line, there is a chance ideas will be muddled. Two people may think they have the same idea because of the conversation. The participants use the same words, in seemingly the same ways, and both leave the conversation thinking they have the same outcome in mind. And then the wrong product is delivered after implementation. Whoops.
How do you arrive at the right outcome? Talk with people. Think about communication like putting rocks in a rock tumbler. With a rock tumbler, rough, jagged rocks in a variety of shapes and sizes go in, and weeks later smooth shiny rocks come out. Rocks in the tumbler apply pressure on the other rocks, bumping into them, knocking the rough edges off.
Pulling interested stakeholders together to get all the ideas and understandings out on the table is like putting rocks in the tumbler. Individually, our first ideas are rough and not fully formed. Talking about any software functionality is abstract by definition. Software projects are about defining behaviors. Humans judge each other by our behavior all the time. When something unexpected happens, people panic.
A good discussion pushes different perspectives against others. Putting pressure on ideas identifies the essence of an idea. The important points and the unimportant points become clear.
It’s important to point out that rocks out of a tumbler don’t look the same as when they went in. Openness is important when working in the idea rock tumbler. Holding professional or personal attachment to a particular idea down to its details is a bad idea. This is where we can take advantage of being lazy. What’s the problem with putting an idea on the table and letting others poke holes in it, try to lift if up with a lever, see where it holds and doesn’t hold, and then building on that idea. You’re on a team, let the team do their part of the work.
This doesn’t mean step back and watch. That’s disengaged, not lazy. Try to pull other ideas in to build a common solution with broad buy-in. People are more likely to agree with a plan, and promote it, when they have an ownership stake. The best polished ideas are those that draw from all of the ideas put into the tumbler. Keep talking, and then review, review, review with the team.
The world may have changed since the initial planning sessions. Set aside working sessions during the week to revisit plans as implementation time draws near. Planning orgs run out ahead of implementation orgs; months can pass between planning something and writing software to deliver it. The best laid plans may be irrelevant by the time development bandwidth can implement them. Don’t be afraid to revisit plans to challenge the underlying assumptions.
Stakeholders can be too close to an issue or idea to see the bigger picture. Planning sessions sometimes get too myopic. Sometimes people don’t understand what they don’t understand. People can be too busy to have the cognitive bandwidth to engage in the same discussion with the rest of the team. Don’t hold this against other people. We are all guilty of it. Be forgiving of assumptions and expectations. Other people aren’t the enemy. There is no place for finger pointing and blame. However, there is plenty of room for taking responsibility for a lack of understanding.
Taking responsibility is a big part of empowering others and making the room safe for others to take responsibility too. If people don’t take responsibility, don’t worry about it. You can’t control them anyway. But you, personally, can take responsibility. If your ideas are not understood by other people, the problem isn’t with them for not understanding, the problem is with us for not communicating clearly. Take the time to tell people what you’re thinking about. Ask for input. Figure out where an idea breaks down. Find the limits of the idea while planning rather than watch it fail in production. This is a collaborative exercise that needs other rough, jagged ideas to knock off the rough edges of our own. The outcome is a collection of smooth, polished ideas that have enthusiastic approval with a broad set of stakeholders.