LET US FLOW

PIAI: Flow Teams — Starting, Maturing, Nurturing Flow Teams

updated — 20240915

Experiment Box
(main post begins below this grey box)

For those who are aural learners, Google’s NotebookLM was used to auto-generate a podcast from this post. All I submitted is the URL for this post. No additional “human instruction”. Enjoy.

https://notebooklm.google.com/notebook/8867fb14-33e5-4248-a826-27aac91771a2/audio

INTRODUCTION

In “Building a Lifeline” we introduced the Concepts, Capabilities, Connectors, Constructions (C4M) diagrammatic for product road mapping .

We now introduce the team culture and associated dynamics that enable collaborative processes like C4M to align multiple facets of an analytical product team into one.

In this post we will introduce :

• Dual origins of the Flow Team Concept in psychology and in agile methodology.

• Purpose of Flow Teams

• The 4 Agreements that create a Flow Team

• Different Routes to becoming a Flow Team

• Analytical Flow Team Capabilities Model; expanding capabilities from those suitable for Analyst focussed teams to scaled real time MLOPs systems.

• Unblocking Flow Teams — a few suggestions as to the ways flow in teams can be blocked.

Future posts will cover each of these items in more detail

Analytical product teams need to align very different perspectives on “product” and bridge highly specialized training amongst team members. Every team is a different mix of training, talent and perspectives. The challenge is to apply what you have experienced in prof teams, what you have read (here and elsewhere) to the analytical product team you are currently on. You may be the team Tech lead, the PO or PM, the Team Manager; you may lead by example in the area of your expertise, or are just starting and are here to learn from the ground up. Consider the ideas here (and in every other work on team dynamics) as suggestions that require field testing and modification in situ; adapted via your own critical judgement and sensitivity. The suggestions come from patterns observed across teams; but they are just starting points for your teams internal problem solving. You and the team you are on will co-decide the beginning, middle, and end of your unique trajectory. Your teams specific decisions fold around your unique problem set, the tapestry of individuals you work with, your co teams, and your management leadership. Like the crystal lattice of a snowflake, each team is unique in its shape and trajectory.

ORIGIN OF FLOW

Every team has its moments of Flow. When things just come together — like a shared smile. And every team has its tensions; it’s moments of stuckness, when everyone is just grinding through. In Flow, time disappears, you catch each other’s thoughts, words tangle into sketches. Your very different talents and sensibilities become one. Flow occurs in Pair Programming, in Design sessions, in Debugging and Root cause team dissections, in falling into a new UI. Occasionally even in meetings that suddenly stop feeling like a meeting and feel like learning, working and deciding together … those meetings where voices, perspectives, ideas come together and build on each other with palpable.

This is the psychological state of flow. A research area founded by psychologist Mihaly Csikszentmihalyi.

