Are you a flow function or a control function?
Summary
Some teams exist to deliver value. Others enforce control. Some others, sit right in the middle. What kind of team are you?
Imagine you’re a product manager. You want to send out an announcement to the rest of the company about a significant capability you’re releasing. You write an engaging note, throw in a video demo, and add a call-to-action, so other teams can muck around with these new features and reach out to you to learn more. But before you send out the note, you need a sign-off from corporate communications.
It takes you a couple of weeks to complete the back-and-forth with the comms team. They dot your is and cross your ts for you. They tell you that the little joke you wrote isn’t in line with your brand voice. You have to redo the video, because you forgot to add the copyright year and the trademark symbols in the right places, and look, you also got a few brand colours wrong. They don’t mind the call-to-action, but they don’t want you to seem like you’re creating extra work for others, so they ask you to rephrase that bit as well.
By the time you’re ready to send out that note, the features aren’t new anymore. There’s no cause for celebration. Your brilliant colleagues have already been playing with the latest enhancements. Your note could well go into the virtual shredder.
In this, obviously imaginary, but oft-real story, did the comms team enable comms, or impede comms? Were they making messages flow, or controlling them? The difference between flow and control is a matter of team design, culture and mindset.
It isn’t more noble to be a flow function over a control function. Sometimes the distinctions are clear. Engineering is most often a flow function because its job is to deliver functionality. Security, ethics and governance, on the other hand, are control functions. At times, their job may seem at odds with engineering, but their value is in preventing downstream problems that could erode the value that engineering delivers.
| Flow function | Control function | |
|---|---|---|
| Primary goal | Deliver value/functionality | Prevent risk and downstream value erosion |
| Typical examples | Engineering, product, design | Security, legal, governance |
| Team mindset | “How do we ship this?” | “Is this safe/ compliant?” |
Sometimes, the distinctions aren’t as cut and dry. Most cross-functional engineering teams have quality assurance analysts. Is quality assurance about flow, or control? I argue they’re both. The best quality assurance shifts left, or upstream in the development process, so they don’t bottleneck delivery at the wee end. That said, some testing is inevitably downstream because defects are sneaky creatures – they slip through the best laid guardrails. All this said, most QAs think of themselves as flow-enablers, not controllers.
So, where am I going with this? Well, if you lead a team and collaborate with other teams, I encourage you to revisit your team’s mindset through the lens of flow and control. On the spectrum of enabling flow versus enforcing control, where do you sit? Answering that question will tell you when you must get out of the way and let people do their jobs, and where you must swoop in to ensure that things don’t go out of hand. And hey, if anything, asking yourself this tricky question will help you figure out how to help yourself and your collaborators be more agile. Isn’t that a worthy outcome?