SCM is at the center of R&D organizational change.  Sometimes, it can seem like a knock-down, drag-out fight between the old guard protecting against change and some newcomers promoting change.

The old guard is protecting what they know works well from morphing into something they don’t know, or into something they don’t think will work.    Some resist change because they see it as a shift from what they know to be a good working environment to what they think are unnecessary process changes adding extra overhead.

The newcomers are promoting change to what they believe will be better, perhaps wanting a change to something known to them from a previous job. Sometimes the newcomers see the current situation as uncontrolled chaos instead of what they consider organized, development best practices.

One thing that is for sure – organizational change will happen as growth occurs.  It is like the size of a code base growing over time and eventually there is a need for significant refactoring.  Sometime the code needs to be completely rewritten.  This change means the SCM requirements are changing.

When the change is the organization, it could mean changing out someone’s favorite version control system and replacing it with a different one.  It could also mean some people are unhappy and leaving for greener pastures.  The human element involved with changing R&D organizations can be painful.  Attempts to stop change might slow things down for a while, but the changes due to growth are necessary and won’t be stopped forever.

Catalysts for change are ever present in the software industry.  Slowing down change will simply cause a buildup of pressure for the appropriate changes.  Resistance to change causes erratic changes over time instead of gradual, continuous change over time.  Gradual changes are perhaps easier to make; and possibly easier on the people involved.

I think the transitions should be done gradually and should be managed carefully.  There is a need for feedback gathering as the changes occur.  Are the changes happening too fast or too slow?  Do we understand the transitions in progress?  After all, you can’t do SCM right without understanding the transitions in progress.  If we change too fast, if people leave rapidly, knowledge transfer is lost.  Lost knowledge is costly.  If we change too slowly, efficiency is poor due to out of sync SCM processes.

Knowing what the changes are is a key to properly managing the changes.  Here is a list of some of the organizational changes happening as a result of the evolving R&D environment.  It is by no means a complete list – it is intended to get you started thinking.

• Flat organization          =>        Deep hierarchical organization
• Full stack teams          =>        Layered teams
• Surgeon model           =>        Peer team model
• Disorganized               =>        Organized
• Developer driven        =>        QA or market driven
• Consensus                  =>        Consultative or directive decisions
• Cowboy coders           =>        Enterprise developers
• Generalists                  =>        Specialists
• Many perks                 =>        Few perks
• Creative retention       =>        Security
• Low pay                      =>        High pay
• Passion motivated      =>        Money motivated
• Big impact workers     =>        Low impact workers
• Low job security          =>        High job security
• Family culture             =>        Machine culture
• Exciting work              =>        Boring environment
• Pathological Culture   =>       Generative culture
• Monolithic code base  =>        Modular code base
• One-off builds             =>        Assembly line builds
• Manual builds              =>        Continuous integration
• Multiple technologies  =>        Core competencies
• No economy of scale =>        Economy of scale
• Latest technology        =>        Mature technology
• High innovation           =>        Refining the existing products
• Latest code                 =>        Reproducible builds
• No policies                  =>        Development policies
• Unstructured               =>        Structured development
• Documentation dump =>        Organized documentation
• No SCM needs           =>        High SCM needs
• Uncontrolled process  =>        Controlled process
• Low overhead             =>        High overhead
• Mostly manual                        =>        Mostly automated
• No regression tests     =>        Targeted regression tests
• Resource utilization    =>       Throughput optimization
• One-off builds             =>        Repeatable builds
• No transparency         =>        Transparency
• Seek market share     =>        Seek profitability
• No legal concerns       =>        Legal concerns
• High risk                      =>        Low risk
• Venture funding          =>        Profitable
• Scalable startup          =>        Cash cow