Question artificial boundaries like problem/solution, feature/non-customer-facing, and build/run.

We mean well…

Highlighting these boundaries is often a sign of respect. You do your part, and we’ll do our part. We respect your work. Please respect our work.

Or, they are impassioned attempts at protecting and/or elevating the work of an embattled team. Product owns the problem, and Engineering owns the solution! UX translates the needs of the user, and product defines the business goal! We are important! Respect our work and time!

Consider the “rules” of Scrum. Many of those rules were expressly designed to protect developers (“the Team”) while at the same time bringing the business and developers closer to together. You get off our backs during the sprint, and we will deliver something. We promise!

So our hearts are in the right place.

But…

These boundaries manifest in structures and processes. Instead of thinking in terms of hats or skills to add, we start thinking in terms of handoffs, and boxes and arrows. You observe things like completely different funding structures for Ops (the “Run”) and Development (the “Build”), despite the vast overlaps in the two. Ops struggles due to low funding and exploding complexity, and Development blames ops.

Or Design “getting ahead” of product development, and creating a perverse set of hand-offs, sign-offs, and rework cycles. They mean well — see, we’re good at this box here! — but the resulting process is dysfunctional and impacts the final product.

Orgs often get confused by “cross-functional”. They get it wrong. The professionals on their teams are cross-functional, but they aren’t WORKING together. They’ve taken these hardened boundaries, and have created processes, workflows, and handoffs based on them.

So…

It is possible to celebrate expertise AND work together. Be very, very cautious when you see the org chart and/or product development process starting to harden around artificial boundaries. Building awesome products is messy. It requires skilled people working together (and sometimes teaching / evangelizing what they know).

You’ll see all kinds of rationalizations around why things like build/run, design/build, why/how are the right way to structure work. Look closely. What is at the heart of it? Look for: assumptions about economies of scale, trust proxies, tension between senior executives, a fear that without those boundaries folks can’t do good work, etc. And then try to address those problems.