Spend 2 hours discussing, make the wrong decision anyway 

It can be hard to detect when a meeting is unproductive, especially when others share the illusion. You gained nothing from it. However, there is a good chance that someone in that meeting feels like that time was well spent. Your time had unfortunately been wasted.  

Allow me to illustrate. 

What makes code the way it is

Any organization that designs a system […] will produce a design whose structure is a copy of the organization’s communication structure. 

Melvin E. Conway (Conway’s Law)

This is simple: if we have a problem, then a program is a set of instructions to the computer that tell it what to calculate, to solve our problem. 

But, we all know that code is abstract and full of patterns and idioms that are mostly concerned with how we, humans, understand that code. Our entire systems are reflections of the organizations we work in and our business processes.  

In other words, the shape of the problem is not the only thing that dictates the shape of the solution. 

What’s more important for this topic is that different people often have different ideas about what our system is and what it should be. 

The projects we work on

I’m sure you’ve met with problems that are easy to describe and talk about, but the code that implements that supposedly simple solution is completely incomprehensible and unmaintainable. 

I once worked on a project that had gone through the 9 Circles of Hell you might be familiar with:

• Unclear concept
• Developers unfamiliar with the domain
• Experimental solutions to unfamiliar problems
• Changing requirements
• Scope creep
• Tough deadlines
• Hacks upon hacks
• Tech debt
• Changing team members

Basically, we’ve built a boat… 

…but the boat was supposed to be a Zeppelin for a while, but then we figured it needs big tractor tires. And also a rocket engine just in case. 

The “obvious” “solution” is to strip away all the cruft and make the boat be the way an actual boat should be. Unfortunately, you can’t just wish a change like that into existence. The boat should be a boat, but right now, it isn’t one.  

Navigating the Sea of Requirements

Every few weeks, an unexpected issue or an urgent new requirement pops up. These require us to make course corrections, which is sometimes hard to do, because turning the rudder requires editing complex SQL procedures, while maintaining backwards compatibility. 

When the system is this complicated, sometimes the only thing keeping the boat from capsizing is a well-balanced stack of bricks on the top of the mast. When making changes, even if you make an effort to balance the boat in a better way, you still have to be really careful when removing those bricks. Otherwise, a barrage of previously valid, but now malformed requests might start hitting some REST endpoint, producing useless logs. Now you’ve got a whole bunch of leaking holes to plug, and your carpets (traffic metrics) are ruined. 

Of course, we are really careful. We practice code review and write lots of tests. We make sure we discuss important changes thoroughly. We include all the stakeholders and seek external advice. 

But there is a sneaky issue, a fog preventing us from communicating effectively, but making us feel like we are. 

There is simply too much to handle. 

1. No single person knows how everything on the boat works. 
2. No individual can monitor and coordinate everyone’s work. 
3. No one can keep track of all the changes everyone does. 
4. Changing one thing almost always affects something else unpredictably. 
5. When everyone has their own limited perspective on the boat and its course, we often talk about different things, using the same words. 

Differing perspectives

Extending our sailing analogy, let’s imagine a new requirement pops up: we have to go around an Iceberg. We schedule a meeting to decide on how to proceed. All the relevant people are invited: 

• The Project Manager (they ultimately decide on where we’re going) 
• All 6 developers (less chance of forgetting something) 
• 3 Support Specialists (they have to answer questions from users) 
• The Iceberg Committee (it’s their Iceberg, after all) 

Here is how everyone sees the problem and their solutions: 

The Project Manager

Believes they are captaining a proper boat. It’s got some weird, but minor issues. 

    Simply steer, send a signal to the Iceberg’s API, realign with the destination. 

The developers

Each has their own idea on how the boat should look. Each one is aware of different issues and strange dependencies on the boat. Only one knows that steering left isn’t working since the last release (this isn’t a big deal because our destination is moving to the right anyway). 

Steer right, take care that the bricks don’t fall from the mast, then carefully readjust everything to continue straight to the destination. 

The Support Specialists

Still putting out fires from last week. They don’t want to be here, but have to be better prepared for the next incident. 

They don’t care if the boat has to fly, just don’t hit that Iceberg, please. 

The Iceberg Committee

For them, this is just another Tuesday. They have a solid, time-proven API with great documentation and no one has any issue registering with it. 

They will provide documentation and claim they are here for any questions. They won’t actually respond because “just read the docs” and they have more important things to do. 

Communication breakdown

 Imagine a timeline of the meeting: 

• Alice suggests turning right. 
• The devs discuss for a bit and figure it’s nothing they can’t solve. 
• The PM mentions in passing that the boat needs to ping the Iceberg’s API. 
• Bob remembers the tractor tires on the side of the boat. It is not clear where to fit the REST cannon. 
• The PM suggests going left. This confuses the devs since they thought our goal was to the right. 
• Alice suddenly remembers that the boat can’t turn left. 
• Now the discussion turns to this problem. Why? Can it be fixed? 
• The devs try to decide whether they have time to fix this. 
• The PM thinks outside the box and suggest they fly over, like a blimp. The discussion shifts again. 
• The team gives another shot to the idea of going right. 
• They go more in depth about building the REST cannon. 
• One dev still has questions about flying over; he still thinks it’s a viable idea. 
• The PM likes the sound of it. 

By the time the team gets back to discussing going right, everyone had already forgotten the reasons they don’t have time to make it work. 

After rehashing all the ideas a few more times, rediscovering problems three times over, they settle on going left. 

The aftermath

Only when someone started working on the task do they remember they don’t have time to fix turning left. They quickly re-plan the tasks to go right. 

But alas, no one remembered to tie up the bricks. 

In the end, after two hours of discussions, the team made the same decision they could have made in five minutes, including the same oversights. 

Some members believe the discussion went great because a lot of ideas had been shared and that the problem is how badly the tasks were written. 

Other members think that the discussion was worth it, even though it was a mess. They think it would have turned out even worse with less “planning”. 

To the Support Specialists: this meeting could have been an email. 

Dispelling the illusion

There are multiple reasons why someone might feel this meeting had been useful. Perhaps even necessary. You may have even learned some things.  

Even if the meeting had been a net positive, could you have learned more by working on something or by asking directed questions? 

The sneakiest illusion might be hidden by the fact that some decision was made. Some progress was made. Something exists after the meeting, that hadn’t existed before. In reality, even more progress may have been made if the meeting hadn’t occurred at all. 

Managing discourse

Sharing ideas about a complex system is complex in itself. The meeting was unproductive because we didn’t approach it in a structured manner. Aside from practicing communicating in an effective and exact manner, I have an actionable suggestion: 

Consider creating a persistent, authoritative document that describes your project. I can’t tell you exactly how it should look, but it’s important that it is continuously referenced and updated, in every discussion. 

All tasks and meeting notes should reference this single source of truth. It should serve as a force that pulls every discussion towards facts and keep everyone on the same page (as much as possible). 

Instead of a conclusion… 

…remember that the key is recognizing when discussions become unproductive. Discussions about complex systems should be structured and lead to verifiable conclusions. 

Remember, this is hard. It’s hard to notice when you, yourself are not communicating effectively, so don’t forget to be kind to others. 

We don’t need to be perfect, but we can do better.