Time To Do This!

If  and/or when you take the step of modelling your business as Part 3 attempted to inspire us to do, and you get that Business Model Canvas mapped out, then the next thing is to take action and….. let’s slow down a minute.

Where do you start?

It’s People – People!

If yours is like any business, it probably already has an infrastructure of human and other resources ingrained in the walls and halls of the business.  This structure could be acceptable or detrimental to the success of the objectives you just hashed out with all of those talented people in the room.

Regardless of what we think might be true, logical cool heads should grapple with this one before we go much further on this Domain Intelligence (DIN) journey.  There is a reason I think addressing People/Teams is a critical next step.

The Hidden Progress Killer

In a recent post I put forward this notion that we cannot expect structures built for well-defined work to provide similar productivity gains when dealing with ambiguously defined work.  Unfortunately, many don’t question their org structure and just try to do different stuff with the same infrastructure.  Plus, the thought of changing from the status-quo conjures up a lot of fear especially for those used to the Industrial Age constructs of an organization. I think this fear is the same basic fear coders have when messing with large messy but profitable applications.  It is real and it should really be addressed.

Why? If Conway’s Law has taught us anything, it is that the solutions we design mirror that of the communication structure of the business.  I have experienced this in every company I have worked in.

• Single Developer, Small Ball of Mud – Probably works and might be flexible for awhile.
• Several Developers on a Team, Medium Ball of Mud – Probably works but is harder to modify.
• 100 Developers on a Team, Massive Ball of Mud – Fo-get-about-it.
• 6 teams of about 15, Several Large Balls of Mud – getting some stuff done, but not likely keeping up with the business needs.
• A few teams of a few devs working on a Monolith that will not die – its really just one team so don’t kid ourselves.

Let’s Think About This

If the business communication structure is the leading indicator of the solutions we design (Conway’s Law), and the solutions we design need to be better informed by the network of communications in the company (The new Business Model Canvas), then the communication structure, and consequently team formations, of the company need to be successfully paradigm shifted or at least modified to lead that change in a more aligned direction.

The New Product Team – Might be Failing

Some managers are realizing this these past few years and the uptick in Product-centric teams has proven that to be the case.  And even though they are attempting to move in this new direction, they often find themselves still constrained by the status quo and are marginally seeing any new benefit – The Big Ball of Mud still emerges.

Why? because I believe they are attempting to implement the new without modifying the old structure. They are applying this hybrid multi-dimensional organizational format where people work with a product team, but report to another management structure for HR reasons.  Reporting to people who do not get your work is amazingly awkward.  It may be working in some capacity in some places better than the traditional corp ladder format, yet, my experience working in this style left a lot more to be desired.

Transition Carefully, But Transition

Changing hierarchical structure in any company is generally not to easy.  What do we change?  How do we change?  When do we change?  When do we change again? Even with those and other questions, Conway’s Law points us toward the need for this type of Team Transformation. This just might be what the company needs to grow in the next phase of its existence.

So how do we accomplish this?  There is no cookie-cutter solution to any company org chart just like there is no cookie-cutter solution to all software needs.  And add to that, communication in teams is like communication in software.  It can get messy.

What is a leader to do?

For a real actionable and far more peaceful solution, I am thinking about a paradigm that has served software well for the last 15 or more years.  It has solved this problem in the complex software space when well implemented.  Maybe we can draw from this concept.

Let me describe the exploration that might take place from that paradigm before I say what it is:

• The business may need to evaluate the new activities the people need to perform.
• While doing that the leaders may need to better discover the Ubiquitous People/Team Language to understand the People/Team Domain needs for the future.
• When they do that, they may need to address the new People/Team Context dynamics in order to form better Resource Bounded Contexts.
• They may want to Aggregate the appropriate disciplines for the products they are building rather than loosely connecting cross-functional members by only inviting them to meetings.
• There is probably a chance a few Anti-Corruption Communication Processes should be established to allow for teams to work their best with fewer unnecessary distractions and keep communication as clear and as noise free as possible.
• That is just the beginning.

If you are a Domain Driven Designer for any length of time, you just read that list far differently than the one who does not recognize those terms in context of DDD.  I do believe your business leaders should ask you for more understanding and here is why.

Conway’s Law

I won’t do a DDD lesson here.  This is not the point.  The point is, if your teams need to be more fluid, better at communication, better supported, and more reliable, then you may want to look at what has worked in a different context.

What is most fortuitous is that you have the software context in some circles to learn from, the very context your people-structure highly influences.

The DDD paradigm already respects economically flexible choices in the software context to include but not be limited to the way software is planned and coded.  Incidentally, in a company that has not made this change, the DDD efforts get frustratingly hindered by People contexts that are not in alignment.  Translating DDD precepts into the People/Team context might just be what the doctor ordered. 

Why?

Conway’s Law

Lastly, removing the translation layer between the people team context and the software development or product context should generally reduce organizational complexity making it easier to deliver the products the business really needs with less chance of discrepancy.

I won’t say Conway’s Law or DDD again in this post – mainly because I am at the end.

Oh – But there is more.  In future posts we will start to dig into the potential of empowering Domain Intelligence for teams and I will even work through some thought provoking team diagrams because my editor will kill me if I don’t.

In addition, we will look beyond teams and software as Domain Intelligence likely provides better operational outcomes as well.

Until then.