Category: Organisation

How does your team work?

Some companies only work big. Large, prescriptive projects with no incremental value delivery, no experimentation, and infrequent integration. Efforts advance at a glacial pace. Scope expands to fill the available time, and then some. And the work “on the roadmap”? That work gets bigger and bigger as well through a cycle of disappointment, fear, and planning overcompensation. 

Some companies only work small. They sprint in circles. The work lacks coherence and feels scattershot. There’s a perception of progress, but looking back the team sees a lot of disjointed, reactive work. The resulting experience is incomplete and imbalanced. But management applauds the team(s) for being responsive, and the cycle continues. Plus… more features to sell! 

Some companies define big, and work small. Large, prescriptive projects get broken into many small pieces. Think of this as a combination of #1 and #2. The team works small and integrates frequently, which reduces risk and accentuates progress. But there is little room to respond to learning and feedback. Design work is more set-in-stone, and less strategic. Like a big lego set, it is placing tiny pieces according to the plan. What if the finished lego set is the wrong lego set? What if 20% of the work represented 80% of the value? Then again, the team is applauded for finishing “big things”.

Finally, we have thinking big, and working small. The team rallies behind a compelling mission linked to a coherent strategy. The mission is outcome/impact oriented. The team contemplates a vision for the holistic experience but works with broad strokes. They sequence work with the riskiest assumptions first — experimenting, testing, and learning. This is not a ship-and-forget or a ship-and-maybe-in-a-year-we-come-back operation.

For items 1-3, note how incentives can hold these ways of working in place. Big prescriptive projects look bold and compelling. High velocity is intoxicating. Rapid progress on big prescriptive projects …exciting!

Thinking big, and working small is more nuanced. There’s more acceptance of uncertainty. There’s less set in stone. There’s an art to framing a mission to leave space for creativity, while also capturing the opportunity. 

Start by figuring out where your company tends to work right now. If you only work big, then start working small. If you are only working small, maybe start by defining the bigger thing. If you’re working small and defining big things prescriptively, then start easing off that level of prescriptiveness focus on missions and strategies.

From The Beautiful Mess – Think Big, Work Small

Charlie Kindel – how to achieve focus in any endeavor you embark on by simply writing down the Purpose, Principles, Priorities, People, and Plan (the 5Ps). An endeavor could be a software development project, a job search, or a phase in your life. I have personally found the 5Ps a useful tool for small projects (e.g. prepping for a VC demo/presentation) as well as large scale projects that include 1,000s of people.

• Purpose: Why do we exist? Why are we in business? Where do we want to be in the future? What will we deliver?
• Principles: What are the non-negotiable rules and key strategies? How will we act?
• Priorities: What’s the framework for tradeoffs? In what order do you do things? How much mass or energy do you apply to each element of the plan? What is not important?
• Plan: How are we going to stage and tackle solving the problems? What are the known dates & forcing functions on the calendar?
• People: Who’s accountable for every key part of the plan?

From https://ceklog.kindel.com/2011/06/14/the-5-ps-achieving-focus-in-any-endeavor/

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

Conway’s law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.

Easily observed in organisations today Conway’s law still has merit and should be considered when designing software or reviewing organisational design.

From http://www.melconway.com/Home/Conways_Law.html

Also, from https://www.linkedin.com/posts/jonny-williams-83433836_do-you-care-about-conways-law-if-youre-activity-7009445165320790016-ZYTW/

So what might caring about Conway’s Law help you to do as a team enabler?

👉 Understand misalignment between the organisation’s communication structure and the systems and products they are creating.
👉 Recognise potential organisational impediments that might limit effective collaboration and communication.
👉 Offer practices, tools, and techniques that can help teams to navigate the limitations of the structure around them.
👉 Avoid common pitfalls and challenges that arise when working on complex systems.
👉 Help senior colleagues to understand that they play a role in shaping systems and products through their influence over communication structures.

Why being imaginative is stifled within most businesses. A great chart from @rorysutherland describing the consequences of different modes of decision making, whether things go right or wrong.

From https://twitter.com/thetenzer/status/1129034179239383040