(https://doodles.google/doodle/mihaly-csikszentmihalyis-89th-birthday/)

Flow is also an “Operating Model” for agile teams developed by Finn Goulding and Haydn Shaughnessy, an agile anti-methodology strongly influenced by both KanBan and DevOps.

(https://www.cxotalk.com/bio/fin-goulding-international-cio-aviva)

(https://robllewellyn.com/haydn-shaughnessy-interviewed/)

Finn Goulding provides a nice summary in the article “Flow is for Everyone, Agile is Not”:

“In Flow, we have pioneered the idea of flexible tools that let people interact in intelligent ways. We don’t have a rule book or a playbook for the end-to-end flow of value. We’ve always said, good social interaction leads to good decisions at work. And we are all for good social interaction and against rigidity. Flow is a naturally agile way to work.”

(https://medium.com/flow-the-new-agile-framework/flow-is-for-everyone-agile-is-not-f0a074eef6f8)

Within the Flow Team concept, as developed by Shaugnessy and Goulding there are three things Leaders must nurture to enable Flow Teams:

• Trust. Nurture high trust.

• Permission. Provide permission to experiment and work outside job descriptions. “In Flow, we want everyone to work in each other’s shoes. Let’s all code, test, deploy, harness customer feedback and stuff the job description.” (Finn Goulding, “The Minimalist Framework for Agile”)

• Unblocking. Remove or minimize tendencies to over(manage, document, govern) so the focus is on building the product together.

PURPOSE OF FLOW TEAMS

Flow Teams exists to speed the double loop from innovation to product, to continuously increase Product Velocity. A Flow Team has all the resources to cycle through from ideation to go-to-market. This will feel odd to organizations where these functions exist in different organizational hierarchies. A Flow team cross-cuts those hierarchies; becoming a point of integration. Flow teams bring together multiple perspectives (subject matter expertise, product, tech, analytics, marketting) so they are embodied in the product from beginning to end; rather than at a particular insertion sequence in the product lifecycle. Flow teams may be started (or other teams dynamics converted to flow teams) via hiring, acquisitions, and transitioning of current teams in place. 

4 AGREEMENTS TO FLOW

“To establish a place of work where engineers can feel the joy of technological innovation, be aware of their mission to society, and work to their heart’s content.”

    ⁃    Masaru  Ibuka, co-founder of Sony in his mission statement of “Purposes of Incorporation”

Creative people want to create: products, software, UX, go to market plans, strategies. Flow Teams exist to synchronize and focus innate creativity. Flow Teams are an evolving journey. The path into them can start at many stages. DevOps principles and mentorship are often critical in guiding analytical teams through these stages. But the most important component are a small set of shared commitments, mutually agreed to and freely given.

Starting an Analytical Flow Team requires a small set of commitments that are made amongst all team members:

• Multistack: commit to being multi-stack (everyone plays multiple roles as required to get a product to release)

• Innovative: commit to innovation (which requires experimentation, and a willingness to trade efficiency for resilience).

• Resilient: commit to uncertainty (i.e. having the confidence to figure everything else out that is needed for release; including methodology, products, development practices, go-to-market, the ultimate skill sets the team needs, etc).

• Continuous Improvement: commit to continual measured improvement (the performance ratchet, and the data driven evidence your flow velocity is increasing).

The team can mutually decide other commitments; but these four are minimally required.

These four commitments define flow teams. They are all that are needed to start an Analytical Flow Team. Everything else can be figured out on the journey.

The leadership elements cited by Goulding/Shaugnessy — Trust, Permission, Unblocking definitely accelerate the progress towards Flow; but it is the commitments the team as a whole must make either tacitly or explicitly that afford the cohesion required for flow. A Lead or a Manager can’t demand Flow; they can enable the trust and unblocking necessary to permit it. Too few commitments are insufficient to bind into flow. To many committments bring rigidity. Seek 4-7 commitments that define you as a team. Your flow commitments will not be exactly the same as another Flow Team. You have different membership, different challenges, a different product; your committments will flow around and bind these elements. One size, one set — does not fit all.

LET US FLOW

Past the 4 commitments to establish a Flow Team, the supports needed by a Flow team depend largely on their origins, the product challenges faced, as well as the nature of the organization your team finds itself in.

Flow teams can originate from an acquisition, through hires, or through lateral transfers across existing teams. Flow Teams with Tech origins will often require SME and Product support up front. Flow Teams with Product and Analytical origins will often require Engineering support (SE & DE) asap. In either case it is not a matter of throwing a specialist on the team, but bringing a capability into the team that is shared across multistack team members. Shared understanding of other team members strengths, and how to combine strengths is critical.

In larger companies, Flow teams originating from Acquisitions need strong support on cultural norms in the organization. Additionally, depending on organization, an acquired team may have started out with either stronger Tech focus, or Product focus, or Service/Consultancy focus and there will be a need to balance out across these three differing perspectives. Lateral transfers into an Acquired team are very helpful in organically bringing in cultural norms. Lateral transfers out of an Acquired team in the first year post-acquisition are Not Recommended, as they are likely to prove stressful to all involved. Once an Acquired team has made the 4 Flow Commitments and adopted cultural norms, lateral transfers requests into other teams should be supported. This is how we  rapidly transfer the new ideas, attitudes, and technologies coming in from an acquisition. Startups often begin with a previously established team and their historical committments, or a newly hired team that must develop flow quickly.

In larger organizations, new hires should start on established Flow Teams and should provide multi-stack balance to the current team. In the interviewing process for new hires there should be questions that test an applicant’s ability to make the 4 commitments.

Lateral transfers are critical for cross-pollinating ideas across Flow Teams and to support Cross-Training across connected Flow Teams (upstream and downstream) so multiple teams act in synchrony. Wherever possible they should be initiated by Flow Team members themselves; facilitated by HR to match people seeking growth through lateral transfers with appropriate opportunities, and via providing the training required to meet those opportunities.

Agile Methodology

It does not really matter which methodology a Flow Team originally has (Waterfall, Scrum, XP, Lean/KanBan, Methodology du Jour); more it helps to have some team members experienced with at least one methodology; as a starting point to innovate a right sized methodology within the Flow Team. For less experienced teams Scrum is a good starting point ; for more experienced teams KanBan is a good starting point.  Teams with no methodology experience tend to over think things when first introduced to Agile methodologies. Consider an effective methodology as the smallest set of practices that allows a team to get high quality products consistently out the door to clients. Then right size methodology to the teams experience. Agility is more cultural than procedural. Focus on Agile culture, and an appropriate methodology will emerge. When it does, give it a cool name! Resist the urge to enforce it on every other team you are subsequently on or every co-team you encounter.

Product Perspective

Flow teams building a new product have a chicken-and-egg problem. The new product being under defined; it is not clear what skill sets are needed to build it, nor the ideal Tech stack to deliver it. It is vital at the new Product stage that Product, Intelligence, and Tech are all at the table early, and working in concert (see C4M posts). Products defined without technical input show it; as do Tech product efforts without Product input. Applying Analytical insight at bug testing time is WAY TOO LATE — critical software decisions have been made and codified and are hard to undo, no matter how many bugs are found; more often it is not bugs per se but that there is a mis-fit between the software solution, the problem domain, and the required market fit. Ideally Tech, Product, Analytics are all in at the design stage; product and Tech rapidly get to an MVP whose usefulness SME’s and business analysts can determine, via standing in the shoes of our clients.

Starting over early in a new product’s development is much easier than starting over in a “new” product that has been under development for a long time. Avoid over design, allow failing fast, and quickly iterate towards an MVP. If a new product can not get to MVP in a 3-4 month time line — a Retrospective is in order. Double that time with no MVP, and it is time to consider beginning again as the existing Tech & Product commitments may be too brittle or scoped wrong; or there is a misfit between software solution and problem domain.

New products require not just the creation of the product, but also the Go-To-Market strategy. This should start as soon as an MVP is available. When you are actually at Go-To-Market is way too late.

Iterating an existing product should focus on two things:

• feedback loop from clients (augmented with instrumentation and telemetry such as Pendo) as to the user experience and current features

•    innovation loop of new features, product line complements, by the Flow Team.

Connecting these two loops is vital to allow clients to both see that the product is moving towards refinement based on their feedback and in allowing clients to experience surprising new features that delight them and warrant more feedback.

In the long run an established Analytical Flow team will likely both iterate on existing products, and create new products. This creates the opportunity to build out  product lines  on the Product side, refine analytical algorithms for accuracy and robustness, construct and scale Frameworks by composing Capabilities to create Assemblies (internal product engines or factories) on the Tech side, and Reports, workflows, and Use Cases on the analytical side. Reports and Use Cases test the market, as well as testing the utility of new and iterated products.

To maintain growing product lines at scale — automation is essential. But premature automation, performance tuning, and scaling can lead a product astray, if market fit is not there. Building the wrong performance optimized product at scale wastes valuable and limited resources. Get the market fit right first (and early) via an MVP, then bring in automation, scaling, and performance tuning as needed in rapid iterations.

Critical in establishing a new Flow Team is making sure the team can fire on Prod, Tech and Analytics (consider BI/ML/AI a continuum) early, and often. The respective organizations must align down to the Flow Team ; and the Flow Team aligns back up to the respective organizations market strategy and value thesis. Flow Teams thus become the method of alignment and synchronization top down and bottom up.

The core skills needed by members of a Flow team are the abilities to learn, cross-train and to collaborate. Everything else needed can be innovated, as required. We will cover practices supporting learning, cross training and collaboration in separate posts.

ANALYTICAL FLOW CAPABILITY MODEL

Flow Team Maturity Capabilities required depend on the kind of organization you are in and how it is incorporating analytical approaches (to predict, to decide) and automating and scaling them into client facing products.

Flow teams can start at any point in the continuum from a team of consulting analysts to a multi-startup hardened team of senior DS/AI and DE’s who are capable of leaping from code detail to architecture in a single bound. At each point in the continuum, there are opportunities to cross train together to get to the next level of expand capability..

Capability 0.  Analysts.

Ability to explore, visualize, and story tell through data is the core capability needed by any Analytical Flow Team. Once this capability is mastered by a team it can expand capability in other directions depending on the nature of the product.

Creatively combine analytical tools (explore, visualize, model and test) to solve problems. Analyst Teams are usually proficient in the multiple tools that cover their domain. Individuals have already put in, or are well on their way to putting in the 10K hours that leads to mastery of an analytical domain. Stage 0 analysts are in a good position to evolve into Technical POs, Data Science Analysts, Data/AI Scientists depending on their interests, formal and self-learned training, as well as predilection to focus on product, analysis, or software aspects. All these facets  will come into play in expanding capabilities of Analytical Flow Teams.

Occasionally a product team will have excellent technical capabilities at automating and scaling software but will be missing these core analytical capabilities. In those cases the analytical capabilities need to be developed to create the ability to expand and evolve a product, and create new products; not just maintain existing products at scale.

Capability 1. Analytical Prototypes.

Increasingly many Analyst teams have the capability to code and prototype allowing them to move seamlessly from exploration and visualization of alternative AI/ML models to Proof of Concept (POC), Prototypes and Minimum Viable Products (MVP).

(https://www.techmagic.co/blog/poc-vs-prototype-vs-mvp/)

Dual Analysis and Coding capabilities allows growth into a Capability 1 Team: able to solve problems in an analytical domain through programming, going beyond existing domain tools to create the software needed internally or by clients to get early product feedback. These Analytical Prototypes may not be pretty, may not show evidence of Software Engineering best practices; but the programs work, produce usable outputs, and have some quality control. The focus at this stage is analytical problem solving through programming. The resulting software is often labelled “POC”, “Prototype” or “MVP”. Analytical Flow Teams at this capability can often be very small with 2-3 folk. They can often be a research or innovation team working closely with a product team.

Capability 2: Analytical Product.

A capability 1 team can get to an MVP on its own; but requires additional support from a product development team. By contrast, a Capability 2 team can go from ideation to prototype to product without calling in additional resources.

Analytical Product teams have the ability to create and maintain domain specific Analytical Products used by clients, and internal teams. Software design, maintainability, iterability best practices come into play. Separation of concerns leads to increasing focus on modularization, configurability, and user interface. Problem solving code defined in POC, Prototype and MVP is refined into tools and applications. Focus now is on design patterns for usable and maintainable applications. Analytical product teams iterate from idea to shippable product. The increased capabilities now include minimally multi-stack analysts (including POs, Data/AI Science Analysts) as well as people with strengths in Software Engineering, and QA, and Data Scientists with more design and engineering focus. POs at this stage work more closely with Marketting, or develop Go-To-Market skills. Being multi-stack the team still stays small; but now team size is more like 3-5.

Capability 3: Scaled Analytical Product.

Products from stage two are now scaled and automated. Emphasis moves from individual products developed by the team to product frameworks that can support a product line. While scaling technologies change roughly every decade, the core design principles for scaling products have been in place for over 50 years — loose coupling, abstraction, modularization and automation. There is greater focus on pipelines and deployment at this point .

Team size is now a bit bigger, 4-10 depending on the diversity of the product line. Often split into sub-teams of 3-5 with rotation across sub teams. Focus is on developing the required skill sets within the Flow team. DevOps, Architecture and DE coaching becomes critical at this stage. Often a DevOps specialist or an Architect is consulting to, or embedded within the team. In these cases the goal is to establish these capabilities within the team. We want to teach “teams to fish” rather than giving them fish. At this stage the scaled analytical product and front end UI may start getting developed in tandem (often by separate but closely coordinating teams) — early connection of Analytical Product and UX is critical. A great analytical product needs to be tied to an immersive user experience. Configuration of the data/analytical back end to support orchestration of UI/UX in the front end is critical to success.

Individual Flow Teams tend to lose cohesion if team size grows beyond 10-12. When team size approaches that point it is worthwhile considering defining differentiated but complementary sub teams of smaller size .

Capability 4: Analytical Platforms.

Analytical Platforms are developed by multiple Flow Teams cross-training together. Focus now becomes leveraging shared architecture, supporting microservices, discoverability, SDLC and SOC2 standardization to provide privacy and security standards. Additionally as platforms can support multiple product lines, multi product coordination and agile release trains become critical.

Also critical is separation of concerns. A Data platform has different concerns than an AI platform, though both have a deep focus on data processing. Focussing on real time (or near real time) data also brings in separate concerns; as does distributed and event based systems. Clear separation of concerns and clear interfaces across components leads to composable and evolve able architecture.

Another key change at the level of Analytical platforms is that they must provide clearly developed service agreements to those product teams using the platform. The Product Teams are now amongst the customers of a Platform Team. This again requires a critical separation of concerns between a platform team and the multiple product teams using the platform. Maintenance of the platform should not break products. Product teams should be able to focus on their product leveraging platform services without worrying about destabilizing other product teams or the platform itself.

To Clients,  a Website driven SaaS application may look like the platform. But a true platform is a set of services supporting the creation, data and computational scaling, developmental lifecycle and deployment of multiple product lines leveraging a common infrastructure. A well designed platform facilitates developing a network of products that flow into the client facing SAAS, and the protocols by which new products are discovered and integrated. In addition to DevOps being critical here, SRE is also critical, since now a consistent platform must be maintained across a large range of products and client subscription levels; and the platform may now be providing critical workflows and services to clients. Often DevOps sets WHAT needs to be done while SRE sets technical guidance on HOW it is to be done ( similar to how Product determines What a product is and Tech determines How it is built).

While Training and Practice are critical in all stages, Cross-Training across multiple Analytical Flow Teams using or developing an analytical platform becomes critical, as now the handoffs are many and the stakes are high. Increasingly communication across technical, product, business and leadership teams needs to be aligned for successful development of Analytical Platforms, invoking Conway’s Law:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

-- Melvin Conway

(quoted from : https://martinfowler.com/bliki/ConwaysLaw.html)

WHERE DID OUR FLOW GO?

Just as individual writers are blocked, Analytical Flow Teams can get blocked.

Blocking can occur for many reasons, including:

• the team is stuck in an iteration that is not working as intended

• two or more team members are in conflict

• the team is in conflict with another team(s)

• an intense iteration(s) has left the team burned out.

• a poor client response to a release has shaken the teams confidence

• feedback from internal stakeholders holders has led the team to second guess itself

• team feels misaligned with senior management (or vice versa)

• there occurs dysfunctional behaviour between team mates or between a manager and one or more team mates

• team has perfected the product and there is nothing left to do.

All but the last point are blockers. Achieving the last point will likely earn your team an award. There are myriad other flow blockers; I’ve just stated the most common.

The generic options when blocked are:

• grind through

• talk it through for example using the “CORE PROTOCOLS” developed by Jim & Michelle McCarthy in their book “Software for your Head”

• change direction/try something new

• seek help/advisement (and in case of dysfunctional or abusive behaviours, report if safe to do so). Help/advisement could be from HR, Sr Leaders with experience debugging teams, even consultants for short focussed survey and dialogue of team dysfunction.

• take a break or temporarily break away from the team.

• break out of your current team head/heart space via a shared experience

• switch teams

Each of these options carry some degree of stress. Perhaps most stressful is “switch teams” as it can imply leaving your current team, or business unit, or finding a new job entirely.

The solutions are unique to each Analytical Flow Team. I’ll go through each of the generic approaches in future posts. For now, just be aware blocks will happen, when the team as a whole does not flow. Then ask yourself; can you still find flow in your daily work? If yes, focus on your own flow for a while and seek a mechanism to deal with team blockage. Team Health meetings following the Core Protocols are one approach I have found useful in the past to unblock a team. Interspersing Production and Innovation oriented iterations is another approach to return to flow — particularly if a team finds itself in “grind mode”. Critically, the team should identify its own blockers, and develop its own methods to unblock. Blockers are a particular case where One Size Does Not Fit All and the creative solutions a team comes up with become key components of it’s culture of resilience.

JUMPING OFF POINTS:

here are a few starting references to begin your journey.

Team Flow

https://www.psychologytoday.com/ca/blog/the-athletes-way/202110/why-team-flow-is-unique-brain-state?amp

Individual Flow

https://www.medicalnewstoday.com/articles/flow-state

Mihaly Csikszentmihalyi on Flow

https://www.ted.com/talks/mihaly_csikszentmihalyi_flow_the_secret_to_happiness?language=en

https://blogs.baruch.cuny.edu/authenticityandastonishment2/files/2013/04/Mihaly-Csikszentmihalyi-Flow1.pdf

https://www.cgu.edu/people/mihaly-csikszentmihalyi/

https://positivepsychology.com/mihaly-csikszentmihalyi-father-of-flow/

Finn Goulding on Flow Teams

https://medium.com/flow-the-new-agile-framework/flow-is-for-everyone-agile-is-not-f0a074eef6f8

https://medium.com/flow-the-new-agile-framework/the-minimalist-framework-for-agile-7f92e6046fe1

https://medium.com/flow-the-new-agile-framework/flow-as-an-operating-model-can-transform-how-you-work-275e07ddaa1

https://medium.com/flow-the-new-agile-framework/getting-into-the-flow-rethinking-agile-1e09cef6fad

CORE PROTOCOLS

These are excellent starting points towards better communication for teams at any level of experience. The practices are simple to state, but take discipline to practice constantly; particularly when the team is under stress. With practice, the core protocols unfold into a deep toolkit of constantly solving team communication issues that can block flow.

https://liveingreatness.com/wp-content/themes/liveingreatness/library/files/core-protocols-3.03.pdf

https://liveingreatness.com/wp-content/themes/liveingreatness/library/files/Software-For-Your-Head-book-v1.0.pdf

Thanks for reading Product Innovation AI. If you liked this post, please click ♡ button below to help product innovation ai grow.

Subscribe for free to receive new posts and support this work.